From tinguely at casselton.net Sun Aug 2 18:45:08 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Sun Aug 2 18:45:19 2009 Subject: FYI: elf_trampoline.c rev 194609 breaks PXA gcc 4.5/binutils 2.19 Message-ID: <200908021845.n72Ij6Nn094849@casselton.net> I have a copy of the GCC 4.5 compilers (ARM/i386) and binutils 2.19 (ARM only) that have been ported to gnu/usr.bin/ (BSD makefiles). I have been using the compiler for several weeks and the binutils is realitively new. The source that I have been testing are my local mods to an old code base. Thinking it is time to move the mods to the newest kernel code, last week I tried the current head GUMSTIX kernel sources and found the compiled kernel would no longer boot under the QEMU. It took me a long time to isolate, I even build new versions of qemu, gcc 4.5, and binutiils 2.19, but I finally isolated the problem to the file sys/arm/arm/elf_trampoline.c revision 94609. I suspect, the lack MMU enable in the __start routine. This code still works with the built-in gcc 4.2.1/binutils 2.15, so this is just a FYI. --Mark Tinguely. From bugmaster at FreeBSD.org Mon Aug 3 11:06:53 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 3 11:07:53 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200908031106.n73B6qrv088525@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From raj at semihalf.com Mon Aug 3 15:21:29 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Mon Aug 3 15:21:41 2009 Subject: About the "USB Cache and busdma usage in USB" thread In-Reply-To: <20090724.233404.-399282844.imp@bsdimp.com> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200907232209.47729.hselasky@c2i.net> <20090724.233404.-399282844.imp@bsdimp.com> Message-ID: <8DC8C704-F84D-4A60-A11B-2F877EB903C9@semihalf.com> On 2009-07-25, at 05:34, M. Warner Losh wrote: > In message: <200907232209.47729.hselasky@c2i.net> > Hans Petter Selasky writes: > : On Thursday 23 July 2009 20:53:06 Marcel Moolenaar wrote: > : > All, > : > > : > I went over the thread and this is what I have to say about it: > : > > : > Using busdma to manage/control CPU caches is wrong for the > : > following simple reason: bus_dmamap_sync() has the side-effect > : > of copying to and from the bounce buffer (if applicable). > : > > : > CPU caches should be kept coherent by using an appropriate API. > : > We already have cpu_flush_dcache(). All we have to do is add > : > cpu_inval_dcache() and let the MD code determine how best to > : > do this -- even if they decide to use busdma. > : > > : > In general: D-cache and I-cache control/handling should not be > : > hidden from MI code. It should not be treated as an artifact of > : > some platform. It should not be implemented by banking on some > : > side-effect of other function(s). We only achieve efficient > : > cache control if MI code calls appropriate APIs so that we can > : > precisely express what we need to achieve at that point. > : > > : > For example: when we write a breakpoint into the text segment > : > of some process by using ptrace(2), the ptrace(2) code must > : > call an appropriate API to make sure that the I-cache is made > : > coherent with memory. This may require a previous D-cache > : > flush! We should not kluge uiomove(9) like we did on PowerPC > : > to deal with this. Note ARM and ia64 are still broken in this > : > respect. > : > : Hi, > : > : I would be fine with a solution where cpufunctions are used > directly in USB. > : The only problem is that if bounce pages are used, which happens > in the case > : of loading kernel virtual data into DMA, then busdma sync calls > would still be > : required. > > They are needed on i386 kernels with more than 4GB of ram... Or ram > located above 4GB... Hans, So how do you want to proceed with these cache sync issues? We need to fix this before 8.0. Rafal From hselasky at c2i.net Mon Aug 3 15:59:51 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Aug 3 15:59:58 2009 Subject: About the "USB Cache and busdma usage in USB" thread In-Reply-To: <8DC8C704-F84D-4A60-A11B-2F877EB903C9@semihalf.com> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <20090724.233404.-399282844.imp@bsdimp.com> <8DC8C704-F84D-4A60-A11B-2F877EB903C9@semihalf.com> Message-ID: <200908031759.46491.hselasky@c2i.net> On Monday 03 August 2009 17:01:37 Rafal Jaworowski wrote: > Hans, > So how do you want to proceed with these cache sync issues? We need to > fix this before 8.0. Hi, CC'ed current: We have a case on ARM where bus_dmamap_sync() is not suffient to update the CPU cache. One reason for this is that USB needs to invalidate the same memory area multiple times. Busdma sync expects paired operation when using the PRE and POST flags, from what I understand. I do not consider this an USB issue, hence Semihalf has got the USB stack working by manually inserting CPU flush/invalidate calls into usb_pc_cpu_invalidate() and usb_pc_cpu_flush(). Their other solution however which modifies the bus_dmamap_sync() flags will break on platforms with more than 4 GByte of memory. Maybe Rafal can give a quick summar to new people at the -current list, or see previous thread on the ARM mailing list. USB needs a solution where it can call a function given a busdma mapping, preferably with an offset and length, which handles the cache sync issue and works with bounce pages on +4GB systems. --HPS From raj at semihalf.com Mon Aug 3 16:52:51 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Mon Aug 3 16:53:02 2009 Subject: About the "USB Cache and busdma usage in USB" thread In-Reply-To: <200908031759.46491.hselasky@c2i.net> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <20090724.233404.-399282844.imp@bsdimp.com> <8DC8C704-F84D-4A60-A11B-2F877EB903C9@semihalf.com> <200908031759.46491.hselasky@c2i.net> Message-ID: On 2009-08-03, at 17:59, Hans Petter Selasky wrote: > On Monday 03 August 2009 17:01:37 Rafal Jaworowski wrote: >> Hans, >> So how do you want to proceed with these cache sync issues? We need >> to >> fix this before 8.0. > > Hi, > > CC'ed current: We have a case on ARM where bus_dmamap_sync() is not > suffient > to update the CPU cache. One reason for this is that USB needs to > invalidate It's not only ARM, but some MIPS and PowerPC observe this as well; actually I'd expect any system with non-coherent DMA will suffer from this with current USB stack. > the same memory area multiple times. Busdma sync expects paired > operation when > using the PRE and POST flags, from what I understand. I do not > consider this > an USB issue, hence Semihalf has got the USB stack working by manually > inserting CPU flush/invalidate calls into usb_pc_cpu_invalidate() and > usb_pc_cpu_flush(). Their other solution however which modifies the > bus_dmamap_sync() flags will break on platforms with more than 4 > GByte of > memory. > > Maybe Rafal can give a quick summar to new people at the -current > list, or see > previous thread on the ARM mailing list. This issue was discussed already: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=50307+0+archive/2009/freebsd-usb/20090628.freebsd-usb See also the beginning of this thread: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=10461+0+archive/2009/freebsd-arm/20090726.freebsd-arm Rafal From gjb at semihalf.com Tue Aug 4 15:01:17 2009 From: gjb at semihalf.com (Grzegorz Bernacki) Date: Tue Aug 4 15:01:34 2009 Subject: About the "USB Cache and busdma usage in USB" thread In-Reply-To: <200908031759.46491.hselasky@c2i.net> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <20090724.233404.-399282844.imp@bsdimp.com> <8DC8C704-F84D-4A60-A11B-2F877EB903C9@semihalf.com> <200908031759.46491.hselasky@c2i.net> Message-ID: <4A7848A0.4080905@semihalf.com> Hans Petter Selasky wrote: > > CC'ed current: We have a case on ARM where bus_dmamap_sync() is not suffient > to update the CPU cache. One reason for this is that USB needs to invalidate > the same memory area multiple times. Busdma sync expects paired operation when > using the PRE and POST flags, from what I understand. I do not consider this > an USB issue, hence Semihalf has got the USB stack working by manually > inserting CPU flush/invalidate calls into usb_pc_cpu_invalidate() and > usb_pc_cpu_flush(). Their other solution however which modifies the > bus_dmamap_sync() flags will break on platforms with more than 4 GByte of > memory. > > Maybe Rafal can give a quick summar to new people at the -current list, or see > previous thread on the ARM mailing list. > > USB needs a solution where it can call a function given a busdma mapping, > preferably with an offset and length, which handles the cache sync issue and > works with bounce pages on +4GB systems. > Hi Hans, New USB stack uses busdma in a little unconventional way. As you mentioned in one of previous mails your assumptions are: XXX_PREXXX functions should be used prior to read/write device access. In other words, PRE has to be a flush operation. XXX_POSTXXX functions should be used after read/write device access. In other words, POST has to be an invalidate operation. Generally it is true, but if you look at ARM code you will find out that it is not that simple. You assumed that after bus_dmamap_sync(..,BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD) there will be no data in cache, but it that's not true. Cache operation are performed on cache lines (32 bytes on our ARM device). Let's say you want to invalidate buffer with size 10 bytes. In this case first whole cache line is invalidated ( and now all requirements related to busdma synchronization are fulfilled, old contents of cache is gone). The second step is to restore back into cache 22 bytes of data which were not a part of buffer. After this second step data are loaded into cache line (it is because our device uses write allocate feature). So busdma on ARM "Perform any synchronization required after an update of host memory by the device", but we still end up with not invalidated flush. It is hard to fix it. We cannot just invalidate whole cache line. We cannot also use cpu_dcache_wbinv, because this function is called after buffer was used by device so we dont want to overwrite those data with old cache contents. One possible solution is to call first bus_dmamap_sync(..,BUS_DMASYNC_POSTREAD) and then bus_dmamap_sync(..,BUS_DMASYNC_PREREAD) in usb_pc_cpu_invalidate(), but this is ugly workaround which applies probably only to ARM case. The second problem is that you cannot use cpu_dcache_wb(inv) function directly because you need to handle bounce pages in USB code. I think that duplication of busdma code makes no sense. Probably it takes less work to add bus_dmamap_sync() before/after each transaction. Could you give us a quick overview of buffer handling in USB stack? I want to understand what is the relation between usb_pc_cpu_invalidate/flush() functions and reading/writing to USB device? From yours previous mail I understand that invalidate is called *before* reading and flush *before* writing. Is that true? Can we add a functions which will be called *after* reading/writing? If you have any questions regarding cache operation on ARM. please let me know, I will try to answer them. regards, Grzesiek From hselasky at c2i.net Tue Aug 4 16:54:54 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Aug 4 16:55:01 2009 Subject: About the "USB Cache and busdma usage in USB" thread In-Reply-To: <4A7848A0.4080905@semihalf.com> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200908031759.46491.hselasky@c2i.net> <4A7848A0.4080905@semihalf.com> Message-ID: <200908041754.50244.hselasky@c2i.net> On Tuesday 04 August 2009 16:41:36 Grzegorz Bernacki wrote: > Hans Petter Selasky wrote: > > CC'ed current: We have a case on ARM where bus_dmamap_sync() is not > > suffient to update the CPU cache. One reason for this is that USB needs > > to invalidate the same memory area multiple times. Busdma sync expects > > paired operation when using the PRE and POST flags, from what I > > understand. I do not consider this an USB issue, hence Semihalf has got > > the USB stack working by manually inserting CPU flush/invalidate calls > > into usb_pc_cpu_invalidate() and usb_pc_cpu_flush(). Their other solution > > however which modifies the bus_dmamap_sync() flags will break on > > platforms with more than 4 GByte of memory. > > > > Maybe Rafal can give a quick summar to new people at the -current list, > > or see previous thread on the ARM mailing list. > > > > USB needs a solution where it can call a function given a busdma mapping, > > preferably with an offset and length, which handles the cache sync issue > > and works with bounce pages on +4GB systems. > > Hi Hans, > > New USB stack uses busdma in a little unconventional way. As you > mentioned in one of previous mails your assumptions are: > > XXX_PREXXX functions should be used prior to read/write device access. > In other words, PRE has to be a flush operation. > > XXX_POSTXXX functions should be used after read/write device access. > In other words, POST has to be an invalidate operation. > > Generally it is true, but if you look at ARM code you will find out that > it is not that simple. You assumed that after > bus_dmamap_sync(..,BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD) there > will be no data in cache, but it that's not true. > > Cache operation are performed on cache lines (32 bytes on our ARM > device). Let's say you want to invalidate buffer with size 10 bytes. In > this case first whole cache line is invalidated ( and now all > requirements related to busdma synchronization are fulfilled, old > contents of cache is gone). The second step is to restore back into > cache 22 bytes of data which were not a part of buffer. After this > second step data are loaded into cache line (it is because our device > uses write allocate feature). > So busdma on ARM "Perform any synchronization required after an update > of host memory by the device", but we still end up with not invalidated > flush. > It is hard to fix it. We cannot just invalidate whole cache line. We > cannot also use cpu_dcache_wbinv, because this function is called after > buffer was used by device so we dont want to overwrite those data with > old cache contents. > > One possible solution is to call first > bus_dmamap_sync(..,BUS_DMASYNC_POSTREAD) and then > bus_dmamap_sync(..,BUS_DMASYNC_PREREAD) in usb_pc_cpu_invalidate(), but > this is ugly workaround which applies probably only to ARM case. > > The second problem is that you cannot use cpu_dcache_wb(inv) function > directly because you need to handle bounce pages in USB code. I think > that duplication of busdma code makes no sense. Probably it takes less > work to add bus_dmamap_sync() before/after each transaction. > > Could you give us a quick overview of buffer handling in USB stack? I > want to understand what is the relation between > usb_pc_cpu_invalidate/flush() functions and reading/writing to USB > device? From yours previous mail I understand that invalidate is called > *before* reading and flush *before* writing. Is that true? Can we add a > functions which will be called *after* reading/writing? Hi, There are two kinds of DMA memory in USB regard: 1) Transfer descriptors are allocated in coherent DMA memory. Operation logic: 1.a) Write to descriptor. 1.b.0) Call usb_pc_cpu_flush() to write data to RAM. 1.b.1) Write more fields to descriptor. 1.b.2) Call usb_pc_cpu_flush() to write data to RAM. 1.c) Call usb_pc_cpu_invalidate() to clear cache. 1.d) Read status field. If not complete goto 1.c) 2) Any kernel virtual memory (which might not be coherent) 2.a.0) CPU read case: 2.a.1) Before transfer start usb_pc_cpu_invalidate() is called to clear any data in cache for this buffer. 2.a.2) After transfer completion usb_pc_cpu_invalidate() is called again. 2.b.0) CPU write case: 2.b.1) Before transfer start usb_pc_cpu_flush() is called to to flush any data in cache to RAM for this buffer. 2.b.2) After transfer completion there is no cache operation. Anything unclear? --HPS > > If you have any questions regarding cache operation on ARM. please let > me know, I will try to answer them. > > regards, > Grzesiek From gjb at semihalf.com Wed Aug 5 13:17:21 2009 From: gjb at semihalf.com (Grzegorz Bernacki) Date: Wed Aug 5 13:17:30 2009 Subject: About the "USB Cache and busdma usage in USB" thread In-Reply-To: <200908041754.50244.hselasky@c2i.net> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200908031759.46491.hselasky@c2i.net> <4A7848A0.4080905@semihalf.com> <200908041754.50244.hselasky@c2i.net> Message-ID: <4A79865E.3060206@semihalf.com> Hans Petter Selasky wrote: > There are two kinds of DMA memory in USB regard: > 1) Transfer descriptors are allocated in coherent DMA memory. > Operation logic: > > 1.a) Write to descriptor. > 1.b.0) Call usb_pc_cpu_flush() to write data to RAM. > 1.b.1) Write more fields to descriptor. > 1.b.2) Call usb_pc_cpu_flush() to write data to RAM. > 1.c) Call usb_pc_cpu_invalidate() to clear cache. > 1.d) Read status field. If not complete goto 1.c) > > 2) Any kernel virtual memory (which might not be coherent) > > 2.a.0) CPU read case: > 2.a.1) Before transfer start usb_pc_cpu_invalidate() is called to clear any > data in cache for this buffer. > 2.a.2) After transfer completion usb_pc_cpu_invalidate() is called again. > > 2.b.0) CPU write case: > 2.b.1) Before transfer start usb_pc_cpu_flush() is called to to flush any data > in cache to RAM for this buffer. > 2.b.2) After transfer completion there is no cache operation. > The best solution is to use bus_dmamap_sync() in in conventional way. I mean call bus_dmamap_sync(..., BUS_DMASYNC_PREREAD) in case 2.a.1 and bus_dmamap_sync(..., BUS_DMASYNC_POSTREAD) in cases 2.a.2 and 1.c. But this is quite a big change and it's risky to put in into -current now, so below is another solution which I believe is simple and safe. I understand that usb_pc_cpu_flush() is called *before* write transfer. So I think that we can just call bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE) there. usb_pc_cpu_invalidate() is called before and after each read transfer and to invalidate cache before reading status field. So I think that simplest fix is to call following sequence of functions in it: bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_POSTREAD); bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREREAD); Below is the patch with that solution. I tested it on ARM and PowerPC and it fixes the problem. Please test it on other platforms you have to see if there is no regression. diff --git a/sys/dev/usb/usb_busdma.c b/sys/dev/usb/usb_busdma.c index 82d18a1..c57f51d 100644 --- a/sys/dev/usb/usb_busdma.c +++ b/sys/dev/usb/usb_busdma.c @@ -678,8 +678,8 @@ usb_pc_cpu_invalidate(struct usb_page_cache *pc) /* nothing has been loaded into this page cache! */ return; } - bus_dmamap_sync(pc->tag, pc->map, - BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD); + bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_POSTREAD); + bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREREAD); } /*------------------------------------------------------------------------* @@ -692,8 +692,7 @@ usb_pc_cpu_flush(struct usb_page_cache *pc) /* nothing has been loaded into this page cache! */ return; } - bus_dmamap_sync(pc->tag, pc->map, - BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD); + bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); } /*------------------------------------------------------------------------* From hselasky at c2i.net Wed Aug 5 13:49:48 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Aug 5 13:49:55 2009 Subject: About the "USB Cache and busdma usage in USB" thread In-Reply-To: <4A79865E.3060206@semihalf.com> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200908041754.50244.hselasky@c2i.net> <4A79865E.3060206@semihalf.com> Message-ID: <200908051549.43890.hselasky@c2i.net> On Wednesday 05 August 2009 15:17:18 Grzegorz Bernacki wrote: > Below is the patch with that solution. I tested it on ARM and PowerPC > and it fixes the problem. Please test it on other platforms you have to > see if there is no regression. Hi, Your patch look Ok. I will do some more testing and then commit it to USB P4. Thank you! --HPS From gjb at semihalf.com Fri Aug 7 11:15:25 2009 From: gjb at semihalf.com (Grzegorz Bernacki) Date: Fri Aug 7 11:15:30 2009 Subject: About the "USB Cache and busdma usage in USB" thread In-Reply-To: <200908051549.43890.hselasky@c2i.net> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200908041754.50244.hselasky@c2i.net> <4A79865E.3060206@semihalf.com> <200908051549.43890.hselasky@c2i.net> Message-ID: <4A7C0CC9.3080701@semihalf.com> Hans Petter Selasky wrote: > On Wednesday 05 August 2009 15:17:18 Grzegorz Bernacki wrote: > > I will do some more testing and then commit it to USB P4. > Hi Hans, Have you had a chance to perform your tests? Do you see any problems on your machine after applying the patch? regards, Grzesiek From hselasky at c2i.net Fri Aug 7 12:33:17 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Aug 7 12:33:23 2009 Subject: USB busdma sync flag fix Message-ID: <200908071433.16484.hselasky@c2i.net> Hi, Can people with AMD64 + USB and more than 4GBytes of RAM give the following patch a shot? http://perforce.freebsd.org/chv.cgi?CH=167088 Thanks to "Grzegorz Bernacki" and his friends at Semihalf for fixing USB on ARM and PowerPC ++ --HPS From raj at semihalf.com Fri Aug 7 13:09:31 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Fri Aug 7 13:09:37 2009 Subject: Help with Marvel kernel for 88F6281 In-Reply-To: <4A7C1937.3060000@donhayford.com> References: <49FA5B75.9090008@donhayford.com> <49FADE9B.1080806@donhayford.com> <494D378B-B243-4D97-8554-AC3E74A30B8C@semihalf.com> <49FB8696.8020907@donhayford.com> <72D23F68-EE62-4297-88F4-6CA0132F0293@semihalf.com> <49FF8461.6020406@donhayford.com> <4A7B826B.4040604@donhayford.com> <8DCDD569-1672-4EC9-9E3C-EB08E039EEA6@semihalf.com> <4A7C1937.3060000@donhayford.com> Message-ID: <1F9EB6AF-F5E0-4DA4-A227-8313C1205C46@semihalf.com> Don, Support for SheevaPlug as a diff against recent HEAD is here http://people.freebsd.org/~raj/patches/arm/sheevaplug.diff Note there's a separate kernel config named SHEEVAPLUG, so use this for building your kernel. Let me know if this worked for you. Rafal From raj at semihalf.com Fri Aug 7 13:19:28 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Fri Aug 7 13:19:35 2009 Subject: Help with Marvel kernel for 88F6281 In-Reply-To: <1F9EB6AF-F5E0-4DA4-A227-8313C1205C46@semihalf.com> References: <49FA5B75.9090008@donhayford.com> <49FADE9B.1080806@donhayford.com> <494D378B-B243-4D97-8554-AC3E74A30B8C@semihalf.com> <49FB8696.8020907@donhayford.com> <72D23F68-EE62-4297-88F4-6CA0132F0293@semihalf.com> <49FF8461.6020406@donhayford.com> <4A7B826B.4040604@donhayford.com> <8DCDD569-1672-4EC9-9E3C-EB08E039EEA6@semihalf.com> <4A7C1937.3060000@donhayford.com> <1F9EB6AF-F5E0-4DA4-A227-8313C1205C46@semihalf.com> Message-ID: <88FC923E-4DFE-4F11-9596-DAE543816AB9@semihalf.com> On 2009-08-07, at 15:09, Rafal Jaworowski wrote: > Don, > Support for SheevaPlug as a diff against recent HEAD is here http://people.freebsd.org/~raj/patches/arm/sheevaplug.diff > > Note there's a separate kernel config named SHEEVAPLUG, so use this > for building your kernel. Let me know if this worked for you. Grr, I put a wrong version of the patch, so if you were quick enough you took a broken diff :-) Download the patch again (it's now ok). Rafal From mike at sentex.net Sat Aug 8 20:46:26 2009 From: mike at sentex.net (Mike Tancsa) Date: Sat Aug 8 20:46:33 2009 Subject: USB busdma sync flag fix In-Reply-To: <200908071433.16484.hselasky@c2i.net> References: <200908071433.16484.hselasky@c2i.net> Message-ID: <200908082027.n78KRpoV018525@lava.sentex.ca> At 08:33 AM 8/7/2009, Hans Petter Selasky wrote: >Hi, > >Can people with AMD64 + USB and more than 4GBytes of RAM give the following >patch a shot? > >http://perforce.freebsd.org/chv.cgi?CH=167088 I tried an eToken key, a USB thumb drive and an uplcom device and it seems to work. Latest HEAD with above patch on a box with CPU: AMD Phenom(tm) 9950 Quad-Core Processor (2608.82-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f23 Stepping = 3 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x7ff TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8001216512 (7630 MB) ACPI APIC Table: <051209 APIC1231> 0(freebsd-current2)# usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen6.1: at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen5.1: at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.2: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON 0(freebsd-current2)# ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From raj at semihalf.com Mon Aug 10 09:09:54 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Mon Aug 10 09:10:00 2009 Subject: Help with Marvel kernel for 88F6281 In-Reply-To: <88FC923E-4DFE-4F11-9596-DAE543816AB9@semihalf.com> References: <49FA5B75.9090008@donhayford.com> <49FADE9B.1080806@donhayford.com> <494D378B-B243-4D97-8554-AC3E74A30B8C@semihalf.com> <49FB8696.8020907@donhayford.com> <72D23F68-EE62-4297-88F4-6CA0132F0293@semihalf.com> <49FF8461.6020406@donhayford.com> <4A7B826B.4040604@donhayford.com> <8DCDD569-1672-4EC9-9E3C-EB08E039EEA6@semihalf.com> <4A7C1937.3060000@donhayford.com> <1F9EB6AF-F5E0-4DA4-A227-8313C1205C46@semihalf.com> <88FC923E-4DFE-4F11-9596-DAE543816AB9@semihalf.com> Message-ID: On 2009-08-07, at 15:19, Rafal Jaworowski wrote: > > On 2009-08-07, at 15:09, Rafal Jaworowski wrote: > >> Don, >> Support for SheevaPlug as a diff against recent HEAD is here http://people.freebsd.org/~raj/patches/arm/sheevaplug.diff >> >> Note there's a separate kernel config named SHEEVAPLUG, so use this >> for building your kernel. Let me know if this worked for you. Please download the patch and try again. Two files went missing from the diff, sorry. It should be good now. Rafal From bugmaster at FreeBSD.org Mon Aug 10 11:06:52 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 10 11:07:32 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200908101106.n7AB6pjF025072@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From Yehuda.Marko at windriver.com Wed Aug 12 11:05:52 2009 From: Yehuda.Marko at windriver.com (Marko, Yehuda) Date: Wed Aug 12 11:05:59 2009 Subject: support for Omap3530 Message-ID: <8F65EE73ECB5CC4ABD290D42566CECED025958AB@ism-mail03.corp.ad.wrs.com> Hello gurus, do you know if the last kernel supports bsp for the Mistral 3530 . if yes, where can I find list of available drivers ? for this board TIA, Yehuda Marko From mlfbsd at ci0.org Wed Aug 12 11:47:43 2009 From: mlfbsd at ci0.org (Olivier Houchard) Date: Wed Aug 12 11:48:16 2009 Subject: support for Omap3530 In-Reply-To: <8F65EE73ECB5CC4ABD290D42566CECED025958AB@ism-mail03.corp.ad.wrs.com> References: <8F65EE73ECB5CC4ABD290D42566CECED025958AB@ism-mail03.corp.ad.wrs.com> Message-ID: <20090812111627.GA71173@ci0.org> On Wed, Aug 12, 2009 at 09:40:09AM +0200, Marko, Yehuda wrote: > Hello gurus, > > do you know if the last kernel supports bsp for the Mistral 3530 . > > if yes, where can I find list of available drivers ? for this board > > TIA, > > Hi, As far as I know, nobody actively works on an OMAP port (I may be wrong, though, I remember seeing some discussions about it). Such a port would be very useful, so feel free to work on it :) Regards, Olivier From gballet at gmail.com Wed Aug 12 12:58:30 2009 From: gballet at gmail.com (Guillaume Ballet) Date: Wed Aug 12 12:58:36 2009 Subject: support for Omap3530 Message-ID: > Hi, > > As far as I know, nobody actively works on an OMAP port (I may be wrong, > though, I remember seeing some discussions about it). Such a port would be > very useful, so feel free to work on it :) > > Regards, > > Olivier Hello list, I am still (silently) working on supporting OMAP3, and especially the BeagleBoard. Haven't reached the point where there are much devices supported. If you are only interested in the drivers, though, you should look into the NetBSD tree. Cheers, Guillaume From heiner_ej at yahoo.de Thu Aug 13 09:53:26 2009 From: heiner_ej at yahoo.de (Heiner =?ISO-8859-1?Q?Strau=DF?=) Date: Thu Aug 13 09:53:32 2009 Subject: support for Omap3530 In-Reply-To: References: Message-ID: <1250156422.1174.18.camel@think.ip> Am Mittwoch, den 12.08.2009, 14:31 +0200 schrieb Guillaume Ballet: > > Hi, > > > > As far as I know, nobody actively works on an OMAP port (I may be wrong, > > though, I remember seeing some discussions about it). Such a port would be > > very useful, so feel free to work on it :) > > > > Regards, > > > > Olivier > > Hello list, > > I am still (silently) working on supporting OMAP3, and especially the > BeagleBoard. Haven't reached the point where there are much devices > supported. If you are only interested in the drivers, though, you > should look into the NetBSD tree. > Hi, do you have a kernel configuration ? Which loader do you use ? Do you boot from SD ? I'm at the point to learn nanobsd to generate a boot image. I hope the board will boot it with u-boot from SD. Most links about FreeBSD on Beagleboard are looking like this: http://code.google.com/p/freebsd-bgb/source/checkout :) Greetings, Heiner From mih at semihalf.com Thu Aug 13 13:34:47 2009 From: mih at semihalf.com (Michal Hajduk) Date: Thu Aug 13 13:34:53 2009 Subject: Mounting rootfs from USB - problem. Message-ID: <4A841697.2080909@semihalf.com> Hello Hans, I've observed problem with mounting root filesystem from USB device at ARM platform. In my case the da0 device has showed too late (after Manual root filesystem specification). I've read the previous threads about USB booting problem but there was no final solution for this issue. http://www.nabble.com/new-usb-stack---boot-problem-from-usb-hdd-td23100089.html Maybe you know the best way how to deal with it ? or somebody is trying to fix it? Thanks for help. Best regards, Micha? Hajduk From hselasky at c2i.net Thu Aug 13 14:21:56 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Aug 13 14:22:30 2009 Subject: Mounting rootfs from USB - problem. In-Reply-To: <4A841697.2080909@semihalf.com> References: <4A841697.2080909@semihalf.com> Message-ID: <200908131622.00203.hselasky@c2i.net> On Thursday 13 August 2009 15:35:19 Michal Hajduk wrote: > Hello Hans, > > I've observed problem with mounting root filesystem from USB device at > ARM platform. In my case the da0 device has showed too late > (after Manual root filesystem specification). > > I've read the previous threads about USB booting problem but > there was no final solution for this issue. > > http://www.nabble.com/new-usb-stack---boot-problem-from-usb-hdd-td23100089. >html > > > Maybe you know the best way how to deal with it ? or somebody > is trying to fix it? Hi, The problem is in: src/sys/kern/vfs_mount.c I have suggested a solution where the mount root code is polling for the given device until it arrives. The current device behaviour is the opposite: To wait until all devices are present until mounting anything. I'm currently not involved in any work on this. I would not recommend adding more delay during startup to catch all kinds of USB devices enumerating. --HPS From tinderbox at freebsd.org Fri Aug 14 01:50:08 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Aug 14 01:50:16 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <20090814012536.9CA4E7302F@freebsd-current.sentex.ca> TB --- 2009-08-14 00:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-08-14 00:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-08-14 00:20:00 - cleaning the object tree TB --- 2009-08-14 00:20:35 - cvsupping the source tree TB --- 2009-08-14 00:20:35 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-08-14 00:20:47 - building world TB --- 2009-08-14 00:20:47 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 00:20:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 00:20:47 - TARGET=arm TB --- 2009-08-14 00:20:47 - TARGET_ARCH=arm TB --- 2009-08-14 00:20:47 - TZ=UTC TB --- 2009-08-14 00:20:47 - __MAKE_CONF=/dev/null TB --- 2009-08-14 00:20:47 - cd /src TB --- 2009-08-14 00:20:47 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 14 00:20:50 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 [...] ===> usr.sbin/mfiutil (all) cc -O -pipe -fno-builtin-strftime -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/usr.sbin/mfiutil/mfiutil.c cc -O -pipe -fno-builtin-strftime -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/usr.sbin/mfiutil/mfi_cmd.c cc -O -pipe -fno-builtin-strftime -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/usr.sbin/mfiutil/mfi_config.c cc -O -pipe -fno-builtin-strftime -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/usr.sbin/mfiutil/mfi_drive.c cc1: warnings being treated as errors /src/usr.sbin/mfiutil/mfi_drive.c: In function 'mfi_lookup_drive': /src/usr.sbin/mfiutil/mfi_drive.c:120: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.sbin/mfiutil. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-08-14 01:25:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-08-14 01:25:36 - ERROR: failed to build world TB --- 2009-08-14 01:25:36 - 3030.63 user 369.23 system 3935.36 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From tinderbox at freebsd.org Fri Aug 14 09:46:06 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Aug 14 09:46:13 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <20090814094602.D210F7302F@freebsd-current.sentex.ca> TB --- 2009-08-14 08:40:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-08-14 08:40:01 - starting HEAD tinderbox run for arm/arm TB --- 2009-08-14 08:40:01 - cleaning the object tree TB --- 2009-08-14 08:40:37 - cvsupping the source tree TB --- 2009-08-14 08:40:37 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-08-14 08:40:45 - building world TB --- 2009-08-14 08:40:45 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 08:40:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 08:40:45 - TARGET=arm TB --- 2009-08-14 08:40:45 - TARGET_ARCH=arm TB --- 2009-08-14 08:40:45 - TZ=UTC TB --- 2009-08-14 08:40:45 - __MAKE_CONF=/dev/null TB --- 2009-08-14 08:40:45 - cd /src TB --- 2009-08-14 08:40:45 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 14 08:40:49 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 [...] ===> usr.sbin/mfiutil (all) cc -O -pipe -fno-builtin-strftime -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/usr.sbin/mfiutil/mfiutil.c cc -O -pipe -fno-builtin-strftime -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/usr.sbin/mfiutil/mfi_cmd.c cc -O -pipe -fno-builtin-strftime -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/usr.sbin/mfiutil/mfi_config.c cc -O -pipe -fno-builtin-strftime -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/usr.sbin/mfiutil/mfi_drive.c cc1: warnings being treated as errors /src/usr.sbin/mfiutil/mfi_drive.c: In function 'mfi_lookup_drive': /src/usr.sbin/mfiutil/mfi_drive.c:120: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.sbin/mfiutil. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-08-14 09:46:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-08-14 09:46:02 - ERROR: failed to build world TB --- 2009-08-14 09:46:02 - 3030.92 user 369.27 system 3961.52 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From bugmaster at FreeBSD.org Mon Aug 17 11:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 17 11:07:24 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200908171106.n7HB6owl075715@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From xiechao.mail at gmail.com Wed Aug 19 01:40:33 2009 From: xiechao.mail at gmail.com (Chao Xie) Date: Wed Aug 19 01:40:39 2009 Subject: nand and filesystem support at Freebsd-arm Message-ID: hi Does anyone know whether there is any solution for NAND support at freebsd-arm? It is not complicated to add NAND driver, but the filesystem support may be a problem. As i know that Linux has JFFS2 and YAFFS to support filesystem at NAND. How about filesystem for NAND at freebsd-arm? From stas at FreeBSD.org Wed Aug 19 08:49:24 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Wed Aug 19 08:49:31 2009 Subject: nand and filesystem support at Freebsd-arm In-Reply-To: References: Message-ID: <20090819124918.433f6f72.stas@FreeBSD.org> On Wed, 19 Aug 2009 09:40:32 +0800 Chao Xie mentioned: > hi > Does anyone know whether there is any solution for NAND support at > freebsd-arm? > It is not complicated to add NAND driver, but the filesystem support may be > a problem. > As i know that Linux has JFFS2 and YAFFS to support filesystem at NAND. How > about filesystem for NAND at freebsd-arm? As far as I know currently there're no flash-optimised filesystems available on FreeBSD as well as working NAND drivers. But there'we some work going on it on the past. Try looking through archives. I suspect Semihalf may be doing some work on NAND drivers/filesystem on FreeBSD but I don't know any details yet. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090819/e20204ae/attachment.pgp From tinderbox at freebsd.org Wed Aug 19 12:30:32 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Aug 19 12:30:59 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <200908191230.n7JCU0Vq001096@freebsd-current2.sentex.ca> TB --- 2009-08-19 12:30:00 - tinderbox 2.6 running on freebsd-current2.sentex.ca TB --- 2009-08-19 12:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-08-19 12:30:00 - mkdir /tinderbox/HEAD TB --- 2009-08-19 12:30:00 - ERROR: /tinderbox/HEAD/arm/arm: File exists TB --- 2009-08-19 12:30:00 - 0.02 user 0.01 system 0.02 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From rafael at lk6.com.br Thu Aug 20 19:09:34 2009 From: rafael at lk6.com.br (Rafael Mentz Aquino) Date: Thu Aug 20 19:09:41 2009 Subject: Marvel Sheevaplug Message-ID: <59898be6a9ea3e4896f5c062a55eb7ba@webmail.lk6.com.br> Good Afternoon, O bought one Marvel Sheevaplug. I already created the cross-compiled world, but when I try to compile kernel SHEEVAPLUG, I got an error. I already applied the patch according to the thread below: http://lists.freebsd.org/pipermail/freebsd-arm/2009-August/001918.html Without the patch, I can compile kernel 88F6XXX, but freezes when I try to use it at sheevaplug. After I applied the patch none of those kernels compile correctely. I'm using FreeBSD 8-BETA2 source. Any help? Thanks!!!! -- Rafael Mentz Aquino LK6 Inform?tica Ltda. 051 - 4063 6269 From raj at semihalf.com Thu Aug 20 19:26:36 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Thu Aug 20 19:26:42 2009 Subject: Marvel Sheevaplug In-Reply-To: <59898be6a9ea3e4896f5c062a55eb7ba@webmail.lk6.com.br> References: <59898be6a9ea3e4896f5c062a55eb7ba@webmail.lk6.com.br> Message-ID: <6AF5CD36-1B59-407C-994C-7D68F46F9227@semihalf.com> On 2009-08-20, at 20:54, Rafael Mentz Aquino wrote: > Good Afternoon, > > O bought one Marvel Sheevaplug. I already created the cross-compiled > world, > but when I try to compile kernel SHEEVAPLUG, I got an error. I already > applied Please include error messages you observe. I received a confirmation from Donald Hayford that the patch worked fine for him with sources around Aug 15. The patch as is would not apply cleanly however for very recent HEAD as some of the changes from the diff were committed individually to the tree. I'll try to come up with an udated version against recent? HEAD tomorrow. > the patch according to the thread below: > > http://lists.freebsd.org/pipermail/freebsd-arm/2009-August/001918.html > > Without the patch, I can compile kernel 88F6XXX, but freezes when I > try to use it at sheevaplug. Don't use the DB- config for SP, it won't work. Rafal From rafael at lk6.com.br Fri Aug 21 10:45:53 2009 From: rafael at lk6.com.br (Rafael Mentz Aquino) Date: Fri Aug 21 10:46:01 2009 Subject: Marvel Sheevaplug In-Reply-To: <6AF5CD36-1B59-407C-994C-7D68F46F9227@semihalf.com> Message-ID: Hi, there, I was doing my tests inside a virtual machine. As long as I don?t know if that was a problem, I decided to start from scratch. Using a real machine, after cvsup to FreeBSD-8-BETA2, I apllied the patch, and was able to compile the SHEEVAPLUG kernel sucessfully, but after load into 90000 address position, it hangs when I run the command "go". Here is the result of map command. Marvell>> map CPU Interface ------------- SDRAM_CS0 ....base 00000000, size 256MB SDRAM_CS1 ....base 10000000, size 256MB SDRAM_CS2 ....disable SDRAM_CS3 ....disable PEX0_MEM ....base 90000000, size 256MB PEX0_IO ....base f0000000, size 16MB INTER_REGS ....base f1000000, size 1MB NFLASH_CS ....base f9000000, size 8MB SPI_CS ....base f8000000, size 16MB BOOT_ROM_CS ....base ff000000, size 16MB DEV_BOOTCS ....base ff000000, size 16MB CRYPT_ENG ....base fb000000, size 64KB AHB To MBUS Bridge: ------------------- win0 - PEX0_MEM base 90000000, ....size 256MB win1 - NFLASH_CS base f9000000, ....size 8MB win2 - PEX0_IO base f0000000, ....size 16MB win3 - SPI_CS base f8000000, ....size 16MB win4 - BOOT_ROM_CS base ff000000, ....size 16MB win5 - disable win6 - disable win7 - CRYPT_ENG base fb000000, ....size 64KB win8 - INTER_REGS base f1000000, ....size 1MB PEX0: ----- Pex Bars Internal Regs Bar0.... base f1000000, size 1MB DRAM Bar1............. base 00000000, size 512MB Devices Bar2.......... disable Pex Decode Windows win0 - SDRAM_CS0 base 00000000, ....size 256MB win1 - SDRAM_CS1 base 10000000, ....size 256MB win2 - disable win3 - disable win4 - disable win5 - disable default win - target unknown Expansion ROM - NFLASH_CS USB: ---- Device 0: win0 - SDRAM_CS0 base 00000000, size 256MB win1 - SDRAM_CS1 base 10000000, size 256MB win2 - PEX0_MEM base 90000000, size 256MB win3 - disable ETH 0: ---- win0 - SDRAM_CS0 base 00000000, ....size 256MB win1 - SDRAM_CS1 base 10000000, ....size 256MB win2 - NFLASH_CS base f9000000, ....size 8MB win3 - SPI_CS base f8000000, ....size 16MB win4 - BOOT_ROM_CS base ff000000, ....size 16MB win5 - disable ETH 1: ---- win0 - SDRAM_CS0 base 00000000, ....size 256MB win1 - SDRAM_CS1 base 10000000, ....size 256MB win2 - NFLASH_CS base f9000000, ....size 8MB win3 - SPI_CS base f8000000, ....size 16MB win4 - BOOT_ROM_CS base ff000000, ....size 16MB win5 - disable XOR 0: ---- win0 - NFLASH_CS base f9000000, size 8MB win1 - PEX0_MEM base 90000000, size 256MB win2 - SDRAM_CS0 base 0, size 256MB win3 - SDRAM_CS1 base 10000000, size 256MB win4 - SPI_CS base f8000000, size 16MB win5 - CRYPT_ENG base fb000000, size 64KB win6 - disable win7 - disable XOR 1: ---- win0 - NFLASH_CS base f9000000, size 8MB win1 - PEX0_MEM base 90000000, size 256MB win2 - SDRAM_CS0 base 0, size 256MB win3 - SDRAM_CS1 base 10000000, size 256MB win4 - SPI_CS base f8000000, size 16MB win5 - CRYPT_ENG base fb000000, size 64KB win6 - disable win7 - disable AUDIO: ---- win0 - SDRAM_CS0 base 00000000, ....size 256MB win1 - SDRAM_CS1 base 10000000, ....size 256MB Marvell>> The size of kernel.bin is 2728820. Marvell>> dhcp BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 52 *** Unhandled DHCP Option in OFFER/ACK: 52 DHCP client bound to address 192.168.2.103 Marvell>> set serverip 192.168.2.10 Marvell>> tftpboot 90000 kernel.bin Using egiga0 device TFTP from server 192.168.2.10; our IP address is 192.168.2.103 Filename 'kernel.bin'. Load address: 0x90000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############# done Bytes transferred = 2728820 (29a374 hex) Marvell>> go 90000 ## Starting application at 0x00090000 ... (after that... nothing...) Thanks again!!! Rafael Mentz Aquino ----------------mensagem original----------------- De: "Rafal Jaworowski" raj@semihalf.com Para: "Rafael Mentz Aquino" rafael@lk6.com.br cc: freebsd-arm@freebsd.org Data: Thu, 20 Aug 2009 21:26:34 +0200 ------------------------------------------------- > > On 2009-08-20, at 20:54, Rafael Mentz Aquino wrote: > >> Good Afternoon, >> >> O bought one Marvel Sheevaplug. I already created the cross-compiled >> world, >> but when I try to compile kernel SHEEVAPLUG, I got an error. I already >> applied > > Please include error messages you observe. I received a confirmation > from Donald Hayford that the patch worked fine for him with sources > around Aug 15. > > The patch as is would not apply cleanly however for very recent HEAD > as some of the changes from the diff were committed individually to > the tree. I'll try to come up with an udated version against recent? > HEAD tomorrow. > >> the patch according to the thread below: >> >> >> http://lists.freebsd.org/pipermail/freebsd-arm/2009-August/001918. >> html >> >> Without the patch, I can compile kernel 88F6XXX, but freezes when I >> try to use it at sheevaplug. > > Don't use the DB- config for SP, it won't work. > > Rafal > > > -- > Esta mensagem foi verificada pelo sistema de antiv?rus e > acredita-se estar livre de perigo. > > -- Rafael Mentz Aquino LK6 Inform?tica Ltda. 051 - 4063 6269 From rafael at lk6.com.br Fri Aug 21 15:58:33 2009 From: rafael at lk6.com.br (Rafael Mentz Aquino) Date: Fri Aug 21 15:58:41 2009 Subject: Marvel Sheevaplug In-Reply-To: <4A8EBAD5.9070300@donhayford.com> Message-ID: <36a915007ca245796a07afc26c2fade9@webmail.lk6.com.br> It worked!!!!! Thanks again!!!! Now I?ll play for a while with some options, and then I?ll post here my results. Thanks agains!!!! Rafael Mentz Aquino ----------------mensagem original----------------- De: "Donald T Hayford" don@donhayford.com Para: "Rafael Mentz Aquino" rafael@lk6.com.br cc: "Rafal Jaworowski" raj@semihalf.com, freebsd-arm@freebsd.org Data: Fri, 21 Aug 2009 11:18:45 -0400 ------------------------------------------------- > Rafael Mentz Aquino wrote: >> Marvell>> dhcp >> BOOTP broadcast 1 >> *** Unhandled DHCP Option in OFFER/ACK: 52 >> *** Unhandled DHCP Option in OFFER/ACK: 52 >> DHCP client bound to address 192.168.2.103 >> Marvell>> set serverip 192.168.2.10 >> Marvell>> tftpboot 90000 kernel.bin >> Using egiga0 device >> TFTP from server 192.168.2.10; our IP address is 192.168.2.103 >> Filename 'kernel.bin'. >> Load address: 0x90000 >> Loading: >> ################################################################# >> >> ################################################################# >> >> ################################################################# >> >> ################################################################# >> >> ################################################################# >> >> ################################################################# >> >> ################################################################# >> >> ################################################################# >> ############# >> done >> Bytes transferred = 2728820 (29a374 hex) >> Marvell>> go 90000 >> ## Starting application at 0x00090000 ... >> > Try a load address of 0x900000, not 0x90000. > Regards, > Don > > -- > Esta mensagem foi verificada pelo sistema de antiv?rus e > acredita-se estar livre de perigo. > > -- Rafael Mentz Aquino LK6 Inform?tica Ltda. 051 - 4063 6269 From rcm at fuzzwad.org Sun Aug 23 15:41:24 2009 From: rcm at fuzzwad.org (Ron McDowell) Date: Sun Aug 23 15:41:31 2009 Subject: Marvel Sheevaplug In-Reply-To: <6AF5CD36-1B59-407C-994C-7D68F46F9227@semihalf.com> References: <59898be6a9ea3e4896f5c062a55eb7ba@webmail.lk6.com.br> <6AF5CD36-1B59-407C-994C-7D68F46F9227@semihalf.com> Message-ID: <4A915A5C.201@fuzzwad.org> Rafal Jaworowski wrote: > /The patch as is would not apply cleanly however for very recent HEAD > as some of the changes from the diff were committed individually to > the tree. I'll try to come up with an udated version against recent? > HEAD tomorrow./ I applied the patch at http://people.freebsd.org/~raj/patches/arm/sheevaplug.diff to a RELENG_8 tree pulled around 8pm CDT 22 Aug 09. The last hunk of the last patch was the only one to fail, but it was easy to locate and apply manually. uname -a of my build system: FreeBSD zombie.volente.us 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Mon Jul 6 01:50:51 CDT 2009 rcm@zombie:/Stash/Work/FreeBSD/Sources/obj/Stash/Work/FreeBSD/Sources/src/sys/GENERIC i386 [I am unable to upgrade the build machine to 8 because of other things running on it.] The build complains of no machine/vm.h or arm/mv/mvwin.h. At this point in the build, I have the following vm.h files: /usr/include/vm/vm.h /Stash/Sheeva/FreeBSD8/dest/usr/include/vm/vm.h /Stash/Sheeva/FreeBSD8/src/sys/vm/vm.h /Stash/Sheeva/FreeBSD8/obj/arm/Stash/Sheeva/FreeBSD8/src/tmp/usr/include/vm/vm.h ...but none of them are in a machine directory. The only mvwin.h file is /Stash/Work/FreeBSD/Sources/src/sys/arm/mv/mvwin.h Here's my output with errors at the end. Ideas? Thanks in advance. --rcm + cd /Sheeva/FreeBSD8/ + . .env + export MAKEOBJDIRPREFIX=/Sheeva/FreeBSD8/obj + export TARGET_ARCH=arm + export DESTDIR=/Sheeva/FreeBSD8/dest + export KERNCONF=SHEEVAPLUG + cd /Sheeva/FreeBSD8/src + make -j4 buildworld -------------------------------------------------------------- >>> World build started on Sat Aug 22 23:00:38 CDT 2009 -------------------------------------------------------------- [huge snip] + make buildkernel -------------------------------------------------------------- >>> Kernel build for SHEEVAPLUG started on Sun Aug 23 00:51:08 CDT 2009 -------------------------------------------------------------- ===> SHEEVAPLUG mkdir -p /Sheeva/FreeBSD8/obj/arm/Stash/Sheeva/FreeBSD8/src/sys -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- [snip] -------------------------------------------------------------- >>> stage 3.1: making dependencies -------------------------------------------------------------- [snip] rm -f .newdep make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -mlittle-endian -E" CC="cc -mlittle-endian" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/Stash/Sheeva/FreeBSD8/src/sys -I/Stash/Sheeva/FreeBSD8/src/sys/contrib/altq -I/Stash/Sheeva/FreeBSD8/src/sys/contrib/ipfilter -I/Stash/Sheeva/FreeBSD8/src/sys/contrib/pf -I/Stash/ Sheeva/FreeBSD8/src/sys/dev/ath -I/Stash/Sheeva/FreeBSD8/src/sys/dev/ath/ath_hal -I/Stash/Sheeva/FreeBSD8/src/sys/contrib/ngatm -I/Stash/Sheeva/FreeBSD8/src/sys/dev/twa -I/Stash/Sheeva/FreeBSD8/src/sys/gnu/fs/xfs/FreeBSD -I/Stash/Sheeva/FreeBSD8/src/sys/gnu/fs/xfs/FreeB SD/support -I/Stash/Sheeva/FreeBSD8/src/sys/gnu/fs/xfs -I/Stash/Sheeva/FreeBSD8/src/sys/contrib/opensolaris/compat -I/Stash/Sheeva/FreeBSD8/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit- growth=100 --param large-function-growth=1000 -march=armv5te -ffreestanding In file included from /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/common.c:44: /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/mvvar.h:47:24: error: machine/vm.h: No such file or directory In file included from /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/gpio.c:49: /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/mvvar.h:47:24: error: machine/vm.h: No such file or directory In file included from /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/ic.c:44: /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/mvvar.h:47:24: error: machine/vm.h: No such file or directory In file included from /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/mv_machdep.c:88: /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/mvvar.h:47:24: error: machine/vm.h: No such file or directory /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/mv_machdep.c:89:26: error: arm/mv/mvwin.h: No such file or directory In file included from /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/obio.c:40: /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/mvvar.h:47:24: error: machine/vm.h: No such file or directory In file included from /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/timer.c:49: /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/mvvar.h:47:24: error: machine/vm.h: No such file or directory In file included from /Stash/Sheeva/FreeBSD8/src/sys/dev/mge/if_mge.c:78: /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/mvvar.h:47:24: error: machine/vm.h: No such file or directory In file included from /Stash/Sheeva/FreeBSD8/src/sys/dev/uart/uart_bus_mbus.c:50: /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/mvvar.h:47:24: error: machine/vm.h: No such file or directory In file included from /Stash/Sheeva/FreeBSD8/src/sys/dev/uart/uart_cpu_mv.c:48: /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/mvvar.h:47:24: error: machine/vm.h: No such file or directory In file included from /Stash/Sheeva/FreeBSD8/src/sys/dev/usb/controller/ehci_mbus.c:55: /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/mvvar.h:47:24: error: machine/vm.h: No such file or directory In file included from /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/kirkwood/kirkwood.c:42: /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/mvvar.h:47:24: error: machine/vm.h: No such file or directory In file included from /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/kirkwood/sheevaplug.c:48: /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/mvvar.h:47:24: error: machine/vm.h: No such file or directory /Stash/Sheeva/FreeBSD8/src/sys/arm/mv/kirkwood/sheevaplug.c:49:26: error: arm/mv/mvwin.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /Stash/Sheeva/FreeBSD8/obj/arm/Stash/Sheeva/FreeBSD8/src/sys/SHEEVAPLUG. *** Error code 1 Stop in /Stash/Sheeva/FreeBSD8/src. *** Error code 1 Stop in /Stash/Sheeva/FreeBSD8/src. -- Ron McDowell San Antonio TX From rcm at fuzzwad.org Sun Aug 23 16:57:50 2009 From: rcm at fuzzwad.org (Ron McDowell) Date: Sun Aug 23 16:57:55 2009 Subject: Marvel Sheevaplug In-Reply-To: <4A915A5C.201@fuzzwad.org> References: <59898be6a9ea3e4896f5c062a55eb7ba@webmail.lk6.com.br> <6AF5CD36-1B59-407C-994C-7D68F46F9227@semihalf.com> <4A915A5C.201@fuzzwad.org> Message-ID: <4A91750F.30401@fuzzwad.org> Replying to my own post here... :) Ron McDowell wrote: > I applied the patch at > http://people.freebsd.org/~raj/patches/arm/sheevaplug.diff to a > RELENG_8 tree pulled around 8pm CDT 22 Aug 09. The last hunk of the > last patch was the only one to fail, but it was easy to locate and > apply manually. I pulled the sheevaplug.diff file at roughly the same time. > > uname -a of my build system: > > FreeBSD zombie.volente.us 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: > Mon Jul 6 01:50:51 CDT 2009 > rcm@zombie:/Stash/Work/FreeBSD/Sources/obj/Stash/Work/FreeBSD/Sources/src/sys/GENERIC > i386 /Sheeva below is a symlink to /Stash/Sheeva > The build complains of no machine/vm.h or arm/mv/mvwin.h. > > At this point in the build, I have the following vm.h files: > > /usr/include/vm/vm.h > /Stash/Sheeva/FreeBSD8/dest/usr/include/vm/vm.h > /Stash/Sheeva/FreeBSD8/src/sys/vm/vm.h > /Stash/Sheeva/FreeBSD8/obj/arm/Stash/Sheeva/FreeBSD8/src/tmp/usr/include/vm/vm.h > > > ...but none of them are in a machine directory. > > The only mvwin.h file is > /Stash/Work/FreeBSD/Sources/src/sys/arm/mv/mvwin.h ...and that mvwin.h file, I see now, is in my 7.2-p2 source tree, not in the 8.0 tree I'm building SHEEVAPLUG from. -- Ron McDowell San Antonio TX From raj at semihalf.com Sun Aug 23 19:34:53 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Sun Aug 23 19:34:59 2009 Subject: Marvel Sheevaplug In-Reply-To: <4A91750F.30401@fuzzwad.org> References: <59898be6a9ea3e4896f5c062a55eb7ba@webmail.lk6.com.br> <6AF5CD36-1B59-407C-994C-7D68F46F9227@semihalf.com> <4A915A5C.201@fuzzwad.org> <4A91750F.30401@fuzzwad.org> Message-ID: <32A7FFAC-8883-4BF9-ABE3-6299FEB5F811@semihalf.com> On 2009-08-23, at 18:57, Ron McDowell wrote: > Replying to my own post here... :) > > Ron McDowell wrote: >> I applied the patch at http://people.freebsd.org/~raj/patches/arm/sheevaplug.diff >> to a RELENG_8 tree pulled around 8pm CDT 22 Aug 09. The last hunk >> of the last patch was the only one to fail, but it was easy to >> locate and apply manually. > > I pulled the sheevaplug.diff file at roughly the same time. As noted earlier, the indicated SheevaPlug patch would only work for HEAD from Aug 15 tree. >> >> uname -a of my build system: >> >> FreeBSD zombie.volente.us 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: >> Mon Jul 6 01:50:51 CDT 2009 rcm@zombie:/Stash/Work/FreeBSD/ >> Sources/obj/Stash/Work/FreeBSD/Sources/src/sys/GENERIC i386 > > /Sheeva below is a symlink to /Stash/Sheeva > >> The build complains of no machine/vm.h or arm/mv/mvwin.h. >> >> At this point in the build, I have the following vm.h files: >> >> /usr/include/vm/vm.h >> /Stash/Sheeva/FreeBSD8/dest/usr/include/vm/vm.h >> /Stash/Sheeva/FreeBSD8/src/sys/vm/vm.h >> /Stash/Sheeva/FreeBSD8/obj/arm/Stash/Sheeva/FreeBSD8/src/tmp/usr/ >> include/vm/vm.h >> >> ...but none of them are in a machine directory. >> >> The only mvwin.h file is >> /Stash/Work/FreeBSD/Sources/src/sys/arm/mv/mvwin.h > > ...and that mvwin.h file, I see now, is in my 7.2-p2 source tree, > not in the 8.0 tree I'm building SHEEVAPLUG from. This seems odd. 7.x does not have Marvell ARM support, so you should not have the sys/arm/mv directory in 7.2 tree. Rafal From don at donhayford.com Sun Aug 23 21:09:13 2009 From: don at donhayford.com (Donald T Hayford) Date: Sun Aug 23 21:09:19 2009 Subject: Marvel Sheevaplug In-Reply-To: <32A7FFAC-8883-4BF9-ABE3-6299FEB5F811@semihalf.com> References: <59898be6a9ea3e4896f5c062a55eb7ba@webmail.lk6.com.br> <6AF5CD36-1B59-407C-994C-7D68F46F9227@semihalf.com> <4A915A5C.201@fuzzwad.org> <4A91750F.30401@fuzzwad.org> <32A7FFAC-8883-4BF9-ABE3-6299FEB5F811@semihalf.com> Message-ID: <4A91AFF2.40508@donhayford.com> Rafal Jaworowski wrote: > > On 2009-08-23, at 18:57, Ron McDowell wrote: > >> Replying to my own post here... :) >> >> Ron McDowell wrote: >>> I applied the patch at >>> http://people.freebsd.org/~raj/patches/arm/sheevaplug.diff to a >>> RELENG_8 tree pulled around 8pm CDT 22 Aug 09. The last hunk of the >>> last patch was the only one to fail, but it was easy to locate and >>> apply manually. >> >> I pulled the sheevaplug.diff file at roughly the same time. > > As noted earlier, the indicated SheevaPlug patch would only work for > HEAD from Aug 15 tree. If it makes any difference, Rafal, the email you sent me about the patch was dated 2009/8/7 (or 8/7/2009 here in the US), so presumably the diff is from about the same time. You can add a date tag to your supfile if you want to get the source from that date. Don From rcm at fuzzwad.org Mon Aug 24 00:12:41 2009 From: rcm at fuzzwad.org (Ron McDowell) Date: Mon Aug 24 00:12:47 2009 Subject: Marvel Sheevaplug In-Reply-To: <32A7FFAC-8883-4BF9-ABE3-6299FEB5F811@semihalf.com> References: <59898be6a9ea3e4896f5c062a55eb7ba@webmail.lk6.com.br> <6AF5CD36-1B59-407C-994C-7D68F46F9227@semihalf.com> <4A915A5C.201@fuzzwad.org> <4A91750F.30401@fuzzwad.org> <32A7FFAC-8883-4BF9-ABE3-6299FEB5F811@semihalf.com> Message-ID: <4A91DAEF.3060109@fuzzwad.org> Rafal Jaworowski wrote: > As noted earlier, the indicated SheevaPlug patch would only work for > HEAD from Aug 15 tree. How can I fetch the correct branch? I'm not new to FreeBSD but am new to dealing with ver 8. Thanks. -- Ron McDowell San Antonio TX From don at donhayford.com Mon Aug 24 02:59:15 2009 From: don at donhayford.com (Donald T Hayford) Date: Mon Aug 24 02:59:22 2009 Subject: Marvel Sheevaplug In-Reply-To: <4A91DAEF.3060109@fuzzwad.org> References: <59898be6a9ea3e4896f5c062a55eb7ba@webmail.lk6.com.br> <6AF5CD36-1B59-407C-994C-7D68F46F9227@semihalf.com> <4A915A5C.201@fuzzwad.org> <4A91750F.30401@fuzzwad.org> <32A7FFAC-8883-4BF9-ABE3-6299FEB5F811@semihalf.com> <4A91DAEF.3060109@fuzzwad.org> Message-ID: <4A9201F8.9000705@donhayford.com> Ron McDowell wrote: > Rafal Jaworowski wrote: >> As noted earlier, the indicated SheevaPlug patch would only work for >> HEAD from Aug 15 tree. > > How can I fetch the correct branch? I'm not new to FreeBSD but am new > to dealing with ver 8. Thanks. > My sheeva.supfile looks like: *default host=cvsup8.FreeBSD.org *default base=/var/db *default prefix=/your-directory-name *default release=cvs tag=. date=2009.08.09.00.00.00 *default delete use-rel-suffix *default compress src-all Then do: csup sheeva.supfile Don From bugmaster at FreeBSD.org Mon Aug 24 11:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 24 11:07:36 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200908241106.n7OB6oat048484@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From raj at semihalf.com Mon Aug 24 13:29:56 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Mon Aug 24 13:30:03 2009 Subject: Marvel Sheevaplug In-Reply-To: <4A91AFF2.40508@donhayford.com> References: <59898be6a9ea3e4896f5c062a55eb7ba@webmail.lk6.com.br> <6AF5CD36-1B59-407C-994C-7D68F46F9227@semihalf.com> <4A915A5C.201@fuzzwad.org> <4A91750F.30401@fuzzwad.org> <32A7FFAC-8883-4BF9-ABE3-6299FEB5F811@semihalf.com> <4A91AFF2.40508@donhayford.com> Message-ID: On 2009-08-23, at 23:09, Donald T Hayford wrote: > Rafal Jaworowski wrote: >> >> On 2009-08-23, at 18:57, Ron McDowell wrote: >> >>> Replying to my own post here... :) >>> >>> Ron McDowell wrote: >>>> I applied the patch at http://people.freebsd.org/~raj/patches/arm/sheevaplug.diff >>>> to a RELENG_8 tree pulled around 8pm CDT 22 Aug 09. The last >>>> hunk of the last patch was the only one to fail, but it was easy >>>> to locate and apply manually. >>> >>> I pulled the sheevaplug.diff file at roughly the same time. >> >> As noted earlier, the indicated SheevaPlug patch would only work >> for HEAD from Aug 15 tree. > If it makes any difference, Rafal, the email you sent me about the > patch was dated 2009/8/7 (or 8/7/2009 here in the US), so presumably > the diff is from about the same time. > You can add a date tag to your supfile if you want to get the source > from that date. The patch http://people.freebsd.org/~raj/patches/arm/sheevaplug.diff is updated to work with today's HEAD. I'm going to commit this to SVN some time soon. Rafal From rcm at fuzzwad.org Mon Aug 24 16:11:02 2009 From: rcm at fuzzwad.org (Ron McDowell) Date: Mon Aug 24 16:11:09 2009 Subject: Marvel Sheevaplug In-Reply-To: References: <59898be6a9ea3e4896f5c062a55eb7ba@webmail.lk6.com.br> <6AF5CD36-1B59-407C-994C-7D68F46F9227@semihalf.com> <4A915A5C.201@fuzzwad.org> <4A91750F.30401@fuzzwad.org> <32A7FFAC-8883-4BF9-ABE3-6299FEB5F811@semihalf.com> <4A91AFF2.40508@donhayford.com> Message-ID: <4A92BB93.80009@fuzzwad.org> My thanks to Donald for supplying me the missing date tag for my sup file. With that I was able to get all the way through the build. Since I'm just getting started I will pull a new source tree today and try Rafal's new patch. I'll report back late this afternoon. -- Ron McDowell San Antonio TX Rafal Jaworowski wrote: > The patch http://people.freebsd.org/~raj/patches/arm/sheevaplug.diff > is updated to work with today's HEAD. I'm going to commit this to SVN > some time soon. > > Rafal From rcm at fuzzwad.org Mon Aug 24 23:09:05 2009 From: rcm at fuzzwad.org (Ron McDowell) Date: Mon Aug 24 23:09:11 2009 Subject: Marvel Sheevaplug In-Reply-To: <4A92BB93.80009@fuzzwad.org> References: <59898be6a9ea3e4896f5c062a55eb7ba@webmail.lk6.com.br> <6AF5CD36-1B59-407C-994C-7D68F46F9227@semihalf.com> <4A915A5C.201@fuzzwad.org> <4A91750F.30401@fuzzwad.org> <32A7FFAC-8883-4BF9-ABE3-6299FEB5F811@semihalf.com> <4A91AFF2.40508@donhayford.com> <4A92BB93.80009@fuzzwad.org> Message-ID: <4A931D91.5070807@fuzzwad.org> It built fine with code pulled [*default release=cvs tag=. date=2009.08.24.00.00.00"] Unfortunately, one of my associates "borrowed" my Sheevaplug, so I won't be able to boot it til tomorrow. Sigh... co-workers... :) -- Ron McDowell San Antonio TX Ron McDowell wrote: > Since I'm just getting started I will pull a new source tree today and > try Rafal's new patch. I'll report back late this afternoon. From raj at semihalf.com Tue Aug 25 10:12:53 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Tue Aug 25 10:13:00 2009 Subject: Marvel Sheevaplug In-Reply-To: References: <59898be6a9ea3e4896f5c062a55eb7ba@webmail.lk6.com.br> <6AF5CD36-1B59-407C-994C-7D68F46F9227@semihalf.com> <4A915A5C.201@fuzzwad.org> <4A91750F.30401@fuzzwad.org> <32A7FFAC-8883-4BF9-ABE3-6299FEB5F811@semihalf.com> <4A91AFF2.40508@donhayford.com> Message-ID: <02DF2360-2117-49A5-9E25-F09563F234E7@semihalf.com> On 2009-08-24, at 15:29, Rafal Jaworowski wrote: > The patch http://people.freebsd.org/~raj/patches/arm/sheevaplug.diff > is updated to work with today's HEAD. I'm going to commit this to > SVN some time soon. FYI: as of r196536 SheevaPlug support is in the SVN tree. Enjoy! Rafal From gballet at gmail.com Sun Aug 30 15:54:21 2009 From: gballet at gmail.com (Guillaume Ballet) Date: Sun Aug 30 15:54:27 2009 Subject: support for Omap3530 Message-ID: > Hi, > do you have a kernel configuration ? Which loader do you use ? Do you > boot from SD ? I'm at the point to learn nanobsd to generate a boot > image. I hope the board will boot it with u-boot from SD. I am indeed booting from the SD card with u-boot, and then with a simplistic custom loader. I plan on porting loader(8) but the kernel is too time consuming for the moment. I remember reading some slides by Rafal Jaworowski on how to have u-boot run loader(8), but I didn't have the time yet to investigate if this went further. Once the capability exists, I guess it is fairly easy to tell loader(8) to fetch the kernel on a FAT partition. It would save me a lot of typing for sure :P Regarding the kernel configuration, I am not at a stage where the kernel finishes booting, so it won't be of much use to you at the moment. I will keep you posted when I manage to the end of the kernel init. Guillaume From bugmaster at FreeBSD.org Mon Aug 31 11:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 31 11:07:35 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200908311107.n7VB71kq070482@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total.