From jacques.fourie at gmail.com Wed Jan 7 14:42:28 2009 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Wed Jan 7 14:42:34 2009 Subject: hwpmc on xscale (pxa255) Message-ID: I am interested in making hwpmc work on my gumstix (pxa255 cpu). Does anyone have working examples of pmc_save_kernel_callchain() and pmc_save_user_callchain() for arm platforms that they are willing to share? From stas at FreeBSD.org Wed Jan 7 17:39:21 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Wed Jan 7 17:39:28 2009 Subject: svn commit: r186730 - in head: lib/libusb20 sys/dev/usb2/controller sys/dev/usb2/core sys/dev/usb2/ethernet sys/dev/usb2/image sys/dev/usb2/include sys/dev/usb2/serial sys/dev/usb2/sound sys/dev/us... In-Reply-To: <200901071751.49494.hselasky@c2i.net> References: <200901040012.n040C2gH040928@svn.freebsd.org> <200901071519.23311.hselasky@c2i.net> <20090107172310.bf12fe39.stas@FreeBSD.org> <200901071751.49494.hselasky@c2i.net> Message-ID: <20090107202901.21df29e3.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 7 Jan 2009 17:51:48 +0100 Hans Petter Selasky mentioned: > > cpu_idcache_wbinv_all(); /* and this line */ > > bus_dmamap_sync(pc->tag, pc->map, > BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD); > } > > Then everything worked. > > I think the ones that have been working on busdma & cache sync issues recently > are to blame. I will try to investigate more. > Hmm, this might be the same problem with duplicate dcache entries raj reported recently on arm@. I tried replacing cpu_idcache_wbinv_all with busdma PREREAD and PREWRITE sync, but this doesn't work. BTW, even with cpu_idcache_wbinv_all change I'm still observing some CAM request retires under high load, so we really seem to have a generic cache issue somewhere. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAklk5mIACgkQK/VZk+smlYHKYQCfeuMdzjTVOu+PcZVfPNae+ZSg GE4AmwQlzD66bQZ8HB5xqThsbwzGaCvB =nK+S -----END PGP SIGNATURE----- !DSPAM:4964e5cf967009398168836! From tinguely at casselton.net Wed Jan 7 18:46:18 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Wed Jan 7 18:46:24 2009 Subject: svn commit: r186730 - in head: lib/libusb20 sys/dev/usb2/controller sys/dev/usb2/core sys/dev/usb2/ethernet sys/dev/usb2/image sys/dev/usb2/include sys/dev/usb2/serial sys/dev/usb2/sound sys/dev/us... In-Reply-To: <20090107202901.21df29e3.stas@FreeBSD.org> Message-ID: <200901071846.n07IkE41053149@casselton.net> > On Wed, 7 Jan 2009 17:51:48 +0100 > Hans Petter Selasky mentioned: > > > > > cpu_idcache_wbinv_all(); /* and this line */ > > > > bus_dmamap_sync(pc->tag, pc->map, > > BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD); > > } > > > > Then everything worked. > > > > I think the ones that have been working on busdma & cache sync issues recently > > are to blame. I will try to investigate more. > > > > Hmm, this might be the same problem with duplicate dcache entries raj reported > recently on arm@. I tried replacing cpu_idcache_wbinv_all with busdma PREREAD > and PREWRITE sync, but this doesn't work. > > BTW, even with cpu_idcache_wbinv_all change I'm still observing some CAM > request retires under high load, so we really seem to have a generic cache > issue somewhere. > > - -- > Stanislav Sedov > ST4096-RIPE It could be the same problem if there is a duplicate kernel mapping. If there is no duplicate kernel mapping, then there is another cache leak somewhere. Because a duplicate kernel mapping currently does not turn off the caches in either mapping, even the wb/inv trick is a cache russian rollette situation. If someone wants to look at very rough code - I don't have a current box to even compile it, I don't know anyone besides myself and Olivier Houchard that is up on the ARM pmap code, but I am looking for someone who will give this an eyeball. There can be consequences to adding pv_entrys where none existed before. I don't want people to blindly download and attempt to run it. My fix idea is to manage all mapped pages, with the expection of ficticous pages. I don't think fictiicous pages can be mapped twice. We need to manage them to turn caching off on all the mappings when there is multiple writers or a writer/reader case. --Mark Tinguely. From raj at semihalf.com Wed Jan 7 19:30:06 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Wed Jan 7 19:30:15 2009 Subject: svn commit: r186730 - in head: lib/libusb20 sys/dev/usb2/controller sys/dev/usb2/core sys/dev/usb2/ethernet sys/dev/usb2/image sys/dev/usb2/include sys/dev/usb2/serial sys/dev/usb2/sound sys/dev/us... In-Reply-To: <200901071846.n07IkE41053149@casselton.net> References: <200901071846.n07IkE41053149@casselton.net> Message-ID: <4964FB53.8040607@semihalf.com> Mark Tinguely wrote: >> On Wed, 7 Jan 2009 17:51:48 +0100 >> Hans Petter Selasky mentioned: >> >> > >> > cpu_idcache_wbinv_all(); /* and this line */ >> > >> > bus_dmamap_sync(pc->tag, pc->map, >> > BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD); >> > } >> > >> > Then everything worked. >> > >> > I think the ones that have been working on busdma & cache sync issues recently >> > are to blame. I will try to investigate more. >> > >> >> Hmm, this might be the same problem with duplicate dcache entries raj reported >> recently on arm@. I tried replacing cpu_idcache_wbinv_all with busdma PREREAD >> and PREWRITE sync, but this doesn't work. >> >> BTW, even with cpu_idcache_wbinv_all change I'm still observing some CAM >> request retires under high load, so we really seem to have a generic cache >> issue somewhere. >> >> - -- >> Stanislav Sedov >> ST4096-RIPE > > It could be the same problem if there is a duplicate kernel mapping. If > there is no duplicate kernel mapping, then there is another cache leak > somewhere. > > Because a duplicate kernel mapping currently does not turn off the > caches in either mapping, even the wb/inv trick is a cache russian rollette > situation. > > If someone wants to look at very rough code - I don't have a current box > to even compile it, I don't know anyone besides myself and Olivier Houchard > that is up on the ARM pmap code, but I am looking for someone who will > give this an eyeball. There can be consequences to adding pv_entrys where none > existed before. I don't want people to blindly download and attempt to run it. Mark, I'd like to look at your code, I guess also Grzegorz (CC'd) who knows ARM pmap code very well will be much interested in your thoughts on resolving the multiple virtual mappings issue, once and for all. How can we access your said proto/rough attempts? Rafal From stas at FreeBSD.org Wed Jan 7 19:32:13 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Wed Jan 7 19:32:20 2009 Subject: svn commit: r186730 - in head: lib/libusb20 sys/dev/usb2/controller sys/dev/usb2/core sys/dev/usb2/ethernet sys/dev/usb2/image sys/dev/usb2/include sys/dev/usb2/serial sys/dev/usb2/sound sys/dev/us... In-Reply-To: <200901071846.n07IkE41053149@casselton.net> References: <20090107202901.21df29e3.stas@FreeBSD.org> <200901071846.n07IkE41053149@casselton.net> Message-ID: <20090107223428.93bf0942.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 7 Jan 2009 12:46:14 -0600 (CST) Mark Tinguely mentioned: > It could be the same problem if there is a duplicate kernel mapping. If > there is no duplicate kernel mapping, then there is another cache leak > somewhere. > Yeah, it seems it leaks somewhere as invalidating the entire wb cache in case of coherent mapping in sys/arm/arm/busdma_machdep.c:_bus_dmamap_sync, where currently it simply returns solves the problem. In fact, all usb memory is mapped as coherent and thus should not require cache flush, but something goes wrong. Could additional entries established by arm_remap_nocache in case of coherent mapping interfere with previous mappings and thus create problems? Is it the same case as duplicate mappings? Thanks! - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkllA8oACgkQK/VZk+smlYHUFQCcD8Ho1E/aFQj6Xm5dOVEwlggW aHMAnR7W3ahfhgJdRpnABLp/c0EuPoa6 =HB2P -----END PGP SIGNATURE----- !DSPAM:4965033a967001106815188! From tinguely at casselton.net Wed Jan 7 19:55:47 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Wed Jan 7 19:55:53 2009 Subject: svn commit: r186730 - in head... In-Reply-To: <4964FB53.8040607@semihalf.com> Message-ID: <200901071955.n07Jthqu057051@casselton.net> > Mark, > I'd like to look at your code, I guess also Grzegorz (CC'd) who knows ARM pmap > code very well will be much interested in your thoughts on resolving the > multiple virtual mappings issue, once and for all. How can we access your said > proto/rough attempts? > > Rafal Here is the "svn diff" from a week or so ago. The url is below in case the inclusion adds some extra characters. http://www.casselton.net/~tinguely/arm_pmap_unmanage.diff pmap_fix_cache() - and the equivalent FreeBSD 6/7 and NetBSD pmap_vac_me_XXX routines should be called when a mapping occurs. It will check for situations where either multiple writers or readers/writer can occur in the current mapping. I won't go into the side cases. Anyway, if there is a writer/reader or multiple writers in a mapping, we have to write back/invalidate and turn off the cache in this mapping. The problem is the kernel mappings (via pmap_enter, pmap_qenter and pmap_kenter) are not managed with pv_entrys. In pmap_fix_cache() we count pv_entrys to detect multiple writers and write/read situations, so it is possible a writable unmanage page may get missed as is. I think the real problem is bigger, for entries mapped with pmap_qenter and pmap_kenter routines, the caches are left on. What my code does is manage all kernel mappings and therefore the pmap_fix_code can do its job. This patch uses more pv_entrys and there were new locks that had to be added for the pv_entry allocation routines. arm_pmap_unmanage.diff Index: arm/arm/pmap.c =================================================================== --- arm/arm/pmap.c (revision 186394) +++ arm/arm/pmap.c (working copy) @@ -407,7 +407,7 @@ #define pmap_is_current(pm) ((pm) == pmap_kernel() || \ curproc->p_vmspace->vm_map.pmap == (pm)) -static uma_zone_t pvzone; +static uma_zone_t pvzone = NULL; uma_zone_t l2zone; static uma_zone_t l2table_zone; static vm_offset_t pmap_kernel_l2dtable_kva; @@ -2713,8 +2713,8 @@ cpu_idcache_wbinv_all(); cpu_l2cache_wbinv_all(); for (pv = TAILQ_FIRST(&pmap->pm_pvlist); pv; pv = npv) { - if (pv->pv_flags & PVF_WIRED) { - /* The page is wired, cannot remove it now. */ + if (pv->pv_flags & PVF_WIRED || pv->pv_flags & PVF_UNMAN) { + /* The page is wired or unmanaged, cannot remove it now. */ npv = TAILQ_NEXT(pv, pv_plist); continue; } @@ -2824,10 +2824,12 @@ struct l2_bucket *l2b; pt_entry_t *pte; pt_entry_t opte; + struct pv_entry *pve; + vm_page_t m; + PDEBUG(1, printf("pmap_kenter: va = %08x, pa = %08x\n", (uint32_t) va, (uint32_t) pa)); - l2b = pmap_get_l2_bucket(pmap_kernel(), va); if (l2b == NULL) l2b = pmap_grow_l2_bucket(pmap_kernel(), va); @@ -2837,10 +2839,10 @@ PDEBUG(1, printf("pmap_kenter: pte = %08x, opte = %08x, npte = %08x\n", (uint32_t) pte, opte, *pte)); if (l2pte_valid(opte)) { - cpu_dcache_wbinv_range(va, PAGE_SIZE); - cpu_l2cache_wbinv_range(va, PAGE_SIZE); - cpu_tlb_flushD_SE(va); - cpu_cpwait(); + /* remove the old mapping + * note, pmap_kremove() has a lot of duplicated code + */ + pmap_kremove(va); } else { if (opte == 0) l2b->l2b_occupancy++; @@ -2852,6 +2854,27 @@ if (flags & KENTER_USER) *pte |= L2_S_PROT_U; PTE_SYNC(pte); + + /* krenel direct mappings can be shared, so use a pv_entry + * to ensure proper caching. + * + * with the old UMA pv allocation method, it is possible + * that this routine is called before UMA is initialized. + * Early allocation should not be shared. + * This can change with "chunk" style pv_entrys. + */ + if (pvzone != NULL) { + if ((pve = pmap_get_pv_entry()) == NULL) + panic("pmap_kenter_internal: no pv entries"); + + vm_page_lock_queues(); + PMAP_LOCK(pmap_kernel()); + m = PHYS_TO_VM_PAGE(vtophys(va)); + pmap_enter_pv(m, pve, pmap_kernel(), va, PVF_WRITE | PVF_UNMAN); + pmap_fix_cache(m, pmap_kernel(), va); + PMAP_UNLOCK(pmap_kernel()); + vm_page_unlock_queues(); + } } void @@ -2888,6 +2911,9 @@ { struct l2_bucket *l2b; pt_entry_t *pte, opte; + struct pv_entry *pve; + vm_page_t m; + vm_offset_t pa; l2b = pmap_get_l2_bucket(pmap_kernel(), va); if (!l2b) @@ -2896,6 +2922,25 @@ pte = &l2b->l2b_kva[l2pte_index(va)]; opte = *pte; if (l2pte_valid(opte)) { + /* pa = vtophs(va) taken from pmap_extract() */ + switch (opte & L2_TYPE_MASK) { + case L2_TYPE_L: + pa = (pte & L2_L_FRAME) | (va & L2_L_OFFSET); + break; + default: + pa = (pte & L2_S_FRAME) | (va & L2_S_OFFSET); + break; + } + /* note: should never have to remove an allocation + * before the pvzone is initialized. + */ + vm_page_lock_queues(); + PMAP_LOCK(pmap_kernel()); /* XXX only PVC_UNMAN? XXX */ + if ((m = PHYS_TO_VM_PAGE(pa)) && + (pve = pmap_remove_pv(m, pmap_kernel(), va))) + pmap_free_pv_entry(pve); + PMAP_UNLOCK(pmap_kernel()); + vm_page_unlock_queues(); cpu_dcache_wbinv_range(va, PAGE_SIZE); cpu_l2cache_wbinv_range(va, PAGE_SIZE); cpu_tlb_flushD_SE(va); @@ -2917,7 +2962,7 @@ * update '*virt' with the first usable address after the mapped * region. */ -vm_offset_t +vm_offset_t pmap_map(vm_offset_t *virt, vm_offset_t start, vm_offset_t end, int prot) { #ifdef ARM_USE_SMALL_ALLOC @@ -3123,6 +3168,11 @@ pmap_remove_write(m); curpm = vmspace_pmap(curproc->p_vmspace); while ((pv = TAILQ_FIRST(&m->md.pv_list)) != NULL) { + /* don't expect to remove a unmanaged page */ + if (pv->pv_flag & PVC_UNMAN) { + printf("pmap_remove_all: Unmanaged page %08x\n", + (u_int32_t) m); + } if (flush == FALSE && (pv->pv_pmap == curpm || pv->pv_pmap == pmap_kernel())) flush = TRUE; @@ -3418,16 +3468,16 @@ * Replacing an existing mapping with a new one. * It is part of our managed memory so we * must remove it from the PV list + * + * unmanaged kernel memory also will have a pv_entry. */ pve = pmap_remove_pv(opg, pmap, va); - if (m && (m->flags & (PG_UNMANAGED | PG_FICTITIOUS)) && - pve) + if (m && (m->flags & PG_FICTITIOUS) && pve) pmap_free_pv_entry(pve); - else if (!pve && - !(m->flags & (PG_UNMANAGED | PG_FICTITIOUS))) + else if (!pve && !(m->flags & PG_FICTITIOUS)) pve = pmap_get_pv_entry(); - KASSERT(pve != NULL || m->flags & (PG_UNMANAGED | - PG_FICTITIOUS), ("No pv")); + KASSERT(pve != NULL || m->flags & PG_FICTITIOUS), + ("No pv")); oflags = pve->pv_flags; /* @@ -3436,8 +3486,7 @@ * initially) then make sure to frob * the cache. */ - if ((oflags & PVF_NC) == 0 && - l2pte_valid(opte)) { + if ((oflags & PVF_NC) == 0 && l2pte_valid(opte)) { if (PV_BEEN_EXECD(oflags)) { pmap_idcache_wbinv_range(pmap, va, PAGE_SIZE); @@ -3448,13 +3497,15 @@ (oflags & PVF_WRITE) == 0); } } - } else if (m && !(m->flags & (PG_UNMANAGED | PG_FICTITIOUS))) + } else if (m && !(m->flags & PG_FICTITIOUS)) if ((pve = pmap_get_pv_entry()) == NULL) { panic("pmap_enter: no pv entries"); } - if (m && !(m->flags & (PG_UNMANAGED | PG_FICTITIOUS))) { + if (m && !(m->flags & PG_FICTITIOUS)) { KASSERT(va < kmi.clean_sva || va >= kmi.clean_eva, ("pmap_enter: managed mapping within the clean submap")); + if (m->flags & PG_UNMANAGED) + nflags |= PVF_UNMAN; pmap_enter_pv(m, pve, pmap, va, nflags); } } Index: arm/include/pmap.h =================================================================== --- arm/include/pmap.h (revision 186394) +++ arm/include/pmap.h (working copy) @@ -495,6 +495,7 @@ #define PVF_EXEC 0x10 /* mapping is executable */ #define PVF_NC 0x20 /* mapping is non-cacheable */ #define PVF_MWC 0x40 /* mapping is used multiple times in userland */ +#define PVF_UNMAN 0x80 /* mapping is unmanaged */ void vector_page_setprot(int); From stas at FreeBSD.org Wed Jan 7 21:53:23 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Wed Jan 7 21:53:35 2009 Subject: USB2 reveals cache sync problems on AT91RM9200 In-Reply-To: <200901071819.26446.hselasky@c2i.net> References: <200901071819.26446.hselasky@c2i.net> Message-ID: <20090108005028.3c31d5eb.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 7 Jan 2009 18:19:25 +0100 Hans Petter Selasky mentioned: > Hi, > > I'm writing this e-mail to you because some of you have changed something in: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/arm/arm/busdma_machdep.c > > I'm experiencing a problem where the CPU is not seeing the data written to > memory by the OHCI using DMA. This does not happen all the time. > > Adding a "cpu_idcache_wbinv_all()" to my "cpu_invalidate" function solves the > problem 100% reliably. I think Stanislav should be able to reproduce this. > > Any ideas? > > I feel pretty sure that this is not an USB2 problem. I have tested that data > is correctly bounced on x86 and assume that if the data is correctly bounced, > it will also be correctly synched. Using bounce buffers by lowering > the "lowaddr" in the DMA tag, on my AT91RM9200, does not solve the problem. > > --HPS > > Hardware: > > ## Starting application at 0x200000E0 ... > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-CURRENT #33: Wed Jan 7 17:52:20 CET 2009 > hans_other@server0.selasky.org:/usr/obj/arm/usr/8-current/src/sys/custom > CPU: ARM920T rev 0 (ARM9TDMI core) > DC enabled IC enabled WB enabled LABT > 16KB/32B 64-way Instruction cache > 16KB/32B 64-way write-back-locking-A Data cache > > My patch that makes things work again: > > #include > > and: > > /*------------------------------------------------------------------------* > * usb2_pc_cpu_invalidate - invalidate CPU cache > *------------------------------------------------------------------------*/ > void > usb2_pc_cpu_invalidate(struct usb2_page_cache *pc) > { > if (pc->page_offset_end == pc->page_offset_buf) { > /* nothing has been loaded into this page cache! */ > return; > } > > cpu_idcache_wbinv_all(); /* and this line */ > > bus_dmamap_sync(pc->tag, pc->map, > BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD); > } > Well, further research showed that what is really not synchronizing correctly is ohci ed descriptors. I've added the following code into ohci2.c and clearly shows that ed descriptor contents differ before and after cpu_idcache_wbinv_all despite it should have been syncronized by usb2_pc_cpu_invalidate. usb2_pc_cpu_invalidate(ed->page_cache); ed_flags = le32toh(ed->ed_flags); ed_headp = le32toh(ed->ed_headp); ed_tailp = le32toh(ed->ed_tailp); + printf("OHCI: ed flags was: %d %d %d\n", le32toh(ed->ed_flags), le32toh(ed->ed_headp), le32toh(ed->ed_tailp)); + cpu_idcache_wbinv_all(); + printf("OHCI: ed flags now: %d %d %d\n", le32toh(ed->ed_flags), le32toh(ed->ed_headp), le32toh(ed->ed_tailp)); Moving cpu_idcache_wbinv_all just after usb2_pc_cpu_invalidate before ed descriptor access fixes umass storage on arm for me. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkllI6gACgkQK/VZk+smlYG0ewCcD5VlJMoLas6hrx9sUC2y7/e5 cfQAnjBKaOwvmMBxt1nMecjB3pvemk7a =86fe -----END PGP SIGNATURE----- !DSPAM:49652316967001025050683! From tinguely at casselton.net Wed Jan 7 21:53:29 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Wed Jan 7 21:53:36 2009 Subject: svn commit: r186730 - in head: lib/libusb20 sys/dev/usb2/controller sys/dev/usb2/core sys/dev/usb2/ethernet sys/dev/usb2/image sys/dev/usb2/include sys/dev/usb2/serial sys/dev/usb2/sound sys/dev/us... In-Reply-To: <20090107223428.93bf0942.stas@FreeBSD.org> Message-ID: <200901072153.n07LrNZU063946@casselton.net> > On Wed, 7 Jan 2009 12:46:14 -0600 (CST) > Mark Tinguely mentioned: > > > It could be the same problem if there is a duplicate kernel mapping. If > > there is no duplicate kernel mapping, then there is another cache leak > > somewhere. > > > > Yeah, it seems it leaks somewhere as invalidating the entire wb cache > in case of coherent mapping in sys/arm/arm/busdma_machdep.c:_bus_dmamap_sync, > where currently it simply returns solves the problem. In fact, all usb memory > is mapped as coherent and thus should not require cache flush, but something > goes wrong. Could additional entries established by arm_remap_nocache in > case of coherent mapping interfere with previous mappings and thus create > problems? Is it the same case as duplicate mappings? > > Thanks! > - -- > Stanislav Sedov > ST4096-RIPE Coherent in ARM is a duplicate mapping with a special VA above the KVM. The new kernel entry is mapped with cache turned off (pmap_kenter_nocache()), but the original virtual mapping still has caching turned on. In fact, pmap_kenter_nocache() invalidates/writebacks the new special VA, but does not writeback/invalidate the original virtual mapping - that is where your problem originates and why your writeback/invalidates works. If you trust that the other mapping will not modify memory - which in this case, I believe we can - a quick solution would be to add a writeback/invalidate (pmap_fix_cache) in the second for loop of arm_remap_nocache(). But I would have to make sure the pmap_fix_cache counts the new un-managed kernel mapping before I recommend that. When I wrote the patch, I grepped for pmap_kenter_* routines, and noticed as side effect of managing the cohert code is also fixed and in fact it can be simplified greatly. At the time - before the usb2 import, I grepping the sources and there were only a couple network adapters using BUS_DMA_COHERENT, so I was not too concerned. --Mark Tinguely. From stas at FreeBSD.org Wed Jan 7 22:24:15 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Wed Jan 7 22:24:22 2009 Subject: svn commit: r186730 - in head: lib/libusb20 sys/dev/usb2/controller sys/dev/usb2/core sys/dev/usb2/ethernet sys/dev/usb2/image sys/dev/usb2/include sys/dev/usb2/serial sys/dev/usb2/sound sys/dev/us... In-Reply-To: <200901072153.n07LrNZU063946@casselton.net> References: <20090107223428.93bf0942.stas@FreeBSD.org> <200901072153.n07LrNZU063946@casselton.net> Message-ID: <20090108012627.4ed3e907.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 7 Jan 2009 15:53:23 -0600 (CST) Mark Tinguely mentioned: > Coherent in ARM is a duplicate mapping with a special VA above the KVM. The > new kernel entry is mapped with cache turned off (pmap_kenter_nocache()), but > the original virtual mapping still has caching turned on. In fact, > pmap_kenter_nocache() invalidates/writebacks the new special VA, but does > not writeback/invalidate the original virtual mapping - that is where your > problem originates and why your writeback/invalidates works. > > If you trust that the other mapping will not modify memory - which in this > case, I believe we can - a quick solution would be to add a writeback/invalidate > (pmap_fix_cache) in the second for loop of arm_remap_nocache(). But I would > have to make sure the pmap_fix_cache counts the new un-managed kernel mapping > before I recommend that. > > When I wrote the patch, I grepped for pmap_kenter_* routines, and noticed > as side effect of managing the cohert code is also fixed and in fact it can > be simplified greatly. At the time - before the usb2 import, I grepping the > sources and there were only a couple network adapters using BUS_DMA_COHERENT, > so I was not too concerned. It looks like I've found the place where the mapping could not be invalidated because of this. In ohci2.c we need the ed descriptor to be synchronized before we access it, but busdma fails to sync it. I tried to do what busdma does by hand, but this doesn't make "ed" to be consistent as well: cpu_idcache_wbinv_range((vm_offset_t)ed->page_cache->map->buffer, ed->page_cache->map->len); After calling cpu_idcache_wbinv_all at this point (which invalidates and cleans all entries) ed contains correct entries. Thus it seems that because of double mappings cpu_idcache_wbinv_range fails to clean the entry (it seem to clear the old one instead). I'll think about your points here, need to study pmap and busdma code a bit first. Thanks for clearing this out! - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkllLBkACgkQK/VZk+smlYERswCggfXhIHlTAZZ0nymRwwRPQKwf NaQAn2tHgT4ez2eHfRyC/JMX37eKiuLU =jzsU -----END PGP SIGNATURE----- !DSPAM:49652b88967002281716519! From gjb at semihalf.com Thu Jan 8 09:22:13 2009 From: gjb at semihalf.com (Grzegorz Bernacki) Date: Thu Jan 8 09:22:20 2009 Subject: USB2 reveals cache sync problems on AT91RM9200 In-Reply-To: <20090108005028.3c31d5eb.stas@FreeBSD.org> References: <200901071819.26446.hselasky@c2i.net> <20090108005028.3c31d5eb.stas@FreeBSD.org> Message-ID: <4965C5D8.6020805@semihalf.com> Stanislav Sedov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 7 Jan 2009 18:19:25 +0100 > Hans Petter Selasky mentioned: > >> Hi, >> >> I'm writing this e-mail to you because some of you have changed something in: >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/arm/arm/busdma_machdep.c >> >> I'm experiencing a problem where the CPU is not seeing the data written to >> memory by the OHCI using DMA. This does not happen all the time. >> >> Adding a "cpu_idcache_wbinv_all()" to my "cpu_invalidate" function solves the >> problem 100% reliably. I think Stanislav should be able to reproduce this. >> >> Any ideas? >> >> I feel pretty sure that this is not an USB2 problem. I have tested that data >> is correctly bounced on x86 and assume that if the data is correctly bounced, >> it will also be correctly synched. Using bounce buffers by lowering >> the "lowaddr" in the DMA tag, on my AT91RM9200, does not solve the problem. >> >> --HPS >> >> Hardware: >> >> ## Starting application at 0x200000E0 ... >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2009 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 8.0-CURRENT #33: Wed Jan 7 17:52:20 CET 2009 >> hans_other@server0.selasky.org:/usr/obj/arm/usr/8-current/src/sys/custom >> CPU: ARM920T rev 0 (ARM9TDMI core) >> DC enabled IC enabled WB enabled LABT >> 16KB/32B 64-way Instruction cache >> 16KB/32B 64-way write-back-locking-A Data cache >> >> My patch that makes things work again: >> >> #include >> >> and: >> >> /*------------------------------------------------------------------------* >> * usb2_pc_cpu_invalidate - invalidate CPU cache >> *------------------------------------------------------------------------*/ >> void >> usb2_pc_cpu_invalidate(struct usb2_page_cache *pc) >> { >> if (pc->page_offset_end == pc->page_offset_buf) { >> /* nothing has been loaded into this page cache! */ >> return; >> } >> >> cpu_idcache_wbinv_all(); /* and this line */ >> >> bus_dmamap_sync(pc->tag, pc->map, >> BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD); >> } >> > > Well, further research showed that what is really not synchronizing > correctly is ohci ed descriptors. I've added the following code into > ohci2.c and clearly shows that ed descriptor contents differ before > and after cpu_idcache_wbinv_all despite it should have been syncronized > by usb2_pc_cpu_invalidate. > > usb2_pc_cpu_invalidate(ed->page_cache); > ed_flags = le32toh(ed->ed_flags); > ed_headp = le32toh(ed->ed_headp); > ed_tailp = le32toh(ed->ed_tailp); > + printf("OHCI: ed flags was: %d %d %d\n", le32toh(ed->ed_flags), le32toh(ed->ed_headp), le32toh(ed->ed_tailp)); > + cpu_idcache_wbinv_all(); > + printf("OHCI: ed flags now: %d %d %d\n", le32toh(ed->ed_flags), le32toh(ed->ed_headp), le32toh(ed->ed_tailp)); > > Moving cpu_idcache_wbinv_all just after usb2_pc_cpu_invalidate before ed descriptor > access fixes umass storage on arm for me. > Hi, Some time ago we had a problem with EHCI. The problem was that after transfer CSW was overwritten with some old data from CSW of previous transfer. We saw it only when write-allocate feature was turned off. The problem was caused by specific handling of BUS_DMASYNC_POSTREAD in ARM bus dma code. If you look at the code you see that if synced region is not cache aligned we copy it into temporary location, invalidate the region and copy back saved data. But if write-allocate is turned on, writing data back causes allocating cache line and store the data in it. So we end up with dirty cache line contains stale data which should be invalidated. And those data could be flushed back at random time whenever cache line is recycled. We fixed the problem using BUS_DMASYNC_PREREAD command before using updated CSW. I don't know if you use write-allocate, but if you do and if the problem disappears when you turn it off it's probably the same problem. You can also check the thread when Rafal described our problem: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=198997+0+archive/2008/freebsd-usb/20080203.freebsd-usb correct place for fix mentioned there is: http://people.freebsd.org/~raj/patches/misc/committed/usbdi-bus_dma-fix.diff pozdrawiam, Grzesiek From jacques.fourie at gmail.com Fri Jan 9 09:52:53 2009 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Fri Jan 9 09:52:59 2009 Subject: if_smc patch Message-ID: <49671DFB.8010800@gmail.com> Hi, I'm not sure who the maintainer of the if_smc code is, but here is a simple patch that addresses what seems like typos in the original code. diff -u -r smc.old/if_smc.c smc.new/if_smc.c --- smc.old/if_smc.c 2009-01-09 10:31:56.000000000 +0200 +++ smc.new/if_smc.c 2009-01-09 11:45:01.000000000 +0200 @@ -494,7 +494,7 @@ * Work out how many 256 byte "pages" we need. We have to include the * control data for the packet in this calculation. */ - npages = (len * PKT_CTRL_DATA_LEN) >> 8; + npages = (len + PKT_CTRL_DATA_LEN) >> 8; if (npages == 0) npages = 1; diff -u -r smc.old/if_smcreg.h smc.new/if_smcreg.h --- smc.old/if_smcreg.h 2009-01-09 10:31:56.000000000 +0200 +++ smc.new/if_smcreg.h 2009-01-09 11:45:01.000000000 +0200 @@ -138,7 +138,7 @@ #define GPR 0xa /* Bank 1, Offset 0xc: Control Register */ -#define CTR 0xa +#define CTR 0xc #define CTR_STORE 0x0001 /* Store registers to EEPROM */ #define CTR_RELOAD 0x0002 /* Reload registers from EEPROM */ #define CTR_EEPROM_SELECT 0x0004 /* Select registers to store/reload */ From sam at freebsd.org Fri Jan 9 21:15:00 2009 From: sam at freebsd.org (Sam Leffler) Date: Fri Jan 9 21:15:06 2009 Subject: hwpmc on xscale (pxa255) In-Reply-To: References: Message-ID: <4967B9B1.3000503@freebsd.org> Jacques Fourie wrote: > I am interested in making hwpmc work on my gumstix (pxa255 cpu). Does > anyone have working examples of pmc_save_kernel_callchain() and > pmc_save_user_callchain() for arm platforms that they are willing to > share? > I'm very interested in pmc support for xscale. If you do anything I'll pitch in. Sam From krassi at bulinfo.net Mon Jan 19 07:54:28 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Mon Jan 19 07:54:35 2009 Subject: Mount root from SD card? Message-ID: <49749CE2.2000405@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am trying to test the latest CURRENT on my 91rm9200 board but can not mount root from SD card anymore. Any ideas? Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #1 r187432M: Mon Jan 19 16:39:23 EET 2009 root@krassi:/usr/obj/arm/usr/src-current/sys/CENTIPAD CPU: ARM920T rev 0 (ARM9TDMI core) DC enabled IC enabled WB enabled LABT 16KB/32B 64-way Instruction cache 16KB/32B 64-way write-back-locking-A Data cache real memory = 67108864 (64 MB) avail memory = 62226432 (59 MB) atmelarm0: on motherboard at91_st0: mem 0xdffffd00-0xdffffdff irq 1 on atmelarm0 at91_st0: watchdog registered, timeout intervall max. 64 sec at91_pio0: mem 0xdffff400-0xdffff5ff irq 1 on atmelarm0 at91_pio0: ABSR: 0x1000060 OSR: 0 PSR:0x380010 ODSR: 0 at91_pio0: [FILTER] at91_pio1: mem 0xdffff600-0xdffff7ff irq 1 on atmelarm0 at91_pio1: ABSR: 0xff338 OSR: 0 PSR:0x3fc00cc7 ODSR: 0 at91_pio1: [FILTER] at91_pio2: mem 0xdffff800-0xdffff9ff irq 1 on atmelarm0 at91_pio2: ABSR: 0 OSR: 0 PSR:0xc07f ODSR: 0x4000 at91_pio2: [FILTER] at91_pio3: mem 0xdffffa00-0xdffffbff irq 1 on atmelarm0 at91_pio3: ABSR: 0 OSR: 0 PSR:0xfffffff ODSR: 0 at91_pio3: [FILTER] at91_pmc0: mem 0xdffffc00-0xdffffcff irq 1 on atmelarm0 at91_pmc0: Primary: 10000000 Hz PLLA: 180 MHz CPU: 180 MHz MCK: 60 MHz at91_mci0: mem 0xdffb4000-0xdffb7fff irq 10 on atmelarm0 at91_mci0: [ITHREAD] mmc0: on at91_mci0 at91_twi0: mem 0xdffb8000-0xdffbbfff irq 12 on atmelarm0 at91_twi0: [ITHREAD] iicbus0: on at91_twi0 setting cwgr to 0x1a4a4 iic0: on iicbus0 icee0: at addr 0xa7 on iicbus0 ate0: mem 0xdffbc000-0xdffbffff irq 24 on atmelarm0 miibus0: on ate0 rlphy0: PHY 16 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ate0: Ethernet address: 43:00:00:01:ff:00 ate0: [ITHREAD] uart0: mem 0xdffff200-0xdffff3ff irq 1 on atmelarm0 uart0: [FILTER]uart0: console (115200,n,8,1) uart1: mem 0xdffc0000-0xdffc3fff irq 6 on atmelarm0 uart1: [FILTER] uart2: mem 0xdffc4000-0xdffc7fff irq 7 on atmelarm0 uart2: [FILTER] uart3: mem 0xdffc8000-0xdffcbfff irq 8 on atmelarm0 uart3: [FILTER] uart4: mem 0xdffcc000-0xdffcffff irq 9 on atmelarm0 uart4: [FILTER] at91_ssc0: mem 0xdffd0000-0xdffd3fff irq 14 on atmelarm0 at91_ssc0: [ITHREAD] at91_ssc1: mem 0xdffd4000-0xdffd7fff irq 15 on atmelarm0 at91_ssc1: [ITHREAD] at91_ssc2: mem 0xdffd8000-0xdffdbfff irq 16 on atmelarm0 at91_ssc2: [ITHREAD] at91_spi0: mem 0xdffe0000-0xdffe3fff irq 13 on atmelarm0 at91_spi0: [ITHREAD] spibus0: on at91_spi0 spibus0: at cs 0 ohci0: mem 0xdfe00000-0xdfefffff irq 23 on atmelarm0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0 usb0 on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhub0: device problem (IOERROR), disabling port 2 Cannot get 100 Hz clock; using 100Hz at91_st0: [FILTER] Timecounter "AT91RM9200 timer" frequency 32768 Hz quality 1000 Timecounters tick every 10.000 msec mmcsd0: 1983MB at mmc0 30MHz/1bit Trying to mount root from ufs:/dev/mmcsd0s1 Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0a ? List valid disk boot devices Abort manual input mountroot> ? List of GEOM managed disk devices: mmcsd0 With last known working kernel: ... FreeBSD 8.0-CURRENT #32: Thu Nov 8 17:22:00 EET 2007 ... SD CARD: 2079326208 bytes mmcsd0: on mmc0 mmc0: setting transfer rate to 30.000MHz Trying to mount root from ufs:/dev/mmcsd0s1 warning: Low voltage. The time may be corrupted! Dec 4 06:42:27 init: getting pseudoterminals resource limit: Invalid argument pid 25 (sh), uid 0: exited on signal 11 ... Best regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdJzixJBWvpalMpkRAp8WAJ9TkaSuQEi+601eEr6gDgYLiDsIkwCfXqA0 fp2SXoYe1rH/1119MAVCtdA= =hgL9 -----END PGP SIGNATURE----- From imp at bsdimp.com Mon Jan 19 10:10:14 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Mon Jan 19 10:10:20 2009 Subject: Mount root from SD card? In-Reply-To: <49749CE2.2000405@bulinfo.net> References: <49749CE2.2000405@bulinfo.net> Message-ID: <20090119.110827.2140505733.imp@bsdimp.com> In message: <49749CE2.2000405@bulinfo.net> Krassimir Slavchev writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : Hi, : : I am trying to test the latest CURRENT on my 91rm9200 board but can not : mount root from SD card anymore. : : Any ideas? : : Copyright (c) 1992-2009 The FreeBSD Project. : Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 : The Regents of the University of California. All rights reserved. : FreeBSD is a registered trademark of The FreeBSD Foundation. : FreeBSD 8.0-CURRENT #1 r187432M: Mon Jan 19 16:39:23 EET 2009 : root@krassi:/usr/obj/arm/usr/src-current/sys/CENTIPAD : CPU: ARM920T rev 0 (ARM9TDMI core) : DC enabled IC enabled WB enabled LABT : 16KB/32B 64-way Instruction cache : 16KB/32B 64-way write-back-locking-A Data cache : real memory = 67108864 (64 MB) : avail memory = 62226432 (59 MB) : atmelarm0: on motherboard : at91_st0: mem 0xdffffd00-0xdffffdff irq 1 on atmelarm0 : at91_st0: watchdog registered, timeout intervall max. 64 sec : at91_pio0: mem 0xdffff400-0xdffff5ff irq 1 on atmelarm0 : at91_pio0: ABSR: 0x1000060 OSR: 0 PSR:0x380010 ODSR: 0 : at91_pio0: [FILTER] : at91_pio1: mem 0xdffff600-0xdffff7ff irq 1 on atmelarm0 : at91_pio1: ABSR: 0xff338 OSR: 0 PSR:0x3fc00cc7 ODSR: 0 : at91_pio1: [FILTER] : at91_pio2: mem 0xdffff800-0xdffff9ff irq 1 on atmelarm0 : at91_pio2: ABSR: 0 OSR: 0 PSR:0xc07f ODSR: 0x4000 : at91_pio2: [FILTER] : at91_pio3: mem 0xdffffa00-0xdffffbff irq 1 on atmelarm0 : at91_pio3: ABSR: 0 OSR: 0 PSR:0xfffffff ODSR: 0 : at91_pio3: [FILTER] : at91_pmc0: mem 0xdffffc00-0xdffffcff irq 1 on atmelarm0 : at91_pmc0: Primary: 10000000 Hz PLLA: 180 MHz CPU: 180 MHz MCK: 60 MHz : at91_mci0: mem 0xdffb4000-0xdffb7fff irq 10 on : atmelarm0 : at91_mci0: [ITHREAD] : mmc0: on at91_mci0 : at91_twi0: mem 0xdffb8000-0xdffbbfff irq 12 on atmelarm0 : at91_twi0: [ITHREAD] : iicbus0: on at91_twi0 : setting cwgr to 0x1a4a4 : iic0: on iicbus0 : icee0: at addr 0xa7 on iicbus0 : ate0: mem 0xdffbc000-0xdffbffff irq 24 on atmelarm0 : miibus0: on ate0 : rlphy0: PHY 16 on miibus0 : rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto : ate0: Ethernet address: 43:00:00:01:ff:00 : ate0: [ITHREAD] : uart0: mem 0xdffff200-0xdffff3ff irq 1 on atmelarm0 : uart0: [FILTER]uart0: console (115200,n,8,1) : uart1: mem 0xdffc0000-0xdffc3fff irq 6 on atmelarm0 : uart1: [FILTER] : uart2: mem 0xdffc4000-0xdffc7fff irq 7 on atmelarm0 : uart2: [FILTER] : uart3: mem 0xdffc8000-0xdffcbfff irq 8 on atmelarm0 : uart3: [FILTER] : uart4: mem 0xdffcc000-0xdffcffff irq 9 on atmelarm0 : uart4: [FILTER] : at91_ssc0: mem 0xdffd0000-0xdffd3fff irq 14 on atmelarm0 : at91_ssc0: [ITHREAD] : at91_ssc1: mem 0xdffd4000-0xdffd7fff irq 15 on atmelarm0 : at91_ssc1: [ITHREAD] : at91_ssc2: mem 0xdffd8000-0xdffdbfff irq 16 on atmelarm0 : at91_ssc2: [ITHREAD] : at91_spi0: mem 0xdffe0000-0xdffe3fff irq 13 on atmelarm0 : at91_spi0: [ITHREAD] : spibus0: on at91_spi0 : spibus0: at cs 0 : ohci0: mem 0xdfe00000-0xdfefffff irq : 23 on atmelarm0 : ohci0: [GIANT-LOCKED] : ohci0: [ITHREAD] : usb0: OHCI version 1.0 : usb0 on ohci0 : usb0: USB revision 1.0 : uhub0: on usb0 : uhub0: 2 ports with 2 removable, self powered : uhub0: device problem (IOERROR), disabling port 2 : Cannot get 100 Hz clock; using 100Hz : at91_st0: [FILTER] : Timecounter "AT91RM9200 timer" frequency 32768 Hz quality 1000 : Timecounters tick every 10.000 msec : mmcsd0: 1983MB at mmc0 30MHz/1bit : Trying to mount root from ufs:/dev/mmcsd0s1 : : Manual root filesystem specification: : : Mount using filesystem : eg. ufs:/dev/da0a : ? List valid disk boot devices : Abort manual input : : mountroot> ? : : List of GEOM managed disk devices: : mmcsd0 Looks like that should be working. mav@ has done a lot of hacking on the mmc code... Do you have 1 wire or 4 wires for your mmc bus on your board? Warner : With last known working kernel: : ... : FreeBSD 8.0-CURRENT #32: Thu Nov 8 17:22:00 EET 2007 : ... : SD CARD: 2079326208 bytes : mmcsd0: on mmc0 : mmc0: setting transfer rate to 30.000MHz : Trying to mount root from ufs:/dev/mmcsd0s1 : warning: Low voltage. The time may be corrupted! : Dec 4 06:42:27 init: getting pseudoterminals resource limit: Invalid : argument : pid 25 (sh), uid 0: exited on signal 11 : ... : : : Best regards : : : -----BEGIN PGP SIGNATURE----- : Version: GnuPG v1.4.7 (FreeBSD) : : iD8DBQFJdJzixJBWvpalMpkRAp8WAJ9TkaSuQEi+601eEr6gDgYLiDsIkwCfXqA0 : fp2SXoYe1rH/1119MAVCtdA= : =hgL9 : -----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 krassi at bulinfo.net Mon Jan 19 23:59:29 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Mon Jan 19 23:59:36 2009 Subject: Mount root from SD card? In-Reply-To: <20090119.110827.2140505733.imp@bsdimp.com> References: <49749CE2.2000405@bulinfo.net> <20090119.110827.2140505733.imp@bsdimp.com> Message-ID: <4975845E.6020502@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: ... > mmcsd0: 1983MB at mmc0 30MHz/1bit > Trying to mount root from ufs:/dev/mmcsd0s1 > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:/dev/da0a > ? List valid disk boot devices > Abort manual input > > mountroot> ? > > List of GEOM managed disk devices: > mmcsd0 > >> Looks like that should be working. > >> mav@ has done a lot of hacking on the mmc code... > >> Do you have 1 wire or 4 wires for your mmc bus on your board? On the board all 4 bus wires are connected (MCD A0-A3) but I've never seen working 4-bit mode on AT91RM9200 (See PR128987 too). Best regards > >> Warner > > With last known working kernel: > ... > FreeBSD 8.0-CURRENT #32: Thu Nov 8 17:22:00 EET 2007 > ... > SD CARD: 2079326208 bytes > mmcsd0: on mmc0 > mmc0: setting transfer rate to 30.000MHz > Trying to mount root from ufs:/dev/mmcsd0s1 > warning: Low voltage. The time may be corrupted! > Dec 4 06:42:27 init: getting pseudoterminals resource limit: Invalid > argument > pid 25 (sh), uid 0: exited on signal 11 > ... > > > Best regards > > _______________________________________________ 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdYRexJBWvpalMpkRAupbAKCU5m28vw6OOhqo9MfMTbVGAFi7OwCfYDQ7 ctPYlDa089mbI+bKUYAf4ys= =6cNg -----END PGP SIGNATURE----- From mav at FreeBSD.org Tue Jan 20 10:09:28 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Jan 20 10:09:34 2009 Subject: Mount root from SD card? In-Reply-To: <49760E8E.1000609@FreeBSD.org> References: <1232392983.00063248.1232380802@10.7.7.3> <1232400185.00063286.1232389201@10.7.7.3> <1232450582.00063538.1232438401@10.7.7.3> <49760E8E.1000609@FreeBSD.org> Message-ID: <4976135A.3070109@FreeBSD.org> Alexander Motin wrote: > Krassimir Slavchev wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> M. Warner Losh wrote: >> ... >>> mmcsd0: 1983MB at mmc0 30MHz/1bit >>> Trying to mount root from ufs:/dev/mmcsd0s1 >>> >>> Manual root filesystem specification: >>> : Mount using filesystem >>> eg. ufs:/dev/da0a >>> ? List valid disk boot devices >>> Abort manual input >>> >>> mountroot> ? >>> >>> List of GEOM managed disk devices: >>> mmcsd0 >>> >>>> Looks like that should be working. >>>> mav@ has done a lot of hacking on the mmc code... >>>> Do you have 1 wire or 4 wires for your mmc bus on your board? >> >> On the board all 4 bus wires are connected (MCD A0-A3) but I've never >> seen working 4-bit mode on AT91RM9200 (See PR128987 too). > > I have just committed MMCBR_IVAR_CAPS implementation into CURRENT. > Without having it implemented, results can be unpredictable. For > example, mmc layer could enable high-speed timings to reach 30MHz, but > this mode is not implemented for this controller. Booting with verbose > messages enabled could give a bit more information. > > What's about 4-bit mode, I see some sc->wire4 variable checked by the > driver, which is never initialized. I don't very understand how this > thing expected to work. As I can see from specification, if sc->wire4 is set to 0 by default, bus will not ever switched into 4bit mode. Try to just comment out " && sc->wire4" part of at91_mci.c. If this variable expected to report real bus width, then it probably should be done in different way, by reporting correct host capabilities. > PS: For MMC cards bus width testing routine implemented. May be we could > do something alike for SD cards. It is not part of SD specification, but > may be we could just issue some other command, transferring data, to > check effective bus width. -- Alexander Motin From imp at bsdimp.com Tue Jan 20 10:42:02 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Jan 20 10:42:08 2009 Subject: Mount root from SD card? In-Reply-To: <49760E8E.1000609@FreeBSD.org> References: <1232400185.00063286.1232389201@10.7.7.3> <1232450582.00063538.1232438401@10.7.7.3> <49760E8E.1000609@FreeBSD.org> Message-ID: <20090120.114051.-854291995.imp@bsdimp.com> In message: <49760E8E.1000609@FreeBSD.org> Alexander Motin writes: : Krassimir Slavchev wrote: : > -----BEGIN PGP SIGNED MESSAGE----- : > Hash: SHA1 : > : > M. Warner Losh wrote: : > ... : >> mmcsd0: 1983MB at mmc0 30MHz/1bit : >> Trying to mount root from ufs:/dev/mmcsd0s1 : >> : >> Manual root filesystem specification: : >> : Mount using filesystem : >> eg. ufs:/dev/da0a : >> ? List valid disk boot devices : >> Abort manual input : >> : >> mountroot> ? : >> : >> List of GEOM managed disk devices: : >> mmcsd0 : >> : >>> Looks like that should be working. : >>> mav@ has done a lot of hacking on the mmc code... : >>> Do you have 1 wire or 4 wires for your mmc bus on your board? : > : > On the board all 4 bus wires are connected (MCD A0-A3) but I've never : > seen working 4-bit mode on AT91RM9200 (See PR128987 too). : : I have just committed MMCBR_IVAR_CAPS implementation into CURRENT. : Without having it implemented, results can be unpredictable. For : example, mmc layer could enable high-speed timings to reach 30MHz, but : this mode is not implemented for this controller. Booting with verbose : messages enabled could give a bit more information. This controller's driver should do the right thing when given a too high bus speed: clamp it to the maximum... However, maybe the clamps are right. The above symptom was what I'd see when the data read in was corrupted. It is the whole reason I never enabled the multi-block read for this controller. I could never make it work well enough to even make mountroot happy. : What's about 4-bit mode, I see some sc->wire4 variable checked by the : driver, which is never initialized. I don't very understand how this : thing expected to work. It is initialized to zero. It is expected that there will be a different mechanism in the future to set it generically on a per-board basis. : PS: For MMC cards bus width testing routine implemented. May be we could : do something alike for SD cards. It is not part of SD specification, but : may be we could just issue some other command, transferring data, to : check effective bus width. That would be cool. Warner From mav at FreeBSD.org Tue Jan 20 10:49:01 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Jan 20 10:49:07 2009 Subject: Mount root from SD card? In-Reply-To: <1232450582.00063538.1232438401@10.7.7.3> References: <1232392983.00063248.1232380802@10.7.7.3> <1232400185.00063286.1232389201@10.7.7.3> <1232450582.00063538.1232438401@10.7.7.3> Message-ID: <49760E8E.1000609@FreeBSD.org> Krassimir Slavchev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > M. Warner Losh wrote: > ... >> mmcsd0: 1983MB at mmc0 30MHz/1bit >> Trying to mount root from ufs:/dev/mmcsd0s1 >> >> Manual root filesystem specification: >> : Mount using filesystem >> eg. ufs:/dev/da0a >> ? List valid disk boot devices >> Abort manual input >> >> mountroot> ? >> >> List of GEOM managed disk devices: >> mmcsd0 >> >>> Looks like that should be working. >>> mav@ has done a lot of hacking on the mmc code... >>> Do you have 1 wire or 4 wires for your mmc bus on your board? > > On the board all 4 bus wires are connected (MCD A0-A3) but I've never > seen working 4-bit mode on AT91RM9200 (See PR128987 too). I have just committed MMCBR_IVAR_CAPS implementation into CURRENT. Without having it implemented, results can be unpredictable. For example, mmc layer could enable high-speed timings to reach 30MHz, but this mode is not implemented for this controller. Booting with verbose messages enabled could give a bit more information. What's about 4-bit mode, I see some sc->wire4 variable checked by the driver, which is never initialized. I don't very understand how this thing expected to work. PS: For MMC cards bus width testing routine implemented. May be we could do something alike for SD cards. It is not part of SD specification, but may be we could just issue some other command, transferring data, to check effective bus width. -- Alexander Motin From imp at bsdimp.com Tue Jan 20 10:50:43 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Jan 20 10:50:49 2009 Subject: Mount root from SD card? In-Reply-To: <4976135A.3070109@FreeBSD.org> References: <1232450582.00063538.1232438401@10.7.7.3> <49760E8E.1000609@FreeBSD.org> <4976135A.3070109@FreeBSD.org> Message-ID: <20090120.115031.2008400028.imp@bsdimp.com> In message: <4976135A.3070109@FreeBSD.org> Alexander Motin writes: : Alexander Motin wrote: : > Krassimir Slavchev wrote: : >> -----BEGIN PGP SIGNED MESSAGE----- : >> Hash: SHA1 : >> : >> M. Warner Losh wrote: : >> ... : >>> mmcsd0: 1983MB at mmc0 30MHz/1bit : >>> Trying to mount root from ufs:/dev/mmcsd0s1 : >>> : >>> Manual root filesystem specification: : >>> : Mount using filesystem : >>> eg. ufs:/dev/da0a : >>> ? List valid disk boot devices : >>> Abort manual input : >>> : >>> mountroot> ? : >>> : >>> List of GEOM managed disk devices: : >>> mmcsd0 : >>> : >>>> Looks like that should be working. : >>>> mav@ has done a lot of hacking on the mmc code... : >>>> Do you have 1 wire or 4 wires for your mmc bus on your board? : >> : >> On the board all 4 bus wires are connected (MCD A0-A3) but I've never : >> seen working 4-bit mode on AT91RM9200 (See PR128987 too). : > : > I have just committed MMCBR_IVAR_CAPS implementation into CURRENT. : > Without having it implemented, results can be unpredictable. For : > example, mmc layer could enable high-speed timings to reach 30MHz, but : > this mode is not implemented for this controller. Booting with verbose : > messages enabled could give a bit more information. : > : > What's about 4-bit mode, I see some sc->wire4 variable checked by the : > driver, which is never initialized. I don't very understand how this : > thing expected to work. : : As I can see from specification, if sc->wire4 is set to 0 by default, : bus will not ever switched into 4bit mode. Try to just comment out " && : sc->wire4" part of at91_mci.c. If this variable expected to report real : bus width, then it probably should be done in different way, by : reporting correct host capabilities. sc is initialized to 0 by the bus layer, so I don't think this will have an effect. You are correct that this should be generic in the board-level specific meta-data for each at91 board. That stuff just isn't there yet. The problem is, I think, that something broke in the series of commits and now reads don't work at all anymore. After the first couple in the series, I didn't test the follow on commits due to time. Warner : > PS: For MMC cards bus width testing routine implemented. May be we could : > do something alike for SD cards. It is not part of SD specification, but : > may be we could just issue some other command, transferring data, to : > check effective bus width. : : -- : Alexander Motin : : From mav at FreeBSD.org Tue Jan 20 11:09:13 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Jan 20 11:09:19 2009 Subject: Mount root from SD card? In-Reply-To: <20090120.114051.-854291995.imp@bsdimp.com> References: <1232400185.00063286.1232389201@10.7.7.3> <1232450582.00063538.1232438401@10.7.7.3> <49760E8E.1000609@FreeBSD.org> <20090120.114051.-854291995.imp@bsdimp.com> Message-ID: <4976215B.40302@FreeBSD.org> M. Warner Losh wrote: > In message: <49760E8E.1000609@FreeBSD.org> > Alexander Motin writes: > : Krassimir Slavchev wrote: > : > -----BEGIN PGP SIGNED MESSAGE----- > : > Hash: SHA1 > : > > : > M. Warner Losh wrote: > : > ... > : >> mmcsd0: 1983MB at mmc0 30MHz/1bit > : >> Trying to mount root from ufs:/dev/mmcsd0s1 > : >> > : >> Manual root filesystem specification: > : >> : Mount using filesystem > : >> eg. ufs:/dev/da0a > : >> ? List valid disk boot devices > : >> Abort manual input > : >> > : >> mountroot> ? > : >> > : >> List of GEOM managed disk devices: > : >> mmcsd0 > : >> > : >>> Looks like that should be working. > : >>> mav@ has done a lot of hacking on the mmc code... > : >>> Do you have 1 wire or 4 wires for your mmc bus on your board? > : > > : > On the board all 4 bus wires are connected (MCD A0-A3) but I've never > : > seen working 4-bit mode on AT91RM9200 (See PR128987 too). > : > : I have just committed MMCBR_IVAR_CAPS implementation into CURRENT. > : Without having it implemented, results can be unpredictable. For > : example, mmc layer could enable high-speed timings to reach 30MHz, but > : this mode is not implemented for this controller. Booting with verbose > : messages enabled could give a bit more information. > > This controller's driver should do the right thing when given a too > high bus speed: clamp it to the maximum... > > However, maybe the clamps are right. The above symptom was what I'd > see when the data read in was corrupted. It is the whole reason I > never enabled the multi-block read for this controller. I could never > make it work well enough to even make mountroot happy. High-speed timings does not mean just a high frequency. It is some different signaling scheme required for higher frequencies, which should be explicitly enabled on both card and controller. If one of them is not enabled - there will be problems. > : What's about 4-bit mode, I see some sc->wire4 variable checked by the > : driver, which is never initialized. I don't very understand how this > : thing expected to work. > > It is initialized to zero. It is expected that there will be a > different mechanism in the future to set it generically on a per-board > basis. IMHO it is incorrect to disable 4bit mode on that stage, it is too late there. It should be done at controller capabilities announcement stage. If you are not objecting, I would remove that wire4 variable. -- Alexander Motin From imp at bsdimp.com Tue Jan 20 11:24:01 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Jan 20 11:24:07 2009 Subject: Mount root from SD card? In-Reply-To: <4976215B.40302@FreeBSD.org> References: <49760E8E.1000609@FreeBSD.org> <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> Message-ID: <20090120.122312.1543793985.imp@bsdimp.com> In message: <4976215B.40302@FreeBSD.org> Alexander Motin writes: : M. Warner Losh wrote: : > In message: <49760E8E.1000609@FreeBSD.org> : > Alexander Motin writes: : > : Krassimir Slavchev wrote: : > : > -----BEGIN PGP SIGNED MESSAGE----- : > : > Hash: SHA1 : > : > : > : > M. Warner Losh wrote: : > : > ... : > : >> mmcsd0: 1983MB at mmc0 30MHz/1bit : > : >> Trying to mount root from ufs:/dev/mmcsd0s1 : > : >> : > : >> Manual root filesystem specification: : > : >> : Mount using filesystem : > : >> eg. ufs:/dev/da0a : > : >> ? List valid disk boot devices : > : >> Abort manual input : > : >> : > : >> mountroot> ? : > : >> : > : >> List of GEOM managed disk devices: : > : >> mmcsd0 : > : >> : > : >>> Looks like that should be working. : > : >>> mav@ has done a lot of hacking on the mmc code... : > : >>> Do you have 1 wire or 4 wires for your mmc bus on your board? : > : > : > : > On the board all 4 bus wires are connected (MCD A0-A3) but I've never : > : > seen working 4-bit mode on AT91RM9200 (See PR128987 too). : > : : > : I have just committed MMCBR_IVAR_CAPS implementation into CURRENT. : > : Without having it implemented, results can be unpredictable. For : > : example, mmc layer could enable high-speed timings to reach 30MHz, but : > : this mode is not implemented for this controller. Booting with verbose : > : messages enabled could give a bit more information. : > : > This controller's driver should do the right thing when given a too : > high bus speed: clamp it to the maximum... : > : > However, maybe the clamps are right. The above symptom was what I'd : > see when the data read in was corrupted. It is the whole reason I : > never enabled the multi-block read for this controller. I could never : > make it work well enough to even make mountroot happy. : : High-speed timings does not mean just a high frequency. It is some : different signaling scheme required for higher frequencies, which should : be explicitly enabled on both card and controller. If one of them is not : enabled - there will be problems. Ah, true. That does need to be a capability then. : > : What's about 4-bit mode, I see some sc->wire4 variable checked by the : > : driver, which is never initialized. I don't very understand how this : > : thing expected to work. : > : > It is initialized to zero. It is expected that there will be a : > different mechanism in the future to set it generically on a per-board : > basis. : : IMHO it is incorrect to disable 4bit mode on that stage, it is too late : there. It should be done at controller capabilities announcement stage. : If you are not objecting, I would remove that wire4 variable. I am objecting. The code is there so that the rest of the driver does the right thing when doing 4-bit. It needs to be a capability too. However, before we go monkeying with this, we need to find the underlying bug. Warner From mav at FreeBSD.org Tue Jan 20 11:29:35 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Jan 20 11:29:42 2009 Subject: Mount root from SD card? In-Reply-To: <20090120.122312.1543793985.imp@bsdimp.com> References: <49760E8E.1000609@FreeBSD.org> <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> Message-ID: <49762621.70104@FreeBSD.org> M. Warner Losh wrote: > In message: <4976215B.40302@FreeBSD.org> > Alexander Motin writes: > : M. Warner Losh wrote: > : > In message: <49760E8E.1000609@FreeBSD.org> > : > Alexander Motin writes: > : > : Krassimir Slavchev wrote: > : > : > -----BEGIN PGP SIGNED MESSAGE----- > : > : > Hash: SHA1 > : > : > > : > : > M. Warner Losh wrote: > : > : > ... > : > : >> mmcsd0: 1983MB at mmc0 30MHz/1bit > : > : >> Trying to mount root from ufs:/dev/mmcsd0s1 > : > : >> > : > : >> Manual root filesystem specification: > : > : >> : Mount using filesystem > : > : >> eg. ufs:/dev/da0a > : > : >> ? List valid disk boot devices > : > : >> Abort manual input > : > : >> > : > : >> mountroot> ? > : > : >> > : > : >> List of GEOM managed disk devices: > : > : >> mmcsd0 > : > : >> > : > : >>> Looks like that should be working. > : > : >>> mav@ has done a lot of hacking on the mmc code... > : > : >>> Do you have 1 wire or 4 wires for your mmc bus on your board? > : > : > > : > : > On the board all 4 bus wires are connected (MCD A0-A3) but I've never > : > : > seen working 4-bit mode on AT91RM9200 (See PR128987 too). > : > : > : > : I have just committed MMCBR_IVAR_CAPS implementation into CURRENT. > : > : Without having it implemented, results can be unpredictable. For > : > : example, mmc layer could enable high-speed timings to reach 30MHz, but > : > : this mode is not implemented for this controller. Booting with verbose > : > : messages enabled could give a bit more information. > : > > : > This controller's driver should do the right thing when given a too > : > high bus speed: clamp it to the maximum... > : > > : > However, maybe the clamps are right. The above symptom was what I'd > : > see when the data read in was corrupted. It is the whole reason I > : > never enabled the multi-block read for this controller. I could never > : > make it work well enough to even make mountroot happy. > : > : High-speed timings does not mean just a high frequency. It is some > : different signaling scheme required for higher frequencies, which should > : be explicitly enabled on both card and controller. If one of them is not > : enabled - there will be problems. > > Ah, true. That does need to be a capability then. > > : > : What's about 4-bit mode, I see some sc->wire4 variable checked by the > : > : driver, which is never initialized. I don't very understand how this > : > : thing expected to work. > : > > : > It is initialized to zero. It is expected that there will be a > : > different mechanism in the future to set it generically on a per-board > : > basis. > : > : IMHO it is incorrect to disable 4bit mode on that stage, it is too late > : there. It should be done at controller capabilities announcement stage. > : If you are not objecting, I would remove that wire4 variable. > > I am objecting. The code is there so that the rest of the driver does > the right thing when doing 4-bit. It needs to be a capability too. > > However, before we go monkeying with this, we need to find the > underlying bug. Bug of not working 4-bit mode? I have told why it is not working: because zeroed wire4 variable permanently disables it by clearing respective bit in controller SDCR register. I can't imagine any possible usage for this variable in present state. Can you? -- Alexander Motin From imp at bsdimp.com Tue Jan 20 11:33:16 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Jan 20 11:33:22 2009 Subject: Mount root from SD card? In-Reply-To: <20090120.122312.1543793985.imp@bsdimp.com> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> Message-ID: <20090120.123230.-272218744.imp@bsdimp.com> In message: <20090120.122312.1543793985.imp@bsdimp.com> "M. Warner Losh" writes: : : IMHO it is incorrect to disable 4bit mode on that stage, it is too late : : there. It should be done at controller capabilities announcement stage. : : If you are not objecting, I would remove that wire4 variable. : : I am objecting. The code is there so that the rest of the driver does : the right thing when doing 4-bit. It needs to be a capability too. : : However, before we go monkeying with this, we need to find the : underlying bug. I've got the following patch, untested, that I think does what I think needs to be done. Not sure about the return value from update_ios... Index: at91_mci.c =================================================================== --- at91_mci.c (revision 187479) +++ at91_mci.c (working copy) @@ -201,7 +201,10 @@ sc->host.f_min = 375000; sc->host.f_max = 30000000; sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; - sc->host.caps = MMC_CAP_4_BIT_DATA; + if (sc->wire4) + sc->host.caps = MMC_CAP_4_BIT_DATA; + else + sc->host.caps = 0; child = device_add_child(dev, "mmc", 0); device_set_ivars(dev, &sc->host); err = bus_generic_attach(dev); @@ -295,6 +298,8 @@ clkdiv = (at91_master_clock / ios->clock) / 2; } if (ios->bus_width == bus_width_4 && sc->wire4) + return EINVAL; + if (ios->bus_width == bus_width_4) WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) | MCI_SDCR_SDCBUS); else WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) & ~MCI_SDCR_SDCBUS); Warner From imp at bsdimp.com Tue Jan 20 11:36:00 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Jan 20 11:36:07 2009 Subject: Mount root from SD card? In-Reply-To: <49762621.70104@FreeBSD.org> References: <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <49762621.70104@FreeBSD.org> Message-ID: <20090120.123333.-2135184451.imp@bsdimp.com> In message: <49762621.70104@FreeBSD.org> Alexander Motin writes: : M. Warner Losh wrote: : > In message: <4976215B.40302@FreeBSD.org> : > Alexander Motin writes: : > : M. Warner Losh wrote: : > : > In message: <49760E8E.1000609@FreeBSD.org> : > : > Alexander Motin writes: : > : > : Krassimir Slavchev wrote: : > : > : > -----BEGIN PGP SIGNED MESSAGE----- : > : > : > Hash: SHA1 : > : > : > : > : > : > M. Warner Losh wrote: : > : > : > ... : > : > : >> mmcsd0: 1983MB at mmc0 30MHz/1bit : > : > : >> Trying to mount root from ufs:/dev/mmcsd0s1 : > : > : >> : > : > : >> Manual root filesystem specification: : > : > : >> : Mount using filesystem : > : > : >> eg. ufs:/dev/da0a : > : > : >> ? List valid disk boot devices : > : > : >> Abort manual input : > : > : >> : > : > : >> mountroot> ? : > : > : >> : > : > : >> List of GEOM managed disk devices: : > : > : >> mmcsd0 : > : > : >> : > : > : >>> Looks like that should be working. : > : > : >>> mav@ has done a lot of hacking on the mmc code... : > : > : >>> Do you have 1 wire or 4 wires for your mmc bus on your board? : > : > : > : > : > : > On the board all 4 bus wires are connected (MCD A0-A3) but I've never : > : > : > seen working 4-bit mode on AT91RM9200 (See PR128987 too). : > : > : : > : > : I have just committed MMCBR_IVAR_CAPS implementation into CURRENT. : > : > : Without having it implemented, results can be unpredictable. For : > : > : example, mmc layer could enable high-speed timings to reach 30MHz, but : > : > : this mode is not implemented for this controller. Booting with verbose : > : > : messages enabled could give a bit more information. : > : > : > : > This controller's driver should do the right thing when given a too : > : > high bus speed: clamp it to the maximum... : > : > : > : > However, maybe the clamps are right. The above symptom was what I'd : > : > see when the data read in was corrupted. It is the whole reason I : > : > never enabled the multi-block read for this controller. I could never : > : > make it work well enough to even make mountroot happy. : > : : > : High-speed timings does not mean just a high frequency. It is some : > : different signaling scheme required for higher frequencies, which should : > : be explicitly enabled on both card and controller. If one of them is not : > : enabled - there will be problems. : > : > Ah, true. That does need to be a capability then. : > : > : > : What's about 4-bit mode, I see some sc->wire4 variable checked by the : > : > : driver, which is never initialized. I don't very understand how this : > : > : thing expected to work. : > : > : > : > It is initialized to zero. It is expected that there will be a : > : > different mechanism in the future to set it generically on a per-board : > : > basis. : > : : > : IMHO it is incorrect to disable 4bit mode on that stage, it is too late : > : there. It should be done at controller capabilities announcement stage. : > : If you are not objecting, I would remove that wire4 variable. : > : > I am objecting. The code is there so that the rest of the driver does : > the right thing when doing 4-bit. It needs to be a capability too. : > : > However, before we go monkeying with this, we need to find the : > underlying bug. : : Bug of not working 4-bit mode? I have told why it is not working: : because zeroed wire4 variable permanently disables it by clearing : respective bit in controller SDCR register. I can't imagine any possible : usage for this variable in present state. Can you? Yes. You don't understand the history here. Keep it. I've sent my preferred patch. There's clearly a bug here, but wire4 is absolutely required to my future plans. Warner From mav at FreeBSD.org Tue Jan 20 11:58:37 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Jan 20 11:58:44 2009 Subject: Mount root from SD card? In-Reply-To: <20090120.123230.-272218744.imp@bsdimp.com> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> Message-ID: <49762CEF.1000405@FreeBSD.org> M. Warner Losh wrote: > In message: <20090120.122312.1543793985.imp@bsdimp.com> > "M. Warner Losh" writes: > : : IMHO it is incorrect to disable 4bit mode on that stage, it is too late > : : there. It should be done at controller capabilities announcement stage. > : : If you are not objecting, I would remove that wire4 variable. > : > : I am objecting. The code is there so that the rest of the driver does > : the right thing when doing 4-bit. It needs to be a capability too. > : > : However, before we go monkeying with this, we need to find the > : underlying bug. > > I've got the following patch, untested, that I think does what I think > needs to be done. Not sure about the return value from update_ios... > > Index: at91_mci.c > =================================================================== > --- at91_mci.c (revision 187479) > +++ at91_mci.c (working copy) > @@ -201,7 +201,10 @@ > sc->host.f_min = 375000; > sc->host.f_max = 30000000; > sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; > - sc->host.caps = MMC_CAP_4_BIT_DATA; > + if (sc->wire4) > + sc->host.caps = MMC_CAP_4_BIT_DATA; > + else > + sc->host.caps = 0; > child = device_add_child(dev, "mmc", 0); > device_set_ivars(dev, &sc->host); > err = bus_generic_attach(dev); Ok. I agree with this part. If for some reason you really need this wire4 variable, this is the right way to use it. > @@ -295,6 +298,8 @@ > clkdiv = (at91_master_clock / ios->clock) / 2; > } > if (ios->bus_width == bus_width_4 && sc->wire4) > + return EINVAL; > + if (ios->bus_width == bus_width_4) > WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) | MCI_SDCR_SDCBUS); > else > WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) & ~MCI_SDCR_SDCBUS); > This part is correct, but useless. If the first part have not set MMC_CAP_4_BIT_DATA, then mmc layer will never request bus_width_4. That's why I have proposed to remove " && sc->wire4" check from here. -- Alexander Motin From mav at FreeBSD.org Tue Jan 20 12:06:32 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Jan 20 12:06:38 2009 Subject: Mount root from SD card? In-Reply-To: <49762CEF.1000405@FreeBSD.org> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> Message-ID: <49762EC9.1010006@FreeBSD.org> Alexander Motin wrote: > M. Warner Losh wrote: >> In message: <20090120.122312.1543793985.imp@bsdimp.com> >> "M. Warner Losh" writes: >> : : IMHO it is incorrect to disable 4bit mode on that stage, it is too >> late : : there. It should be done at controller capabilities >> announcement stage. : : If you are not objecting, I would remove that >> wire4 variable. >> : : I am objecting. The code is there so that the rest of the driver >> does >> : the right thing when doing 4-bit. It needs to be a capability too. >> : : However, before we go monkeying with this, we need to find the >> : underlying bug. >> >> I've got the following patch, untested, that I think does what I think >> needs to be done. Not sure about the return value from update_ios... >> >> Index: at91_mci.c >> =================================================================== >> --- at91_mci.c (revision 187479) >> +++ at91_mci.c (working copy) >> @@ -201,7 +201,10 @@ >> sc->host.f_min = 375000; >> sc->host.f_max = 30000000; >> sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; >> - sc->host.caps = MMC_CAP_4_BIT_DATA; >> + if (sc->wire4) >> + sc->host.caps = MMC_CAP_4_BIT_DATA; >> + else >> + sc->host.caps = 0; >> child = device_add_child(dev, "mmc", 0); >> device_set_ivars(dev, &sc->host); >> err = bus_generic_attach(dev); > > Ok. I agree with this part. If for some reason you really need this > wire4 variable, this is the right way to use it. > >> @@ -295,6 +298,8 @@ >> clkdiv = (at91_master_clock / ios->clock) / 2; >> } >> if (ios->bus_width == bus_width_4 && sc->wire4) >> + return EINVAL; >> + if (ios->bus_width == bus_width_4) >> WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) | MCI_SDCR_SDCBUS); >> else >> WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) & ~MCI_SDCR_SDCBUS); >> > > This part is correct, but useless. If the first part have not set > MMC_CAP_4_BIT_DATA, then mmc layer will never request bus_width_4. > That's why I have proposed to remove " && sc->wire4" check from here. No, stop, this part is incorrect. Correct but useless would be: if (ios->bus_width == bus_width_4 && !sc->wire4) return EINVAL; -- Alexander Motin From mav at FreeBSD.org Wed Jan 21 00:54:28 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Jan 21 00:54:39 2009 Subject: Mount root from SD card? In-Reply-To: <49762EC9.1010006@FreeBSD.org> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> Message-ID: <4976E2C2.4090002@FreeBSD.org> Alexander Motin wrote: > Alexander Motin wrote: >> M. Warner Losh wrote: >>> In message: <20090120.122312.1543793985.imp@bsdimp.com> >>> "M. Warner Losh" writes: >>> : : IMHO it is incorrect to disable 4bit mode on that stage, it is >>> too late : : there. It should be done at controller capabilities >>> announcement stage. : : If you are not objecting, I would remove that >>> wire4 variable. >>> : : I am objecting. The code is there so that the rest of the driver >>> does >>> : the right thing when doing 4-bit. It needs to be a capability too. >>> : : However, before we go monkeying with this, we need to find the >>> : underlying bug. >>> >>> I've got the following patch, untested, that I think does what I think >>> needs to be done. Not sure about the return value from update_ios... I would prefer attached variant. It will also disable 4-bit support by default, but will make it properly. How do you plan to control that wire4 variable? With device.hints? -- Alexander Motin -------------- next part -------------- --- at91_mci.c.prev 2009-01-20 19:36:58.000000000 +0200 +++ at91_mci.c 2009-01-21 10:46:00.000000000 +0200 @@ -201,7 +201,10 @@ at91_mci_attach(device_t dev) sc->host.f_min = 375000; sc->host.f_max = 30000000; sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; - sc->host.caps = MMC_CAP_4_BIT_DATA; + if (sc->wire4) + sc->host.caps = MMC_CAP_4_BIT_DATA; + else + sc->host.caps = 0; child = device_add_child(dev, "mmc", 0); device_set_ivars(dev, &sc->host); err = bus_generic_attach(dev); @@ -294,7 +297,7 @@ at91_mci_update_ios(device_t brdev, devi else clkdiv = (at91_master_clock / ios->clock) / 2; } - if (ios->bus_width == bus_width_4 && sc->wire4) + if (ios->bus_width == bus_width_4) WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) | MCI_SDCR_SDCBUS); else WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) & ~MCI_SDCR_SDCBUS); From krassi at bulinfo.net Wed Jan 21 01:24:49 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Wed Jan 21 01:24:57 2009 Subject: Mount root from SD card? In-Reply-To: <4976E2C2.4090002@FreeBSD.org> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> Message-ID: <4976E9DB.3000803@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've tried the attached patch but the problem still exist. I see another strange things which may be related: On 7.1-STABLE: #fdisk -BI mmcsd0 ******* Working on device /dev/mmcsd0 ******* fdisk: Geom not found: "mmcsd0" #geom disk list Geom name: ad4 Providers: 1. Name: ad4 Mediasize: 250059350016 (233G) Sectorsize: 512 Mode: r5w5e6 fwsectors: 63 fwheads: 16 Geom name: mmcsd0 Providers: 1. Name: mmcsd0 Mediasize: 2012217344 (1.9G) Sectorsize: 512 Mode: r0w0e0 fwsectors: 0 fwheads: 0 Also sysinstall crashes when trying to create a new slice. May be because: Disk name: mmcsd0 FDISK Partition Editor DISK Geometry: 0 cyls/0 heads/0 sectors = 0 sectors (0MB) Alexander Motin wrote: > Alexander Motin wrote: >> Alexander Motin wrote: >>> M. Warner Losh wrote: >>>> In message: <20090120.122312.1543793985.imp@bsdimp.com> >>>> "M. Warner Losh" writes: >>>> : : IMHO it is incorrect to disable 4bit mode on that stage, it is >>>> too late : : there. It should be done at controller capabilities >>>> announcement stage. : : If you are not objecting, I would remove that >>>> wire4 variable. >>>> : : I am objecting. The code is there so that the rest of the driver >>>> does >>>> : the right thing when doing 4-bit. It needs to be a capability too. >>>> : : However, before we go monkeying with this, we need to find the >>>> : underlying bug. >>>> >>>> I've got the following patch, untested, that I think does what I think >>>> needs to be done. Not sure about the return value from update_ios... > > I would prefer attached variant. It will also disable 4-bit support by > default, but will make it properly. How do you plan to control that > wire4 variable? With device.hints? > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdunaxJBWvpalMpkRAjzPAJ9LA9ZhZjPjIQiod3T5kR/JtIFW9ACgqddT ZiXkmV7ByTiAXn4PIG7LFl4= =vyt3 -----END PGP SIGNATURE----- From mav at FreeBSD.org Wed Jan 21 01:50:39 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Jan 21 01:51:06 2009 Subject: Mount root from SD card? In-Reply-To: <4976E9DB.3000803@bulinfo.net> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> Message-ID: <4976EFED.4010706@FreeBSD.org> Krassimir Slavchev wrote: > I've tried the attached patch but the problem still exist. Then it is something different. It would be easier if I have some arm hardware to play with, but I have no. Try to apply this debugging patch. It should tell us what's going on there. > I see another strange things which may be related: > On 7.1-STABLE: > > #fdisk -BI mmcsd0 > > ******* Working on device /dev/mmcsd0 ******* > fdisk: Geom not found: "mmcsd0" > > #geom disk list > Geom name: ad4 > Providers: > 1. Name: ad4 > Mediasize: 250059350016 (233G) > Sectorsize: 512 > Mode: r5w5e6 > fwsectors: 63 > fwheads: 16 > > Geom name: mmcsd0 > Providers: > 1. Name: mmcsd0 > Mediasize: 2012217344 (1.9G) > Sectorsize: 512 > Mode: r0w0e0 > fwsectors: 0 > fwheads: 0 > > Also sysinstall crashes when trying to create a new slice. > May be because: > Disk name: mmcsd0 FDISK > Partition Editor > DISK Geometry: 0 cyls/0 heads/0 sectors = 0 sectors (0MB) I don't think it is related. There is no such thing as disk geometry on flash card, that's why driver does not announce it. The only places where it may be important is when fdisk is trying to align partitions with track boundaries for compatibility with legacy BIOS'es. There is no problem to report some fake values, but from one side they should better match BIOS assumptions on geometry and from other, they should as much as possible to match flash erase sector size. I just have no any system which supports SD booting to report something reasonable there. Reporting maximal 63 sectors per track as for HDD may result in ineffective filesystem alignment and reduced performance. -- Alexander Motin -------------- next part -------------- --- mmc.c.prev 2008-12-25 11:50:18.000000000 +0200 +++ mmc.c 2009-01-21 11:39:31.000000000 +0200 @@ -315,11 +315,14 @@ mmc_wait_for_req(struct mmc_softc *sc, s req->done = mmc_wakeup; req->done_data = sc; + printf("CMD: %x ARG %x len %d\n", req->cmd->opcode, req->cmd->arg, + (int)(req->cmd->data)?req->cmd->data->len:0); MMCBR_REQUEST(device_get_parent(sc->dev), sc->dev, req); MMC_LOCK(sc); while ((req->flags & MMC_REQ_DONE) == 0) msleep(req, &sc->sc_mtx, 0, "mmcreq", 0); MMC_UNLOCK(sc); + printf("RES: %d\n", req->cmd->error); return (0); } From krassi at bulinfo.net Wed Jan 21 02:40:16 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Wed Jan 21 02:40:26 2009 Subject: Mount root from SD card? In-Reply-To: <4976EFED.4010706@FreeBSD.org> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> Message-ID: <4976FB8C.5050209@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is the output: CMD: 0 ARG 0 len 0 RES: 0 CMD: 8 ARG 1aa len 0 RES: 1 CMD: 37 ARG 0 len 0 RES: 0 CMD: 29 ARG 0 len 0 RES: 0 CMD: 0 ARG 0 len 0 RES: 0 CMD: 8 ARG 1aa len 0 RES: 1 CMD: 37 ARG 0 len 0 RES: 0 CMD: 29 ARG ff8000 len 0 RES: 0 CMD: 37 ARG 0 len 0 RES: 0 CMD: 29 ARG ff8000 len 0 RES: 0 CMD: 2 ARG 0 len 0 RES: 0 CMD: 3 ARG 0 len 0 RES: 0 CMD: 9 ARG 10000 len 0 RES: 0 CMD: 7 ARG 10000 len 0 RES: 0 CMD: 37 ARG 10000 len 0 RES: 0 CMD: 33 ARG 0 len 8 RES: 0 CMD: 6 ARG ffffff len 64 RES: 0 CMD: 37 ARG 10000 len 0 RES: 0 CMD: d ARG 0 len 64 RES: 2 CMD: 37 ARG 10000 len 0 RES: 0 CMD: d ARG 0 len 64 RES: 0 CMD: 7 ARG 0 len 0 RES: 0 CMD: 7 ARG 10000 len 0 RES: 0 CMD: 7 ARG 0 len 0 RES: 0 CMD: 7 ARG 10000 len 0 RES: 2 CMD: 6 ARG 80fffff0 len 64 RES: 0 CMD: 7 ARG 0 len 0 RES: 0 mmcsd0: 1983MB at mmc0 30MHz/1bit CMD: 7 ARG 10000 len 0 RES: 2 CMD: 37 ARG 10000 len 0 RES: 0 CMD: 6 ARG 0 len 0 RES: 0 CMD: 11 ARG 0 len 512 RES: 0 CMD: 11 ARG 0 len 512 RES: 0 CMD: 11 ARG 200 len 512 RES: 0 Trying to mount root from ufs:/dev/mmcsd0s1 >> >> Also sysinstall crashes when trying to create a new slice. >> May be because: >> Disk name: mmcsd0 FDISK >> Partition Editor >> DISK Geometry: 0 cyls/0 heads/0 sectors = 0 sectors (0MB) > > I don't think it is related. There is no such thing as disk geometry on > flash card, that's why driver does not announce it. The only places > where it may be important is when fdisk is trying to align partitions > with track boundaries for compatibility with legacy BIOS'es. > > There is no problem to report some fake values, but from one side they > should better match BIOS assumptions on geometry and from other, they > should as much as possible to match flash erase sector size. I just have > no any system which supports SD booting to report something reasonable > there. Reporting maximal 63 sectors per track as for HDD may result in > ineffective filesystem alignment and reduced performance. > > At least sysinstall should be fixed. Should I fill a PR for this? Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdvuMxJBWvpalMpkRAryjAJ9v4cj1FCZHFUx/csHsa3SDrjodHwCeNMSi wgWK6W4prQzbjJqzitiqcnw= =F7xk -----END PGP SIGNATURE----- From mav at FreeBSD.org Wed Jan 21 05:01:30 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Jan 21 05:01:37 2009 Subject: Mount root from SD card? In-Reply-To: <4976FB8C.5050209@bulinfo.net> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> Message-ID: <49771CA6.7080106@FreeBSD.org> Krassimir Slavchev wrote: > This is the output: > > CMD: 0 ARG 0 len 0 > RES: 0 > CMD: 8 ARG 1aa len 0 > RES: 1 > CMD: 37 ARG 0 len 0 > RES: 0 > CMD: 29 ARG 0 len 0 > RES: 0 > CMD: 0 ARG 0 len 0 > RES: 0 > CMD: 8 ARG 1aa len 0 > RES: 1 > CMD: 37 ARG 0 len 0 > RES: 0 > CMD: 29 ARG ff8000 len 0 > RES: 0 > CMD: 37 ARG 0 len 0 > RES: 0 > CMD: 29 ARG ff8000 len 0 > RES: 0 > CMD: 2 ARG 0 len 0 > RES: 0 > CMD: 3 ARG 0 len 0 > RES: 0 > CMD: 9 ARG 10000 len 0 > RES: 0 > CMD: 7 ARG 10000 len 0 > RES: 0 > CMD: 37 ARG 10000 len 0 > RES: 0 > CMD: 33 ARG 0 len 8 > RES: 0 > CMD: 6 ARG ffffff len 64 > RES: 0 > CMD: 37 ARG 10000 len 0 > RES: 0 > CMD: d ARG 0 len 64 > RES: 2 > CMD: 37 ARG 10000 len 0 > RES: 0 > CMD: d ARG 0 len 64 > RES: 0 This part looks fine. Just normal SD detection and initialization. Somewhere here bus frequency and high-speed timings negotiated: > CMD: 7 ARG 0 len 0 > RES: 0 > CMD: 7 ARG 10000 len 0 > RES: 0 > CMD: 7 ARG 0 len 0 > RES: 0 > CMD: 7 ARG 10000 len 0 > RES: 2 > CMD: 6 ARG 80fffff0 len 64 > RES: 0 > CMD: 7 ARG 0 len 0 > RES: 0 > mmcsd0: 1983MB at mmc0 30MHz/1bit Then regular card activity beging: - select the card - error > CMD: 7 ARG 10000 len 0 > RES: 2 - select bus width - normal ?? > CMD: 37 ARG 10000 len 0 > RES: 0 > CMD: 6 ARG 0 len 0 > RES: 0 - read some sectors - normal ?? > CMD: 11 ARG 0 len 512 > RES: 0 > CMD: 11 ARG 0 len 512 > RES: 0 > CMD: 11 ARG 200 len 512 > RES: 0 > Trying to mount root from ufs:/dev/mmcsd0s1 It's a bis strange to me that this card selection request failed, while previous ones during initialization managed fine. May be card or controller unable to handle such speed, or may be bus just hasn't managed to settle new parameters until that command. Also interesting what are the reading command returned after card select command failed. Boot with verbose messages enabled should show when exactly frequency has changed. Do it please. >>> Also sysinstall crashes when trying to create a new slice. >>> May be because: >>> Disk name: mmcsd0 FDISK >>> Partition Editor >>> DISK Geometry: 0 cyls/0 heads/0 sectors = 0 sectors (0MB) >> I don't think it is related. There is no such thing as disk geometry on >> flash card, that's why driver does not announce it. The only places >> where it may be important is when fdisk is trying to align partitions >> with track boundaries for compatibility with legacy BIOS'es. > >> There is no problem to report some fake values, but from one side they >> should better match BIOS assumptions on geometry and from other, they >> should as much as possible to match flash erase sector size. I just have >> no any system which supports SD booting to report something reasonable >> there. Reporting maximal 63 sectors per track as for HDD may result in >> ineffective filesystem alignment and reduced performance. > > At least sysinstall should be fixed. Should I fill a PR for this? Probably yes. I haven't looked into sysinstall. -- Alexander Motin From krassi at bulinfo.net Wed Jan 21 05:30:27 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Wed Jan 21 05:30:35 2009 Subject: Mount root from SD card? In-Reply-To: <49771CA6.7080106@FreeBSD.org> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> Message-ID: <4977236E.2020409@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Boot with verbose messages is here: http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose Alexander Motin wrote: > Krassimir Slavchev wrote: >> This is the output: >> >> CMD: 0 ARG 0 len 0 >> RES: 0 >> CMD: 8 ARG 1aa len 0 >> RES: 1 >> CMD: 37 ARG 0 len 0 >> RES: 0 >> CMD: 29 ARG 0 len 0 >> RES: 0 >> CMD: 0 ARG 0 len 0 >> RES: 0 >> CMD: 8 ARG 1aa len 0 >> RES: 1 >> CMD: 37 ARG 0 len 0 >> RES: 0 >> CMD: 29 ARG ff8000 len 0 >> RES: 0 >> CMD: 37 ARG 0 len 0 >> RES: 0 >> CMD: 29 ARG ff8000 len 0 >> RES: 0 >> CMD: 2 ARG 0 len 0 >> RES: 0 >> CMD: 3 ARG 0 len 0 >> RES: 0 >> CMD: 9 ARG 10000 len 0 >> RES: 0 >> CMD: 7 ARG 10000 len 0 >> RES: 0 >> CMD: 37 ARG 10000 len 0 >> RES: 0 >> CMD: 33 ARG 0 len 8 >> RES: 0 >> CMD: 6 ARG ffffff len 64 >> RES: 0 >> CMD: 37 ARG 10000 len 0 >> RES: 0 >> CMD: d ARG 0 len 64 >> RES: 2 >> CMD: 37 ARG 10000 len 0 >> RES: 0 >> CMD: d ARG 0 len 64 >> RES: 0 > > This part looks fine. Just normal SD detection and initialization. > > Somewhere here bus frequency and high-speed timings negotiated: > >> CMD: 7 ARG 0 len 0 >> RES: 0 >> CMD: 7 ARG 10000 len 0 >> RES: 0 >> CMD: 7 ARG 0 len 0 >> RES: 0 >> CMD: 7 ARG 10000 len 0 >> RES: 2 >> CMD: 6 ARG 80fffff0 len 64 >> RES: 0 >> CMD: 7 ARG 0 len 0 >> RES: 0 >> mmcsd0: 1983MB at mmc0 30MHz/1bit > > Then regular card activity beging: > > - select the card - error >> CMD: 7 ARG 10000 len 0 >> RES: 2 > > - select bus width - normal ?? >> CMD: 37 ARG 10000 len 0 >> RES: 0 >> CMD: 6 ARG 0 len 0 >> RES: 0 > > - read some sectors - normal ?? >> CMD: 11 ARG 0 len 512 >> RES: 0 >> CMD: 11 ARG 0 len 512 >> RES: 0 >> CMD: 11 ARG 200 len 512 >> RES: 0 >> Trying to mount root from ufs:/dev/mmcsd0s1 > > It's a bis strange to me that this card selection request failed, while > previous ones during initialization managed fine. May be card or > controller unable to handle such speed, or may be bus just hasn't > managed to settle new parameters until that command. > Also interesting what are the reading command returned after card select > command failed. > > Boot with verbose messages enabled should show when exactly frequency > has changed. Do it please. > >>>> Also sysinstall crashes when trying to create a new slice. >>>> May be because: >>>> Disk name: mmcsd0 FDISK >>>> Partition Editor >>>> DISK Geometry: 0 cyls/0 heads/0 sectors = 0 sectors (0MB) >>> I don't think it is related. There is no such thing as disk geometry on >>> flash card, that's why driver does not announce it. The only places >>> where it may be important is when fdisk is trying to align partitions >>> with track boundaries for compatibility with legacy BIOS'es. >>> There is no problem to report some fake values, but from one side they >>> should better match BIOS assumptions on geometry and from other, they >>> should as much as possible to match flash erase sector size. I just have >>> no any system which supports SD booting to report something reasonable >>> there. Reporting maximal 63 sectors per track as for HDD may result in >>> ineffective filesystem alignment and reduced performance. >> At least sysinstall should be fixed. Should I fill a PR for this? > > Probably yes. I haven't looked into sysinstall. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdyNuxJBWvpalMpkRAljVAJ976HFJu0zPWWmgqSGM9NUkBFXltQCeO5am UNVeNhRajDLjuwMgqstKL1I= =V/UU -----END PGP SIGNATURE----- From krassi at bulinfo.net Wed Jan 21 05:45:33 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Wed Jan 21 05:45:40 2009 Subject: Mount root from SD card? In-Reply-To: <4977236E.2020409@bulinfo.net> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> Message-ID: <497726F5.5080000@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oops, sorry this output was without SD card inserted! I've changed the file. Best Regards Krassimir Slavchev wrote: > Boot with verbose messages is here: > > http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose > > > Alexander Motin wrote: >> Krassimir Slavchev wrote: >>> This is the output: >>> >>> CMD: 0 ARG 0 len 0 >>> RES: 0 >>> CMD: 8 ARG 1aa len 0 >>> RES: 1 >>> CMD: 37 ARG 0 len 0 >>> RES: 0 >>> CMD: 29 ARG 0 len 0 >>> RES: 0 >>> CMD: 0 ARG 0 len 0 >>> RES: 0 >>> CMD: 8 ARG 1aa len 0 >>> RES: 1 >>> CMD: 37 ARG 0 len 0 >>> RES: 0 >>> CMD: 29 ARG ff8000 len 0 >>> RES: 0 >>> CMD: 37 ARG 0 len 0 >>> RES: 0 >>> CMD: 29 ARG ff8000 len 0 >>> RES: 0 >>> CMD: 2 ARG 0 len 0 >>> RES: 0 >>> CMD: 3 ARG 0 len 0 >>> RES: 0 >>> CMD: 9 ARG 10000 len 0 >>> RES: 0 >>> CMD: 7 ARG 10000 len 0 >>> RES: 0 >>> CMD: 37 ARG 10000 len 0 >>> RES: 0 >>> CMD: 33 ARG 0 len 8 >>> RES: 0 >>> CMD: 6 ARG ffffff len 64 >>> RES: 0 >>> CMD: 37 ARG 10000 len 0 >>> RES: 0 >>> CMD: d ARG 0 len 64 >>> RES: 2 >>> CMD: 37 ARG 10000 len 0 >>> RES: 0 >>> CMD: d ARG 0 len 64 >>> RES: 0 >> This part looks fine. Just normal SD detection and initialization. > >> Somewhere here bus frequency and high-speed timings negotiated: > >>> CMD: 7 ARG 0 len 0 >>> RES: 0 >>> CMD: 7 ARG 10000 len 0 >>> RES: 0 >>> CMD: 7 ARG 0 len 0 >>> RES: 0 >>> CMD: 7 ARG 10000 len 0 >>> RES: 2 >>> CMD: 6 ARG 80fffff0 len 64 >>> RES: 0 >>> CMD: 7 ARG 0 len 0 >>> RES: 0 >>> mmcsd0: 1983MB at mmc0 30MHz/1bit >> Then regular card activity beging: > >> - select the card - error >>> CMD: 7 ARG 10000 len 0 >>> RES: 2 >> - select bus width - normal ?? >>> CMD: 37 ARG 10000 len 0 >>> RES: 0 >>> CMD: 6 ARG 0 len 0 >>> RES: 0 >> - read some sectors - normal ?? >>> CMD: 11 ARG 0 len 512 >>> RES: 0 >>> CMD: 11 ARG 0 len 512 >>> RES: 0 >>> CMD: 11 ARG 200 len 512 >>> RES: 0 >>> Trying to mount root from ufs:/dev/mmcsd0s1 >> It's a bis strange to me that this card selection request failed, while >> previous ones during initialization managed fine. May be card or >> controller unable to handle such speed, or may be bus just hasn't >> managed to settle new parameters until that command. >> Also interesting what are the reading command returned after card select >> command failed. > >> Boot with verbose messages enabled should show when exactly frequency >> has changed. Do it please. > >>>>> Also sysinstall crashes when trying to create a new slice. >>>>> May be because: >>>>> Disk name: mmcsd0 FDISK >>>>> Partition Editor >>>>> DISK Geometry: 0 cyls/0 heads/0 sectors = 0 sectors (0MB) >>>> I don't think it is related. There is no such thing as disk geometry on >>>> flash card, that's why driver does not announce it. The only places >>>> where it may be important is when fdisk is trying to align partitions >>>> with track boundaries for compatibility with legacy BIOS'es. >>>> There is no problem to report some fake values, but from one side they >>>> should better match BIOS assumptions on geometry and from other, they >>>> should as much as possible to match flash erase sector size. I just have >>>> no any system which supports SD booting to report something reasonable >>>> there. Reporting maximal 63 sectors per track as for HDD may result in >>>> ineffective filesystem alignment and reduced performance. >>> At least sysinstall should be fixed. Should I fill a PR for this? >> Probably yes. I haven't looked into sysinstall. > > _______________________________________________ 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdyb0xJBWvpalMpkRAp6fAJ4/nwjwzvJ2gJuH8pGSpjKKhSZFBQCggIhs 1kc1rDx4i88ulndFuCLIW1Q= =lwV7 -----END PGP SIGNATURE----- From mav at FreeBSD.org Wed Jan 21 05:59:11 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Jan 21 05:59:17 2009 Subject: Mount root from SD card? In-Reply-To: <497726F5.5080000@bulinfo.net> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> <497726F5.5080000@bulinfo.net> Message-ID: <49772A2C.7090903@FreeBSD.org> Krassimir Slavchev wrote: > Oops, sorry this output was without SD card inserted! > I've changed the file. That's some different debugging. I have meant that one, which happens when boot_verbose="YES" added to loader.conf, or respective Fx button pressed during boot on PC. -- Alexander Motin From krassi at bulinfo.net Wed Jan 21 06:09:22 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Wed Jan 21 06:09:28 2009 Subject: Mount root from SD card? In-Reply-To: <49772A2C.7090903@FreeBSD.org> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> <497726F5.5080000@bulinfo.net> <49772A2C.7090903@FreeBSD.org> Message-ID: <49772C8A.5020402@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexander Motin wrote: > Krassimir Slavchev wrote: >> Oops, sorry this output was without SD card inserted! >> I've changed the file. > > That's some different debugging. I have meant that one, which happens > when boot_verbose="YES" added to loader.conf, or respective Fx button > pressed during boot on PC. > Yes this is with kernel VERBOSE_SYSINIT option because I cannot set boot_verbose from arm boot loader. Verbose messages from which modules you want to see? I will set bootverbose manually. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdyyKxJBWvpalMpkRAsBbAKCLUOVoOsBScAqSOkSbSPuedqQi/gCZAcU5 PzlVXZfnW4xDrs5lwrISpd4= =wWIY -----END PGP SIGNATURE----- From mav at FreeBSD.org Wed Jan 21 06:19:50 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Jan 21 06:19:57 2009 Subject: Mount root from SD card? In-Reply-To: <49772C8A.5020402@bulinfo.net> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> <497726F5.5080000@bulinfo.net> <49772A2C.7090903@FreeBSD.org> <49772C8A.5020402@bulinfo.net> Message-ID: <49772EF1.1060207@FreeBSD.org> Krassimir Slavchev wrote: > Alexander Motin wrote: >> Krassimir Slavchev wrote: >>> Oops, sorry this output was without SD card inserted! >>> I've changed the file. >> That's some different debugging. I have meant that one, which happens >> when boot_verbose="YES" added to loader.conf, or respective Fx button >> pressed during boot on PC. > > Yes this is with kernel VERBOSE_SYSINIT option because I cannot set > boot_verbose from arm boot loader. > Verbose messages from which modules you want to see? I will set > bootverbose manually. mmc. And while being there, apply this one please. -- Alexander Motin -------------- next part -------------- --- mmc.c1 2008-12-25 11:50:18.000000000 +0200 +++ mmc.c 2009-01-21 16:15:27.000000000 +0200 @@ -1322,11 +1322,12 @@ mmc_calculate_clock(struct mmc_softc *sc panic("can't get children"); for (i = 0; i < nkid; i++) { ivar = device_get_ivars(kids[i]); +printf("timing %d, rate %d, hsrate %d\n", ivar->timing, ivar->tran_speed, ivar->hs_tran_speed); if (ivar->timing < max_timing) max_timing = ivar->timing; if (ivar->tran_speed < max_dtr) max_dtr = ivar->tran_speed; - if (ivar->hs_tran_speed < max_dtr) + if (ivar->hs_tran_speed < max_hs_dtr) max_hs_dtr = ivar->hs_tran_speed; } for (i = 0; i < nkid; i++) { From krassi at bulinfo.net Wed Jan 21 06:26:47 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Wed Jan 21 06:26:54 2009 Subject: Mount root from SD card? In-Reply-To: <49772EF1.1060207@FreeBSD.org> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> <497726F5.5080000@bulinfo.net> <49772A2C.7090903@FreeBSD.org> <49772C8A.5020402@bulinfo.net> <49772EF1.1060207@FreeBSD.org> Message-ID: <4977309F.2020402@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... CMD: 7 ARG 0 len 0 RES: 0 timing 1, rate 30000000, hsrate 50000000 CMD: 7 ARG 10000 len 0 RES: 2 CMD: 6 ARG 80fffff0 len 64 RES: 0 CMD: 7 ARG 0 len 0 RES: 0 mmc0: setting transfer rate to 30.000MHz mmcsd0: 1983MB at mmc0 30MHz/1bit CMD: 7 ARG 10000 len 0 RES: 2 mmc0: setting bus width to 1 bits CMD: 37 ARG 10000 len 0 RES: 0 CMD: 6 ARG 0 len 0 RES: 0 CMD: 11 ARG 0 len 512 RES: 0 CMD: 11 ARG 0 len 512 RES: 0 CMD: 11 ARG 200 len 512 RES: 0 Trying to mount root from ufs:/dev/mmcsd0s1 Alexander Motin wrote: > Krassimir Slavchev wrote: >> Alexander Motin wrote: >>> Krassimir Slavchev wrote: >>>> Oops, sorry this output was without SD card inserted! >>>> I've changed the file. >>> That's some different debugging. I have meant that one, which happens >>> when boot_verbose="YES" added to loader.conf, or respective Fx button >>> pressed during boot on PC. >> Yes this is with kernel VERBOSE_SYSINIT option because I cannot set >> boot_verbose from arm boot loader. >> Verbose messages from which modules you want to see? I will set >> bootverbose manually. > > mmc. And while being there, apply this one please. > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdzCfxJBWvpalMpkRAm1AAKCwNkuBrI6uBwfC4ZlrkpLgTqXc/wCeIM0j AGdwpQCQvBceK1HzyCF7xEM= =TLd2 -----END PGP SIGNATURE----- From imp at bsdimp.com Wed Jan 21 07:35:47 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Jan 21 07:35:54 2009 Subject: Mount root from SD card? In-Reply-To: <4976E2C2.4090002@FreeBSD.org> References: <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> Message-ID: <20090121.083438.1081366624.imp@bsdimp.com> In message: <4976E2C2.4090002@FreeBSD.org> Alexander Motin writes: : Alexander Motin wrote: : > Alexander Motin wrote: : >> M. Warner Losh wrote: : >>> In message: <20090120.122312.1543793985.imp@bsdimp.com> : >>> "M. Warner Losh" writes: : >>> : : IMHO it is incorrect to disable 4bit mode on that stage, it is : >>> too late : : there. It should be done at controller capabilities : >>> announcement stage. : : If you are not objecting, I would remove that : >>> wire4 variable. : >>> : : I am objecting. The code is there so that the rest of the driver : >>> does : >>> : the right thing when doing 4-bit. It needs to be a capability too. : >>> : : However, before we go monkeying with this, we need to find the : >>> : underlying bug. : >>> : >>> I've got the following patch, untested, that I think does what I think : >>> needs to be done. Not sure about the return value from update_ios... : : I would prefer attached variant. It will also disable 4-bit support by : default, but will make it properly. How do you plan to control that : wire4 variable? With device.hints? It is part of the board-variant work that I have in flight. I'm not 100% sure the exact mechanism, but the meta-data about how the device is wired will be provided by "the parent device" in some way. I'm still working out the details. Warner From imp at bsdimp.com Wed Jan 21 07:42:57 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Jan 21 07:43:18 2009 Subject: Mount root from SD card? In-Reply-To: <49772A2C.7090903@FreeBSD.org> References: <4977236E.2020409@bulinfo.net> <497726F5.5080000@bulinfo.net> <49772A2C.7090903@FreeBSD.org> Message-ID: <20090121.084141.-1119405090.imp@bsdimp.com> In message: <49772A2C.7090903@FreeBSD.org> Alexander Motin writes: : Krassimir Slavchev wrote: : > Oops, sorry this output was without SD card inserted! : > I've changed the file. : : That's some different debugging. I have meant that one, which happens : when boot_verbose="YES" added to loader.conf, or respective Fx button : pressed during boot on PC. You can't do either of those on the ARM platform. Warner From imp at bsdimp.com Wed Jan 21 07:42:59 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Jan 21 07:43:19 2009 Subject: Mount root from SD card? In-Reply-To: <49772C8A.5020402@bulinfo.net> References: <497726F5.5080000@bulinfo.net> <49772A2C.7090903@FreeBSD.org> <49772C8A.5020402@bulinfo.net> Message-ID: <20090121.084202.96341656.imp@bsdimp.com> In message: <49772C8A.5020402@bulinfo.net> Krassimir Slavchev writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : Alexander Motin wrote: : > Krassimir Slavchev wrote: : >> Oops, sorry this output was without SD card inserted! : >> I've changed the file. : > : > That's some different debugging. I have meant that one, which happens : > when boot_verbose="YES" added to loader.conf, or respective Fx button : > pressed during boot on PC. : > : : Yes this is with kernel VERBOSE_SYSINIT option because I cannot set : boot_verbose from arm boot loader. : Verbose messages from which modules you want to see? I will set : bootverbose manually. Which boot loader are you using? Warner From imp at bsdimp.com Wed Jan 21 07:43:00 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Jan 21 07:43:20 2009 Subject: Mount root from SD card? In-Reply-To: <4977236E.2020409@bulinfo.net> References: <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> Message-ID: <20090121.084023.188100520.imp@bsdimp.com> In message: <4977236E.2020409@bulinfo.net> Krassimir Slavchev writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : Boot with verbose messages is here: : : http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose This looks very similar to the data corruption I saw when I had enabled multiblock read. To track this down, we're going to have to print the actual data returned for each sector... Warner : Alexander Motin wrote: : > Krassimir Slavchev wrote: : >> This is the output: : >> : >> CMD: 0 ARG 0 len 0 : >> RES: 0 : >> CMD: 8 ARG 1aa len 0 : >> RES: 1 : >> CMD: 37 ARG 0 len 0 : >> RES: 0 : >> CMD: 29 ARG 0 len 0 : >> RES: 0 : >> CMD: 0 ARG 0 len 0 : >> RES: 0 : >> CMD: 8 ARG 1aa len 0 : >> RES: 1 : >> CMD: 37 ARG 0 len 0 : >> RES: 0 : >> CMD: 29 ARG ff8000 len 0 : >> RES: 0 : >> CMD: 37 ARG 0 len 0 : >> RES: 0 : >> CMD: 29 ARG ff8000 len 0 : >> RES: 0 : >> CMD: 2 ARG 0 len 0 : >> RES: 0 : >> CMD: 3 ARG 0 len 0 : >> RES: 0 : >> CMD: 9 ARG 10000 len 0 : >> RES: 0 : >> CMD: 7 ARG 10000 len 0 : >> RES: 0 : >> CMD: 37 ARG 10000 len 0 : >> RES: 0 : >> CMD: 33 ARG 0 len 8 : >> RES: 0 : >> CMD: 6 ARG ffffff len 64 : >> RES: 0 : >> CMD: 37 ARG 10000 len 0 : >> RES: 0 : >> CMD: d ARG 0 len 64 : >> RES: 2 : >> CMD: 37 ARG 10000 len 0 : >> RES: 0 : >> CMD: d ARG 0 len 64 : >> RES: 0 : > : > This part looks fine. Just normal SD detection and initialization. : > : > Somewhere here bus frequency and high-speed timings negotiated: : > : >> CMD: 7 ARG 0 len 0 : >> RES: 0 : >> CMD: 7 ARG 10000 len 0 : >> RES: 0 : >> CMD: 7 ARG 0 len 0 : >> RES: 0 : >> CMD: 7 ARG 10000 len 0 : >> RES: 2 : >> CMD: 6 ARG 80fffff0 len 64 : >> RES: 0 : >> CMD: 7 ARG 0 len 0 : >> RES: 0 : >> mmcsd0: 1983MB at mmc0 30MHz/1bit : > : > Then regular card activity beging: : > : > - select the card - error : >> CMD: 7 ARG 10000 len 0 : >> RES: 2 : > : > - select bus width - normal ?? : >> CMD: 37 ARG 10000 len 0 : >> RES: 0 : >> CMD: 6 ARG 0 len 0 : >> RES: 0 : > : > - read some sectors - normal ?? : >> CMD: 11 ARG 0 len 512 : >> RES: 0 : >> CMD: 11 ARG 0 len 512 : >> RES: 0 : >> CMD: 11 ARG 200 len 512 : >> RES: 0 : >> Trying to mount root from ufs:/dev/mmcsd0s1 : > : > It's a bis strange to me that this card selection request failed, while : > previous ones during initialization managed fine. May be card or : > controller unable to handle such speed, or may be bus just hasn't : > managed to settle new parameters until that command. : > Also interesting what are the reading command returned after card select : > command failed. : > : > Boot with verbose messages enabled should show when exactly frequency : > has changed. Do it please. : > : >>>> Also sysinstall crashes when trying to create a new slice. : >>>> May be because: : >>>> Disk name: mmcsd0 FDISK : >>>> Partition Editor : >>>> DISK Geometry: 0 cyls/0 heads/0 sectors = 0 sectors (0MB) : >>> I don't think it is related. There is no such thing as disk geometry on : >>> flash card, that's why driver does not announce it. The only places : >>> where it may be important is when fdisk is trying to align partitions : >>> with track boundaries for compatibility with legacy BIOS'es. : >>> There is no problem to report some fake values, but from one side they : >>> should better match BIOS assumptions on geometry and from other, they : >>> should as much as possible to match flash erase sector size. I just have : >>> no any system which supports SD booting to report something reasonable : >>> there. Reporting maximal 63 sectors per track as for HDD may result in : >>> ineffective filesystem alignment and reduced performance. : >> At least sysinstall should be fixed. Should I fill a PR for this? : > : > Probably yes. I haven't looked into sysinstall. : > : : -----BEGIN PGP SIGNATURE----- : Version: GnuPG v1.4.7 (FreeBSD) : : iD8DBQFJdyNuxJBWvpalMpkRAljVAJ976HFJu0zPWWmgqSGM9NUkBFXltQCeO5am : UNVeNhRajDLjuwMgqstKL1I= : =V/UU : -----END PGP SIGNATURE----- : : From krassi at bulinfo.net Wed Jan 21 07:50:57 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Wed Jan 21 07:51:03 2009 Subject: Mount root from SD card? In-Reply-To: <20090121.084202.96341656.imp@bsdimp.com> References: <497726F5.5080000@bulinfo.net> <49772A2C.7090903@FreeBSD.org> <49772C8A.5020402@bulinfo.net> <20090121.084202.96341656.imp@bsdimp.com> Message-ID: <4977445C.1090504@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: > In message: <49772C8A.5020402@bulinfo.net> > Krassimir Slavchev writes: > : -----BEGIN PGP SIGNED MESSAGE----- > : Hash: SHA1 > : > : Alexander Motin wrote: > : > Krassimir Slavchev wrote: > : >> Oops, sorry this output was without SD card inserted! > : >> I've changed the file. > : > > : > That's some different debugging. I have meant that one, which happens > : > when boot_verbose="YES" added to loader.conf, or respective Fx button > : > pressed during boot on PC. > : > > : > : Yes this is with kernel VERBOSE_SYSINIT option because I cannot set > : boot_verbose from arm boot loader. > : Verbose messages from which modules you want to see? I will set > : bootverbose manually. > > Which boot loader are you using? > > Warner > I am using bootspi to boot from TFTP server. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJd0RcxJBWvpalMpkRAo1VAJ4noAvXXowkr6StHIp5gJR5RdvA5gCdF/OM XBYxIDm3WK8iOFMpH529IHE= =Qbu+ -----END PGP SIGNATURE----- From imp at bsdimp.com Wed Jan 21 08:03:09 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Jan 21 08:03:16 2009 Subject: Mount root from SD card? In-Reply-To: <4977445C.1090504@bulinfo.net> References: <49772C8A.5020402@bulinfo.net> <20090121.084202.96341656.imp@bsdimp.com> <4977445C.1090504@bulinfo.net> Message-ID: <20090121.090054.107772597.imp@bsdimp.com> In message: <4977445C.1090504@bulinfo.net> Krassimir Slavchev writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : M. Warner Losh wrote: : > In message: <49772C8A.5020402@bulinfo.net> : > Krassimir Slavchev writes: : > : -----BEGIN PGP SIGNED MESSAGE----- : > : Hash: SHA1 : > : : > : Alexander Motin wrote: : > : > Krassimir Slavchev wrote: : > : >> Oops, sorry this output was without SD card inserted! : > : >> I've changed the file. : > : > : > : > That's some different debugging. I have meant that one, which happens : > : > when boot_verbose="YES" added to loader.conf, or respective Fx button : > : > pressed during boot on PC. : > : > : > : : > : Yes this is with kernel VERBOSE_SYSINIT option because I cannot set : > : boot_verbose from arm boot loader. : > : Verbose messages from which modules you want to see? I will set : > : bootverbose manually. : > : > Which boot loader are you using? : > : > Warner : > : : I am using bootspi to boot from TFTP server. Hmmmm.... That makes it harder to add a -v flag to get bootverbose... Warner From mav at FreeBSD.org Wed Jan 21 08:10:04 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Jan 21 08:10:11 2009 Subject: Mount root from SD card? In-Reply-To: <4977309F.2020402@bulinfo.net> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> <497726F5.5080000@bulinfo.net> <49772A2C.7090903@FreeBSD.org> <49772C8A.5020402@bulinfo.net> <49772EF1.1060207@FreeBSD.org> <4977309F.2020402@bulinfo.net> Message-ID: <497748D9.2040607@FreeBSD.org> Krassimir Slavchev wrote: > ... > CMD: 7 ARG 0 len 0 > RES: 0 Before this point mmc_rescan_cards() have successfully selected all the cards. Then at this point mmcbr_set_bus_mode(dev, pushpull); mmcbr_update_ios(dev); were called. And after that same request inside mmc_calculate_clock() has failed. That's strange. > timing 1, rate 30000000, hsrate 50000000 > CMD: 7 ARG 10000 len 0 > RES: 2 Open drain bus mode control is not implemented by sdhci driver, so I haven't looked at it close. Quick look around shows that push-pull mode was set there even without that last call. May be I am wrong, but first line looks useless. mmcbr_update_ios(dev) writes to the controller bus control registers, may be it affects something, or bus require some time to settle after it? > CMD: 6 ARG 80fffff0 len 64 > RES: 0 > CMD: 7 ARG 0 len 0 > RES: 0 > mmc0: setting transfer rate to 30.000MHz > mmcsd0: 1983MB at mmc0 30MHz/1bit Bus frequency changed here. SD specification allows frequencies up to 25MHz without high speed timings used, but cards like this one ofter declare a bit higher frequencies in legacy mode. May be we should just to try to limit it to some safe value? You may just try to set max_dtr = 5000000; in mmc_calculate_clock(), before "if (bootverbose) {". > CMD: 7 ARG 10000 len 0 > RES: 2 > mmc0: setting bus width to 1 bits > CMD: 37 ARG 10000 len 0 > RES: 0 > CMD: 6 ARG 0 len 0 > RES: 0 > CMD: 11 ARG 0 len 512 > RES: 0 > CMD: 11 ARG 0 len 512 > RES: 0 > CMD: 11 ARG 200 len 512 > RES: 0 > Trying to mount root from ufs:/dev/mmcsd0s1 > > Alexander Motin wrote: >> Krassimir Slavchev wrote: >>> Alexander Motin wrote: >>>> Krassimir Slavchev wrote: >>>>> Oops, sorry this output was without SD card inserted! >>>>> I've changed the file. >>>> That's some different debugging. I have meant that one, which happens >>>> when boot_verbose="YES" added to loader.conf, or respective Fx button >>>> pressed during boot on PC. >>> Yes this is with kernel VERBOSE_SYSINIT option because I cannot set >>> boot_verbose from arm boot loader. >>> Verbose messages from which modules you want to see? I will set >>> bootverbose manually. >> mmc. And while being there, apply this one please. -- Alexander Motin From krassi at bulinfo.net Wed Jan 21 08:40:47 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Wed Jan 21 08:40:55 2009 Subject: Mount root from SD card? In-Reply-To: <20090121.084023.188100520.imp@bsdimp.com> References: <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> <20090121.084023.188100520.imp@bsdimp.com> Message-ID: <4977500A.7060902@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: > In message: <4977236E.2020409@bulinfo.net> > Krassimir Slavchev writes: > Boot with verbose messages is here: > > http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose > >> This looks very similar to the data corruption I saw when I had >> enabled multiblock read. To track this down, we're going to have to >> print the actual data returned for each sector... > >> Warner Here is a dump of data right after the byte swapping in at91_mci_read_done(): http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump and here is the first 1M of the SD card: http://mnemonic.bulinfo.net/~krassi/ARM/sd.bin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJd1AJxJBWvpalMpkRAqWtAKC3EUilDCO0xao7N5xalFL2D9iMSACfVlwa 4UK5WYmLGlb22iHjFiDgFh0= =zi6J -----END PGP SIGNATURE----- From imp at bsdimp.com Wed Jan 21 08:48:30 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Jan 21 08:48:37 2009 Subject: Mount root from SD card? In-Reply-To: <497748D9.2040607@FreeBSD.org> References: <49772EF1.1060207@FreeBSD.org> <4977309F.2020402@bulinfo.net> <497748D9.2040607@FreeBSD.org> Message-ID: <20090121.094616.639845519.imp@bsdimp.com> In message: <497748D9.2040607@FreeBSD.org> Alexander Motin writes: : Krassimir Slavchev wrote: : > ... : > CMD: 7 ARG 0 len 0 : > RES: 0 : : Before this point mmc_rescan_cards() have successfully selected all the : cards. Then at this point : mmcbr_set_bus_mode(dev, pushpull); : : mmcbr_update_ios(dev); : were called. And after that same request inside mmc_calculate_clock() : has failed. That's strange. : : > timing 1, rate 30000000, hsrate 50000000 : > CMD: 7 ARG 10000 len 0 : > RES: 2 : : Open drain bus mode control is not implemented by sdhci driver, so I : haven't looked at it close. Quick look around shows that push-pull mode : was set there even without that last call. May be I am wrong, but first : line looks useless. mmcbr_update_ios(dev) writes to the controller bus : control registers, may be it affects something, or bus require some time : to settle after it? Without open drain bus mode, I don't think that you can properly do MMC cards. At least I couldn't with the AT91 when I was developing it. The open drain mode is what allows us to select the one mmc card we're talking to. : > CMD: 6 ARG 80fffff0 len 64 : > RES: 0 : > CMD: 7 ARG 0 len 0 : > RES: 0 : > mmc0: setting transfer rate to 30.000MHz : > mmcsd0: 1983MB at mmc0 30MHz/1bit : : Bus frequency changed here. SD specification allows frequencies up to : 25MHz without high speed timings used, but cards like this one ofter : declare a bit higher frequencies in legacy mode. May be we should just : to try to limit it to some safe value? You may just try to set : max_dtr = 5000000; : in mmc_calculate_clock(), before "if (bootverbose) {". The AT91 stuff works well in high speed mode, but the internal clocks of the AT91 may limit it to a number less than 50MHz. The 30MHz limit actually should be at91_master_clock / 2, so that's a bit of a bug in the driver (which I've fixed in my tree). I've made 30MHz work on the prior version of the code, so there's not a hardware limitation. BTW, at91_master_clock is 60,000,000 by default, so we can't go higher than 30MHz on those boards. Warner : > CMD: 7 ARG 10000 len 0 : > RES: 2 : > mmc0: setting bus width to 1 bits : > CMD: 37 ARG 10000 len 0 : > RES: 0 : > CMD: 6 ARG 0 len 0 : > RES: 0 : > CMD: 11 ARG 0 len 512 : > RES: 0 : > CMD: 11 ARG 0 len 512 : > RES: 0 : > CMD: 11 ARG 200 len 512 : > RES: 0 : > Trying to mount root from ufs:/dev/mmcsd0s1 : > : > Alexander Motin wrote: : >> Krassimir Slavchev wrote: : >>> Alexander Motin wrote: : >>>> Krassimir Slavchev wrote: : >>>>> Oops, sorry this output was without SD card inserted! : >>>>> I've changed the file. : >>>> That's some different debugging. I have meant that one, which happens : >>>> when boot_verbose="YES" added to loader.conf, or respective Fx button : >>>> pressed during boot on PC. : >>> Yes this is with kernel VERBOSE_SYSINIT option because I cannot set : >>> boot_verbose from arm boot loader. : >>> Verbose messages from which modules you want to see? I will set : >>> bootverbose manually. : >> mmc. And while being there, apply this one please. : : -- : Alexander Motin : : From imp at bsdimp.com Wed Jan 21 09:06:34 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Jan 21 09:06:41 2009 Subject: Mount root from SD card? In-Reply-To: <4977500A.7060902@bulinfo.net> References: <4977236E.2020409@bulinfo.net> <20090121.084023.188100520.imp@bsdimp.com> <4977500A.7060902@bulinfo.net> Message-ID: <20090121.100533.-1955669401.imp@bsdimp.com> In message: <4977500A.7060902@bulinfo.net> Krassimir Slavchev writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : M. Warner Losh wrote: : > In message: <4977236E.2020409@bulinfo.net> : > Krassimir Slavchev writes: : > Boot with verbose messages is here: : > : > http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose : > : >> This looks very similar to the data corruption I saw when I had : >> enabled multiblock read. To track this down, we're going to have to : >> print the actual data returned for each sector... : > : >> Warner : : : Here is a dump of data right after the byte swapping in : at91_mci_read_done(): : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump : : and here is the first 1M of the SD card: : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.bin Looks like we're getting some data corruption: CMD: 11 ARG 0 len 512 ff ff ff ff fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 ... and then: CMD: 11 ARG 0 len 512 00 00 55 aa fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 ... So it looks like the first 4 bytes are corrupted on the read. If you look closely at the data on the device, you'll see that 'fc 31 c0 8e' are the first 4 bytes of the reads are the 'left over' data from prior data streams. This didn't used to be the case in the prior code before the recent changes. The only way we're going to find the bad change is to do a binary search on the svn changes to find out where we go off the rails. This problem seems familiar to me, but I can't quite put my finger on what the root-cause was last time I had it. Warner From imp at bsdimp.com Wed Jan 21 09:15:17 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Jan 21 09:15:41 2009 Subject: Mount root from SD card? In-Reply-To: <20090121.100533.-1955669401.imp@bsdimp.com> References: <20090121.084023.188100520.imp@bsdimp.com> <4977500A.7060902@bulinfo.net> <20090121.100533.-1955669401.imp@bsdimp.com> Message-ID: <20090121.101459.2022307528.imp@bsdimp.com> In message: <20090121.100533.-1955669401.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <4977500A.7060902@bulinfo.net> : Krassimir Slavchev writes: : : -----BEGIN PGP SIGNED MESSAGE----- : : Hash: SHA1 : : : : M. Warner Losh wrote: : : > In message: <4977236E.2020409@bulinfo.net> : : > Krassimir Slavchev writes: : : > Boot with verbose messages is here: : : > : : > http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose : : > : : >> This looks very similar to the data corruption I saw when I had : : >> enabled multiblock read. To track this down, we're going to have to : : >> print the actual data returned for each sector... : : > : : >> Warner : : : : : : Here is a dump of data right after the byte swapping in : : at91_mci_read_done(): : : : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump : : : : and here is the first 1M of the SD card: : : : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.bin : : Looks like we're getting some data corruption: : : CMD: 11 ARG 0 len 512 : : ff ff ff ff fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c : 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab : fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 : 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 : ... : : and then: : : CMD: 11 ARG 0 len 512 : : 00 00 55 aa fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c : 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab : fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 : 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 : ... : : So it looks like the first 4 bytes are corrupted on the read. If you : look closely at the data on the device, you'll see that 'fc 31 c0 8e' : are the first 4 bytes of the reads are the 'left over' data from prior : data streams. This didn't used to be the case in the prior code : before the recent changes. The only way we're going to find the bad : change is to do a binary search on the svn changes to find out where : we go off the rails. This problem seems familiar to me, but I can't : quite put my finger on what the root-cause was last time I had it. I should have said 'fc 31 c0 8e' are the first four bytes of the data on the device, and 'ff ff ff ff' and '00 00 55 aa' are the leftover data which is corrupting things. The latter is actually the last 4 bytes of the block, which indicates that our PMC usage has stopped too soon, or that we have left over PMC data from a previous "read" that didn't specify enough data to be transferred. I suspect that we're sending a command down and not expecting enough data. On other bridges we toss the data harmlessly. On at91, the data is still in the FIFO for the mci device, so we see it first on the next read. At least that's the theory that just popped into my head, and also the root-cause that I now recall from before when I saw similar problems... Of course, given the number of transfers that had a lot of 'ff' in them, maybe the PMC is trasnferring data that doesn't really exist yet... Warner From mav at FreeBSD.org Wed Jan 21 10:19:35 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Jan 21 10:19:40 2009 Subject: Mount root from SD card? In-Reply-To: <20090121.101459.2022307528.imp@bsdimp.com> References: <20090121.084023.188100520.imp@bsdimp.com> <4977500A.7060902@bulinfo.net> <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> Message-ID: <49776734.8030805@FreeBSD.org> M. Warner Losh wrote: > In message: <20090121.100533.-1955669401.imp@bsdimp.com> > "M. Warner Losh" writes: > : In message: <4977500A.7060902@bulinfo.net> > : Krassimir Slavchev writes: > : : -----BEGIN PGP SIGNED MESSAGE----- > : : Hash: SHA1 > : : > : : M. Warner Losh wrote: > : : > In message: <4977236E.2020409@bulinfo.net> > : : > Krassimir Slavchev writes: > : : > Boot with verbose messages is here: > : : > > : : > http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose > : : > > : : >> This looks very similar to the data corruption I saw when I had > : : >> enabled multiblock read. To track this down, we're going to have to > : : >> print the actual data returned for each sector... > : : > > : : >> Warner > : : > : : > : : Here is a dump of data right after the byte swapping in > : : at91_mci_read_done(): > : : > : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump > : : > : : and here is the first 1M of the SD card: > : : > : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.bin > : > : Looks like we're getting some data corruption: > : > : CMD: 11 ARG 0 len 512 > : > : ff ff ff ff fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c > : 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab > : fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 > : 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 > : ... > : > : and then: > : > : CMD: 11 ARG 0 len 512 > : > : 00 00 55 aa fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c > : 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab > : fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 > : 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 > : ... > : > : So it looks like the first 4 bytes are corrupted on the read. If you > : look closely at the data on the device, you'll see that 'fc 31 c0 8e' > : are the first 4 bytes of the reads are the 'left over' data from prior > : data streams. This didn't used to be the case in the prior code > : before the recent changes. The only way we're going to find the bad > : change is to do a binary search on the svn changes to find out where > : we go off the rails. This problem seems familiar to me, but I can't > : quite put my finger on what the root-cause was last time I had it. > > I should have said 'fc 31 c0 8e' are the first four bytes of the data > on the device, and 'ff ff ff ff' and '00 00 55 aa' are the leftover > data which is corrupting things. The latter is actually the last 4 > bytes of the block, which indicates that our PMC usage has stopped too > soon, or that we have left over PMC data from a previous "read" that > didn't specify enough data to be transferred. I suspect that we're > sending a command down and not expecting enough data. On other > bridges we toss the data harmlessly. On at91, the data is still in > the FIFO for the mci device, so we see it first on the next read. At > least that's the theory that just popped into my head, and also the > root-cause that I now recall from before when I saw similar > problems... > > Of course, given the number of transfers that had a lot of 'ff' in > them, maybe the PMC is trasnferring data that doesn't really exist > yet... > > Warner This part looks quire strange for plain FIFO explanation. Several consequential commands give different results: CMD: 37 ARG 10000 len 0 RES: 0 CMD: d ARG 0 len 64 ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... RES: 2 CMD: 37 ARG 10000 len 0 RES: 0 CMD: d ARG 0 len 64 ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... RES: 2 CMD: 37 ARG 10000 len 0 RES: 0 CMD: d ARG 0 len 64 ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... RES: 2 CMD: 37 ARG 10000 len 0 RES: 0 CMD: d ARG 0 len 64 ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... RES: 2 While working on sdhci driver for on ENE chip I have found that for short transfers (less then 1K) DMA engine returns set of zeroes instead of data. I haven't found better solution and just handling short transfers by PIO. Same problem exists for PIO also, but there it was masked by adding short delay before reading from port. -- Alexander Motin From imp at bsdimp.com Wed Jan 21 11:30:19 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Jan 21 11:30:26 2009 Subject: Mount root from SD card? In-Reply-To: <49776734.8030805@FreeBSD.org> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> Message-ID: <20090121.122842.-1582190967.imp@bsdimp.com> In message: <49776734.8030805@FreeBSD.org> Alexander Motin writes: : M. Warner Losh wrote: : > In message: <20090121.100533.-1955669401.imp@bsdimp.com> : > "M. Warner Losh" writes: : > : In message: <4977500A.7060902@bulinfo.net> : > : Krassimir Slavchev writes: : > : : -----BEGIN PGP SIGNED MESSAGE----- : > : : Hash: SHA1 : > : : : > : : M. Warner Losh wrote: : > : : > In message: <4977236E.2020409@bulinfo.net> : > : : > Krassimir Slavchev writes: : > : : > Boot with verbose messages is here: : > : : > : > : : > http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose : > : : > : > : : >> This looks very similar to the data corruption I saw when I had : > : : >> enabled multiblock read. To track this down, we're going to have to : > : : >> print the actual data returned for each sector... : > : : > : > : : >> Warner : > : : : > : : : > : : Here is a dump of data right after the byte swapping in : > : : at91_mci_read_done(): : > : : : > : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump : > : : : > : : and here is the first 1M of the SD card: : > : : : > : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.bin : > : : > : Looks like we're getting some data corruption: : > : : > : CMD: 11 ARG 0 len 512 : > : : > : ff ff ff ff fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c : > : 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab : > : fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 : > : 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 : > : ... : > : : > : and then: : > : : > : CMD: 11 ARG 0 len 512 : > : : > : 00 00 55 aa fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c : > : 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab : > : fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 : > : 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 : > : ... : > : : > : So it looks like the first 4 bytes are corrupted on the read. If you : > : look closely at the data on the device, you'll see that 'fc 31 c0 8e' : > : are the first 4 bytes of the reads are the 'left over' data from prior : > : data streams. This didn't used to be the case in the prior code : > : before the recent changes. The only way we're going to find the bad : > : change is to do a binary search on the svn changes to find out where : > : we go off the rails. This problem seems familiar to me, but I can't : > : quite put my finger on what the root-cause was last time I had it. : > : > I should have said 'fc 31 c0 8e' are the first four bytes of the data : > on the device, and 'ff ff ff ff' and '00 00 55 aa' are the leftover : > data which is corrupting things. The latter is actually the last 4 : > bytes of the block, which indicates that our PMC usage has stopped too : > soon, or that we have left over PMC data from a previous "read" that : > didn't specify enough data to be transferred. I suspect that we're : > sending a command down and not expecting enough data. On other : > bridges we toss the data harmlessly. On at91, the data is still in : > the FIFO for the mci device, so we see it first on the next read. At : > least that's the theory that just popped into my head, and also the : > root-cause that I now recall from before when I saw similar : > problems... : > : > Of course, given the number of transfers that had a lot of 'ff' in : > them, maybe the PMC is trasnferring data that doesn't really exist : > yet... : > : > Warner : : This part looks quire strange for plain FIFO explanation. Several : consequential commands give different results: : : CMD: 37 ARG 10000 len 0 : RES: 0 : CMD: d ARG 0 len 64 : : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : RES: 2 : CMD: 37 ARG 10000 len 0 : RES: 0 : CMD: d ARG 0 len 64 : : ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 : 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : RES: 2 : CMD: 37 ARG 10000 len 0 : RES: 0 : CMD: d ARG 0 len 64 : : ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : RES: 2 : CMD: 37 ARG 10000 len 0 : RES: 0 : CMD: d ARG 0 len 64 : : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : RES: 2 : : While working on sdhci driver for on ENE chip I have found that for : short transfers (less then 1K) DMA engine returns set of zeroes instead : of data. I haven't found better solution and just handling short : transfers by PIO. Same problem exists for PIO also, but there it was : masked by adding short delay before reading from port. I'll have to take a look at the code in more detail to make sure that we're doing the right thing. I noticed all the ff's, but didn't notice until now what they were shifted the same way that the data blocks were later. In this case, you'll see there's three of them. I believe that this is the first use of a CMD that generates data that isn't a full block of data... Warner From raj at semihalf.com Thu Jan 22 00:35:02 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Thu Jan 22 00:35:09 2009 Subject: Mount root from SD card? In-Reply-To: <20090121.084141.-1119405090.imp@bsdimp.com> References: <4977236E.2020409@bulinfo.net> <497726F5.5080000@bulinfo.net> <49772A2C.7090903@FreeBSD.org> <20090121.084141.-1119405090.imp@bsdimp.com> Message-ID: <49782CE0.8010607@semihalf.com> M. Warner Losh wrote: > In message: <49772A2C.7090903@FreeBSD.org> > Alexander Motin writes: > : Krassimir Slavchev wrote: > : > Oops, sorry this output was without SD card inserted! > : > I've changed the file. > : > : That's some different debugging. I have meant that one, which happens > : when boot_verbose="YES" added to loader.conf, or respective Fx button > : pressed during boot on PC. > > You can't do either of those on the ARM platform. Just for the record: Marvell ARM platforms can boot with regular loader(8) environment; in this case using runtime variables, boot flags etc. works. Rafal From ticso at cicely7.cicely.de Thu Jan 22 03:29:05 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Thu Jan 22 03:29:12 2009 Subject: Mount root from SD card? In-Reply-To: <20090121.122842.-1582190967.imp@bsdimp.com> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> Message-ID: <20090122105650.GB50103@cicely7.cicely.de> On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: > In message: <49776734.8030805@FreeBSD.org> > Alexander Motin writes: > : > : This part looks quire strange for plain FIFO explanation. Several > : consequential commands give different results: > : > : CMD: 37 ARG 10000 len 0 > : RES: 0 > : CMD: d ARG 0 len 64 > : > : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... > : RES: 2 > : CMD: 37 ARG 10000 len 0 > : RES: 0 > : CMD: d ARG 0 len 64 > : > : ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 > : 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... > : RES: 2 > : CMD: 37 ARG 10000 len 0 > : RES: 0 > : CMD: d ARG 0 len 64 > : > : ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... > : RES: 2 > : CMD: 37 ARG 10000 len 0 > : RES: 0 > : CMD: d ARG 0 len 64 > : > : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... > : RES: 2 > : > : While working on sdhci driver for on ENE chip I have found that for > : short transfers (less then 1K) DMA engine returns set of zeroes instead > : of data. I haven't found better solution and just handling short > : transfers by PIO. Same problem exists for PIO also, but there it was > : masked by adding short delay before reading from port. > > I'll have to take a look at the code in more detail to make sure that > we're doing the right thing. I noticed all the ff's, but didn't > notice until now what they were shifted the same way that the data > blocks were later. In this case, you'll see there's three of them. > > I believe that this is the first use of a CMD that generates data that > isn't a full block of data... Havn't read everything, so maybe I writing nonsense in respect to this problem. The multiblock read trouble is a problem in the MMC design. The first read always works fine, but you need to stop the transfer and an exact time, otherwise it starts reading the next block. The first bytes of the next block then stucks in the DMA fifo and the next read then starts with the stuck uint32. If you see broken reads like this then I would assume the previous command was problematic. The official workaround to get multiblock reading is to reset the MMC and clean the fifo after each multiblock command, but I would assume it is enough to just read the data register a few time before setting up the DMA for the new request. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From mav at FreeBSD.org Thu Jan 22 05:22:35 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Jan 22 05:22:42 2009 Subject: Mount root from SD card? In-Reply-To: <20090122105650.GB50103@cicely7.cicely.de> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> Message-ID: <49787314.3070004@FreeBSD.org> Bernd Walter wrote: > On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: >> In message: <49776734.8030805@FreeBSD.org> >> Alexander Motin writes: >> : >> : This part looks quire strange for plain FIFO explanation. Several >> : consequential commands give different results: >> : >> : CMD: 37 ARG 10000 len 0 >> : RES: 0 >> : CMD: d ARG 0 len 64 >> : >> : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... >> : RES: 2 >> : CMD: 37 ARG 10000 len 0 >> : RES: 0 >> : CMD: d ARG 0 len 64 >> : >> : ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 >> : 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... >> : RES: 2 >> : CMD: 37 ARG 10000 len 0 >> : RES: 0 >> : CMD: d ARG 0 len 64 >> : >> : ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... >> : RES: 2 >> : CMD: 37 ARG 10000 len 0 >> : RES: 0 >> : CMD: d ARG 0 len 64 >> : >> : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... >> : RES: 2 >> : >> : While working on sdhci driver for on ENE chip I have found that for >> : short transfers (less then 1K) DMA engine returns set of zeroes instead >> : of data. I haven't found better solution and just handling short >> : transfers by PIO. Same problem exists for PIO also, but there it was >> : masked by adding short delay before reading from port. >> >> I'll have to take a look at the code in more detail to make sure that >> we're doing the right thing. I noticed all the ff's, but didn't >> notice until now what they were shifted the same way that the data >> blocks were later. In this case, you'll see there's three of them. >> >> I believe that this is the first use of a CMD that generates data that >> isn't a full block of data... > > Havn't read everything, so maybe I writing nonsense in respect to > this problem. > The multiblock read trouble is a problem in the MMC design. > The first read always works fine, but you need to stop the transfer > and an exact time, otherwise it starts reading the next block. > The first bytes of the next block then stucks in the DMA fifo and > the next read then starts with the stuck uint32. > If you see broken reads like this then I would assume the previous > command was problematic. > The official workaround to get multiblock reading is to reset the MMC > and clean the fifo after each multiblock command, but I would assume > it is enough to just read the data register a few time before setting > up the DMA for the new request. Haven't look deep at that arm controller operation, but standard SD host has special counter register which terminates DMA transfer after specified amount of blocks. sdhci driver even uses it's Auth-CMD12 feature, where controller even sends STOP command to the card by itself. -- Alexander Motin From ticso at cicely7.cicely.de Thu Jan 22 06:20:24 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Thu Jan 22 06:20:31 2009 Subject: Mount root from SD card? In-Reply-To: <49787314.3070004@FreeBSD.org> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> Message-ID: <20090122142015.GC50103@cicely7.cicely.de> On Thu, Jan 22, 2009 at 03:22:28PM +0200, Alexander Motin wrote: > Bernd Walter wrote: > >On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: > >Havn't read everything, so maybe I writing nonsense in respect to > >this problem. > >The multiblock read trouble is a problem in the MMC design. > >The first read always works fine, but you need to stop the transfer > >and an exact time, otherwise it starts reading the next block. > >The first bytes of the next block then stucks in the DMA fifo and > >the next read then starts with the stuck uint32. > >If you see broken reads like this then I would assume the previous > >command was problematic. > >The official workaround to get multiblock reading is to reset the MMC > >and clean the fifo after each multiblock command, but I would assume > >it is enough to just read the data register a few time before setting > >up the DMA for the new request. > > Haven't look deep at that arm controller operation, but standard SD host > has special counter register which terminates DMA transfer after > specified amount of blocks. sdhci driver even uses it's Auth-CMD12 > feature, where controller even sends STOP command to the card by itself. > Yes - and this is broken in the Atmel design. This is not the only nasty bug that Atmel has left int he chip. You need to issue the STOP command at the absolut right timing, which is more or less impossible. The design puts every 32bit word in a receive register, which has a small fifo. You can setup a DMA enginge to pull the words from the register into RAM. Now what happens is that if you issue the STOP too late it starts reading the next block and then stops - the card can stop at every location, so there is no problem about this, but now you have the first words in the receive fifo. The DMA doesn't work anymore, because it was setup with a limited number of words to pull, so the additional words are kept in the register. Once you start reading the next block and setup the DMA it pulls the stuck words first. It that case it looks as if the timing is one word too late therefor you get 4 additonal bytes after each transaction. It shouldn't be a problem to read the receive register without data in it, so 4 or 5 dummy reads befor DMA setup should be enough. IIRC the fifo can only hold up to 3 words. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From krassi at bulinfo.net Thu Jan 22 06:46:42 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Thu Jan 22 06:46:51 2009 Subject: Mount root from SD card? In-Reply-To: <20090122142015.GC50103@cicely7.cicely.de> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> Message-ID: <497886C9.3020907@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have added a loop to read (256 times) the receive register (MCI_RDR) right before DMA setup for reading. Here is the result: http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump2 Best Regards Bernd Walter wrote: > On Thu, Jan 22, 2009 at 03:22:28PM +0200, Alexander Motin wrote: >> Bernd Walter wrote: >>> On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: >>> Havn't read everything, so maybe I writing nonsense in respect to >>> this problem. >>> The multiblock read trouble is a problem in the MMC design. >>> The first read always works fine, but you need to stop the transfer >>> and an exact time, otherwise it starts reading the next block. >>> The first bytes of the next block then stucks in the DMA fifo and >>> the next read then starts with the stuck uint32. >>> If you see broken reads like this then I would assume the previous >>> command was problematic. >>> The official workaround to get multiblock reading is to reset the MMC >>> and clean the fifo after each multiblock command, but I would assume >>> it is enough to just read the data register a few time before setting >>> up the DMA for the new request. >> Haven't look deep at that arm controller operation, but standard SD host >> has special counter register which terminates DMA transfer after >> specified amount of blocks. sdhci driver even uses it's Auth-CMD12 >> feature, where controller even sends STOP command to the card by itself. >> > > Yes - and this is broken in the Atmel design. > This is not the only nasty bug that Atmel has left int he chip. > You need to issue the STOP command at the absolut right timing, which > is more or less impossible. > The design puts every 32bit word in a receive register, which has a small > fifo. > You can setup a DMA enginge to pull the words from the register into RAM. > Now what happens is that if you issue the STOP too late it starts reading > the next block and then stops - the card can stop at every location, so > there is no problem about this, but now you have the first words in the > receive fifo. > The DMA doesn't work anymore, because it was setup with a limited number > of words to pull, so the additional words are kept in the register. > Once you start reading the next block and setup the DMA it pulls the > stuck words first. > It that case it looks as if the timing is one word too late therefor > you get 4 additonal bytes after each transaction. > It shouldn't be a problem to read the receive register without data in > it, so 4 or 5 dummy reads befor DMA setup should be enough. > IIRC the fifo can only hold up to 3 words. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJeIbJxJBWvpalMpkRAoyiAJ498TG0ZB+aIoz66ZMQ08C3RxQ8YQCfSoL0 AA+/Up5DcZCzX7b+sz0PXk0= =pLAx -----END PGP SIGNATURE----- From mav at FreeBSD.org Thu Jan 22 06:47:37 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Jan 22 06:47:43 2009 Subject: Mount root from SD card? In-Reply-To: <20090122142015.GC50103@cicely7.cicely.de> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> Message-ID: <49788702.9010808@FreeBSD.org> Bernd Walter wrote: > On Thu, Jan 22, 2009 at 03:22:28PM +0200, Alexander Motin wrote: >> Bernd Walter wrote: >>> On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: >>> Havn't read everything, so maybe I writing nonsense in respect to >>> this problem. >>> The multiblock read trouble is a problem in the MMC design. >>> The first read always works fine, but you need to stop the transfer >>> and an exact time, otherwise it starts reading the next block. >>> The first bytes of the next block then stucks in the DMA fifo and >>> the next read then starts with the stuck uint32. >>> If you see broken reads like this then I would assume the previous >>> command was problematic. >>> The official workaround to get multiblock reading is to reset the MMC >>> and clean the fifo after each multiblock command, but I would assume >>> it is enough to just read the data register a few time before setting >>> up the DMA for the new request. >> Haven't look deep at that arm controller operation, but standard SD host >> has special counter register which terminates DMA transfer after >> specified amount of blocks. sdhci driver even uses it's Auth-CMD12 >> feature, where controller even sends STOP command to the card by itself. >> > > Yes - and this is broken in the Atmel design. > This is not the only nasty bug that Atmel has left int he chip. > You need to issue the STOP command at the absolut right timing, which > is more or less impossible. > The design puts every 32bit word in a receive register, which has a small > fifo. > You can setup a DMA enginge to pull the words from the register into RAM. > Now what happens is that if you issue the STOP too late it starts reading > the next block and then stops - the card can stop at every location, so > there is no problem about this, but now you have the first words in the > receive fifo. > The DMA doesn't work anymore, because it was setup with a limited number > of words to pull, so the additional words are kept in the register. > Once you start reading the next block and setup the DMA it pulls the > stuck words first. > It that case it looks as if the timing is one word too late therefor > you get 4 additonal bytes after each transaction. > It shouldn't be a problem to read the receive register without data in > it, so 4 or 5 dummy reads befor DMA setup should be enough. > IIRC the fifo can only hold up to 3 words. Looks realistic. Just needed somebody with hardware to investigate it. But even if current problem seems to be alike, the reasons are probably different. At this time, mmc/mmcsd layers are strictly instructed to not issue multi block operations to the at91 controller. There is something different pollutes the buffer. But may be cleaning that FIFO before starting transfer could become universal solution. -- Alexander Motin From ticso at cicely7.cicely.de Thu Jan 22 07:13:47 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Thu Jan 22 07:13:53 2009 Subject: Mount root from SD card? In-Reply-To: <49788702.9010808@FreeBSD.org> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@FreeBSD.org> Message-ID: <20090122151340.GE50103@cicely7.cicely.de> On Thu, Jan 22, 2009 at 04:47:30PM +0200, Alexander Motin wrote: > Bernd Walter wrote: > >Yes - and this is broken in the Atmel design. > >This is not the only nasty bug that Atmel has left int he chip. > >You need to issue the STOP command at the absolut right timing, which > >is more or less impossible. > >The design puts every 32bit word in a receive register, which has a small > >fifo. > >You can setup a DMA enginge to pull the words from the register into RAM. > >Now what happens is that if you issue the STOP too late it starts reading > >the next block and then stops - the card can stop at every location, so > >there is no problem about this, but now you have the first words in the > >receive fifo. > >The DMA doesn't work anymore, because it was setup with a limited number > >of words to pull, so the additional words are kept in the register. > >Once you start reading the next block and setup the DMA it pulls the > >stuck words first. > >It that case it looks as if the timing is one word too late therefor > >you get 4 additonal bytes after each transaction. > >It shouldn't be a problem to read the receive register without data in > >it, so 4 or 5 dummy reads befor DMA setup should be enough. > >IIRC the fifo can only hold up to 3 words. > > Looks realistic. Just needed somebody with hardware to investigate it. I unfortunately don't have the time right now. > But even if current problem seems to be alike, the reasons are probably > different. At this time, mmc/mmcsd layers are strictly instructed to not > issue multi block operations to the at91 controller. There is something > different pollutes the buffer. That's the point why I was not sure if it applies here. Is there anything else issued which needs a STOP? I'm really a bit out of SD card command handling... > But may be cleaning that FIFO before starting transfer could become > universal solution. Probably - especially because multiblock operations are a massive speed factor, but it would still be good to know why it happens here. With multiblock writing we don't have this problem, because we have to supply the data and there is no reson to supply more than we need to send. The reason why we don't allow multiblock writes with this controller is just because we need a temporary buffer to reorder the bytes, which is fixed allocated to one block - the MCI in the RM9200 uses the wrong byte order - sigh... Would be good to use a larger buffer some day to speed up writing. Especially with writing multiblock would be a major enhancement. As another point: Is it possible to support SHDC with mci some day, or is there a special hardware requirement for SDHC? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From ticso at cicely7.cicely.de Thu Jan 22 07:23:09 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Thu Jan 22 07:23:16 2009 Subject: Mount root from SD card? In-Reply-To: <497886C9.3020907@bulinfo.net> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> <497886C9.3020907@bulinfo.net> Message-ID: <20090122152250.GH50103@cicely7.cicely.de> On Thu, Jan 22, 2009 at 04:46:33PM +0200, Krassimir Slavchev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I have added a loop to read (256 times) the receive register (MCI_RDR) > right before DMA setup for reading. Here is the result: > > http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump2 Seems there is a good reason, why Atmel does a MCI reset in their workaround :( > Best Regards > > Bernd Walter wrote: > > On Thu, Jan 22, 2009 at 03:22:28PM +0200, Alexander Motin wrote: > >> Bernd Walter wrote: > >>> On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: > >>> Havn't read everything, so maybe I writing nonsense in respect to > >>> this problem. > >>> The multiblock read trouble is a problem in the MMC design. > >>> The first read always works fine, but you need to stop the transfer > >>> and an exact time, otherwise it starts reading the next block. > >>> The first bytes of the next block then stucks in the DMA fifo and > >>> the next read then starts with the stuck uint32. > >>> If you see broken reads like this then I would assume the previous > >>> command was problematic. > >>> The official workaround to get multiblock reading is to reset the MMC > >>> and clean the fifo after each multiblock command, but I would assume > >>> it is enough to just read the data register a few time before setting > >>> up the DMA for the new request. > >> Haven't look deep at that arm controller operation, but standard SD host > >> has special counter register which terminates DMA transfer after > >> specified amount of blocks. sdhci driver even uses it's Auth-CMD12 > >> feature, where controller even sends STOP command to the card by itself. > >> > > > > Yes - and this is broken in the Atmel design. > > This is not the only nasty bug that Atmel has left int he chip. > > You need to issue the STOP command at the absolut right timing, which > > is more or less impossible. > > The design puts every 32bit word in a receive register, which has a small > > fifo. > > You can setup a DMA enginge to pull the words from the register into RAM. > > Now what happens is that if you issue the STOP too late it starts reading > > the next block and then stops - the card can stop at every location, so > > there is no problem about this, but now you have the first words in the > > receive fifo. > > The DMA doesn't work anymore, because it was setup with a limited number > > of words to pull, so the additional words are kept in the register. > > Once you start reading the next block and setup the DMA it pulls the > > stuck words first. > > It that case it looks as if the timing is one word too late therefor > > you get 4 additonal bytes after each transaction. > > It shouldn't be a problem to read the receive register without data in > > it, so 4 or 5 dummy reads befor DMA setup should be enough. > > IIRC the fifo can only hold up to 3 words. > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (FreeBSD) > > iD8DBQFJeIbJxJBWvpalMpkRAoyiAJ498TG0ZB+aIoz66ZMQ08C3RxQ8YQCfSoL0 > AA+/Up5DcZCzX7b+sz0PXk0= > =pLAx > -----END PGP SIGNATURE----- -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From krassi at bulinfo.net Thu Jan 22 07:55:40 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Thu Jan 22 07:55:46 2009 Subject: Mount root from SD card?(solved!) In-Reply-To: <20090122151340.GE50103@cicely7.cicely.de> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de> Message-ID: <497896F3.9030908@bulinfo.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090122/9e15968b/signature.pgp From imp at bsdimp.com Thu Jan 22 08:07:08 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Jan 22 08:07:16 2009 Subject: Mount root from SD card? In-Reply-To: <49787314.3070004@FreeBSD.org> References: <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> Message-ID: <20090122.090540.-839781195.imp@bsdimp.com> In message: <49787314.3070004@FreeBSD.org> Alexander Motin writes: : Bernd Walter wrote: : > On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: : >> In message: <49776734.8030805@FreeBSD.org> : >> Alexander Motin writes: : >> : : >> : This part looks quire strange for plain FIFO explanation. Several : >> : consequential commands give different results: : >> : : >> : CMD: 37 ARG 10000 len 0 : >> : RES: 0 : >> : CMD: d ARG 0 len 64 : >> : : >> : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : >> : RES: 2 : >> : CMD: 37 ARG 10000 len 0 : >> : RES: 0 : >> : CMD: d ARG 0 len 64 : >> : : >> : ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 : >> : 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : >> : RES: 2 : >> : CMD: 37 ARG 10000 len 0 : >> : RES: 0 : >> : CMD: d ARG 0 len 64 : >> : : >> : ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : >> : RES: 2 : >> : CMD: 37 ARG 10000 len 0 : >> : RES: 0 : >> : CMD: d ARG 0 len 64 : >> : : >> : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : >> : RES: 2 : >> : : >> : While working on sdhci driver for on ENE chip I have found that for : >> : short transfers (less then 1K) DMA engine returns set of zeroes instead : >> : of data. I haven't found better solution and just handling short : >> : transfers by PIO. Same problem exists for PIO also, but there it was : >> : masked by adding short delay before reading from port. : >> : >> I'll have to take a look at the code in more detail to make sure that : >> we're doing the right thing. I noticed all the ff's, but didn't : >> notice until now what they were shifted the same way that the data : >> blocks were later. In this case, you'll see there's three of them. : >> : >> I believe that this is the first use of a CMD that generates data that : >> isn't a full block of data... : > : > Havn't read everything, so maybe I writing nonsense in respect to : > this problem. : > The multiblock read trouble is a problem in the MMC design. : > The first read always works fine, but you need to stop the transfer : > and an exact time, otherwise it starts reading the next block. : > The first bytes of the next block then stucks in the DMA fifo and : > the next read then starts with the stuck uint32. : > If you see broken reads like this then I would assume the previous : > command was problematic. : > The official workaround to get multiblock reading is to reset the MMC : > and clean the fifo after each multiblock command, but I would assume : > it is enough to just read the data register a few time before setting : > up the DMA for the new request. : : Haven't look deep at that arm controller operation, but standard SD host : has special counter register which terminates DMA transfer after : specified amount of blocks. sdhci driver even uses it's Auth-CMD12 : feature, where controller even sends STOP command to the card by itself. The standard host adapter spec has this. The Atmel part doesn't. Warner From krassi at bulinfo.net Thu Jan 22 08:12:17 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Thu Jan 22 08:12:23 2009 Subject: Mount root from SD card?(solved!) In-Reply-To: <497896F3.9030908@bulinfo.net> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de> <497896F3.9030908@bulinfo.net> Message-ID: <49789ADE.4020107@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 And SD is corrupted! ... mmcsd0: 1983MB at mmc0 30MHz/1bit GEOM: mmcsd0s1: geometry does not match label (255h,63s != 64h,63s). GEOM: mmcsd0s2: geometry does not match label (255h,63s != 64h,63s). Trying to mount root from ufs:/dev/mmcsd0s1 warning: no time-of-day clock registered, system time will not be set accurately Loading configuration files. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/mmcsd0s2 as swap device uhub0: device problem (IOERROR), disabling port 2 Starting file system checks: /dev/mmcsd0s1: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mmcsd0s1: clean, 740863 free (3079 frags, 92223 blocks, 0.3% fragmentation) try does not match label (255h,63s != 64h,63s). Setting hostuuid: 5d40cced-02e7-11dc-b687-00ff01000043. Setting hostid: 0xf129ad60. Mounting local file systems:. panic: ufs_dirbad: /: bad dir ino 47116 at offset 0: mangled entry KDB: enter: panic [thread pid 80 tid 100044 ] Stopped at kdb_enter+0x44: ldrb r15, [r15, r15, ror r15]! db> Krassimir Slavchev wrote: > Hi, > > We have to send the command before enabling the PDC for reading. I do > not know why in the datasheet is opposite! > > See the attached patch. > > Thanks to All! > > Best Regards > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJeJrexJBWvpalMpkRAoCqAJ962bjsgQuUmDuuGQUH/gVjtOAelACbBDNU XczYSgeGxfA58BB5p4EsUIw= =NPrA -----END PGP SIGNATURE----- From imp at bsdimp.com Thu Jan 22 08:12:41 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Jan 22 08:12:53 2009 Subject: Mount root from SD card? In-Reply-To: <49788702.9010808@FreeBSD.org> References: <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@FreeBSD.org> Message-ID: <20090122.090957.803629112.imp@bsdimp.com> In message: <49788702.9010808@FreeBSD.org> Alexander Motin writes: : Bernd Walter wrote: : > On Thu, Jan 22, 2009 at 03:22:28PM +0200, Alexander Motin wrote: : >> Bernd Walter wrote: : >>> On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: : >>> Havn't read everything, so maybe I writing nonsense in respect to : >>> this problem. : >>> The multiblock read trouble is a problem in the MMC design. : >>> The first read always works fine, but you need to stop the transfer : >>> and an exact time, otherwise it starts reading the next block. : >>> The first bytes of the next block then stucks in the DMA fifo and : >>> the next read then starts with the stuck uint32. : >>> If you see broken reads like this then I would assume the previous : >>> command was problematic. : >>> The official workaround to get multiblock reading is to reset the MMC : >>> and clean the fifo after each multiblock command, but I would assume : >>> it is enough to just read the data register a few time before setting : >>> up the DMA for the new request. : >> Haven't look deep at that arm controller operation, but standard SD host : >> has special counter register which terminates DMA transfer after : >> specified amount of blocks. sdhci driver even uses it's Auth-CMD12 : >> feature, where controller even sends STOP command to the card by itself. : >> : > : > Yes - and this is broken in the Atmel design. : > This is not the only nasty bug that Atmel has left int he chip. : > You need to issue the STOP command at the absolut right timing, which : > is more or less impossible. : > The design puts every 32bit word in a receive register, which has a small : > fifo. : > You can setup a DMA enginge to pull the words from the register into RAM. : > Now what happens is that if you issue the STOP too late it starts reading : > the next block and then stops - the card can stop at every location, so : > there is no problem about this, but now you have the first words in the : > receive fifo. : > The DMA doesn't work anymore, because it was setup with a limited number : > of words to pull, so the additional words are kept in the register. : > Once you start reading the next block and setup the DMA it pulls the : > stuck words first. : > It that case it looks as if the timing is one word too late therefor : > you get 4 additonal bytes after each transaction. : > It shouldn't be a problem to read the receive register without data in : > it, so 4 or 5 dummy reads befor DMA setup should be enough. : > IIRC the fifo can only hold up to 3 words. : : Looks realistic. Just needed somebody with hardware to investigate it. : : But even if current problem seems to be alike, the reasons are probably : different. At this time, mmc/mmcsd layers are strictly instructed to not : issue multi block operations to the at91 controller. There is something : different pollutes the buffer. True. But the mmc layer is also now issuing commands it didn't used to issue, with different timing than before. That's the root cause of the problem. Also, there's bugs in the timing switching code that I'm working through. It does some bogus things and makes some bogus assumptions (like that if a car CAN do a hight speed transfer it MUST do it, even if the transfer speed isn't > 25MHz). : But may be cleaning that FIFO before starting transfer could become : universal solution. That's a really ugly solution. And it can't really be done reliably on this chip. At least when I was messing with it before I couldn't get it to work completely... There were too many ugly things wrong with this chip to make it viable. Warner From imp at bsdimp.com Thu Jan 22 08:12:43 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Jan 22 08:12:54 2009 Subject: Mount root from SD card? In-Reply-To: <20090122151340.GE50103@cicely7.cicely.de> References: <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de> Message-ID: <20090122.091204.831807729.imp@bsdimp.com> In message: <20090122151340.GE50103@cicely7.cicely.de> Bernd Walter writes: : On Thu, Jan 22, 2009 at 04:47:30PM +0200, Alexander Motin wrote: : > Bernd Walter wrote: : > >Yes - and this is broken in the Atmel design. : > >This is not the only nasty bug that Atmel has left int he chip. : > >You need to issue the STOP command at the absolut right timing, which : > >is more or less impossible. : > >The design puts every 32bit word in a receive register, which has a small : > >fifo. : > >You can setup a DMA enginge to pull the words from the register into RAM. : > >Now what happens is that if you issue the STOP too late it starts reading : > >the next block and then stops - the card can stop at every location, so : > >there is no problem about this, but now you have the first words in the : > >receive fifo. : > >The DMA doesn't work anymore, because it was setup with a limited number : > >of words to pull, so the additional words are kept in the register. : > >Once you start reading the next block and setup the DMA it pulls the : > >stuck words first. : > >It that case it looks as if the timing is one word too late therefor : > >you get 4 additonal bytes after each transaction. : > >It shouldn't be a problem to read the receive register without data in : > >it, so 4 or 5 dummy reads befor DMA setup should be enough. : > >IIRC the fifo can only hold up to 3 words. : > : > Looks realistic. Just needed somebody with hardware to investigate it. : : I unfortunately don't have the time right now. : : > But even if current problem seems to be alike, the reasons are probably : > different. At this time, mmc/mmcsd layers are strictly instructed to not : > issue multi block operations to the at91 controller. There is something : > different pollutes the buffer. : : That's the point why I was not sure if it applies here. : Is there anything else issued which needs a STOP? : I'm really a bit out of SD card command handling... : : > But may be cleaning that FIFO before starting transfer could become : > universal solution. : : Probably - especially because multiblock operations are a massive : speed factor, but it would still be good to know why it happens here. : : With multiblock writing we don't have this problem, because we have : to supply the data and there is no reson to supply more than we need to : send. : The reason why we don't allow multiblock writes with this controller is : just because we need a temporary buffer to reorder the bytes, which is : fixed allocated to one block - the MCI in the RM9200 uses the wrong : byte order - sigh... : Would be good to use a larger buffer some day to speed up writing. : Especially with writing multiblock would be a major enhancement. Yes. We could have a larger buffer, but we still need the reset the fifo after each transfer hack. I tried to implement it long ago, but it failed to work reliably... : As another point: : Is it possible to support SHDC with mci some day, or is there a special : hardware requirement for SDHC? It should be, in theory, possible. sdio is a different matter due to timing issues, but SDHC should be possible... Warner From imp at bsdimp.com Thu Jan 22 08:30:03 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Jan 22 08:30:10 2009 Subject: Mount root from SD card?(solved!) In-Reply-To: <497896F3.9030908@bulinfo.net> References: <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de> <497896F3.9030908@bulinfo.net> Message-ID: <20090122.093007.1785588956.imp@bsdimp.com> In message: <497896F3.9030908@bulinfo.net> Krassimir Slavchev writes: : Index: at91_mci.c : =================================================================== : --- at91_mci.c (revision 187590) : +++ at91_mci.c (working copy) : @@ -199,7 +199,7 @@ : goto out; : } : sc->host.f_min = 375000; : - sc->host.f_max = at91_master_clock / 2; /* Typically 30MHz */ : + sc->host.f_max = AT91C_MASTER_CLOCK / 2; /* Typically 30MHz */ : sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; : if (sc->wire4) : sc->host.caps = MMC_CAP_4_BIT_DATA; This change is wrong. : @@ -399,8 +399,8 @@ : WR4(sc, MCI_ARGR, cmd->arg); : if (cmdr & MCI_CMDR_TRCMD_START) { : if (cmdr & MCI_CMDR_TRDIR) { : + WR4(sc, MCI_CMDR, cmdr); : WR4(sc, PDC_PTCR, PDC_PTCR_RXTEN); : - WR4(sc, MCI_CMDR, cmdr); This change is also wrong. It won't work. Also, why test the direction at all if we're just going to do the same thing in both legs of the branch? When I was developing the code, I originally had the 'send a command and then enable PDC' logic. It didn't work for the read case, so now we enable the reader and then send the command. We do this based on the logic that it is OK to have the PDC enabled when there's no data transfer going, but if we send the command, then take an interrupt before we can enable the PDC, we'd lose data. And that seemed to happen a lot. There's lots of races in programming this chip :( : } else { : WR4(sc, MCI_CMDR, cmdr); : WR4(sc, PDC_PTCR, PDC_PTCR_TXTEN); Warner From mav at FreeBSD.org Thu Jan 22 10:02:35 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Jan 22 10:02:42 2009 Subject: Mount root from SD card? In-Reply-To: <20090122151340.GE50103@cicely7.cicely.de> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de> Message-ID: <4978B4A6.8060408@FreeBSD.org> Bernd Walter wrote: > As another point: > Is it possible to support SHDC with mci some day, or is there a special > hardware requirement for SDHC? SDHC (SD High Capacity) has just a different data addressing scheme (in 512bytes blocks instead of bytes). There is no special hardware requirements, only minor initialization differences. With present mmc/mmcsd modules SDHC should work fine on any controller. -- Alexander Motin From ticso at cicely7.cicely.de Thu Jan 22 10:05:27 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Thu Jan 22 10:05:33 2009 Subject: Mount root from SD card? In-Reply-To: <4978B4A6.8060408@FreeBSD.org> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de> <4978B4A6.8060408@FreeBSD.org> Message-ID: <20090122180518.GK50103@cicely7.cicely.de> On Thu, Jan 22, 2009 at 08:02:14PM +0200, Alexander Motin wrote: > Bernd Walter wrote: > >As another point: > >Is it possible to support SHDC with mci some day, or is there a special > >hardware requirement for SDHC? > > SDHC (SD High Capacity) has just a different data addressing scheme (in > 512bytes blocks instead of bytes). There is no special hardware > requirements, only minor initialization differences. With present > mmc/mmcsd modules SDHC should work fine on any controller. Good news - thank you for clearification. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From imp at bsdimp.com Thu Jan 22 15:00:46 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Jan 22 15:00:52 2009 Subject: Mount root from SD card? In-Reply-To: <20090122180518.GK50103@cicely7.cicely.de> References: <20090122151340.GE50103@cicely7.cicely.de> <4978B4A6.8060408@FreeBSD.org> <20090122180518.GK50103@cicely7.cicely.de> Message-ID: <20090122.155741.-470325804.imp@bsdimp.com> In message: <20090122180518.GK50103@cicely7.cicely.de> Bernd Walter writes: : On Thu, Jan 22, 2009 at 08:02:14PM +0200, Alexander Motin wrote: : > Bernd Walter wrote: : > >As another point: : > >Is it possible to support SHDC with mci some day, or is there a special : > >hardware requirement for SDHC? : > : > SDHC (SD High Capacity) has just a different data addressing scheme (in : > 512bytes blocks instead of bytes). There is no special hardware : > requirements, only minor initialization differences. With present : > mmc/mmcsd modules SDHC should work fine on any controller. : : Good news - thank you for clearification. Now all we need to do is to enhance the boot blocks to be able to boot off the SDHC cards :) BTW, I found and fixed the bug (at least I think so). We were assuming that all transfers were 512 bytes long. The newly used 16 and 64 byte transfers broke that assumption, which is why things broke after Alexander's latest commits. There's still a small chance that there's something borked in the byte swapping code, but I kinda doubt it since I was able to mount root. svn commit r187603 is the fix. Warner From ticso at cicely7.cicely.de Thu Jan 22 15:06:55 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Thu Jan 22 15:07:02 2009 Subject: Mount root from SD card? In-Reply-To: <20090122.155741.-470325804.imp@bsdimp.com> References: <20090122151340.GE50103@cicely7.cicely.de> <4978B4A6.8060408@FreeBSD.org> <20090122180518.GK50103@cicely7.cicely.de> <20090122.155741.-470325804.imp@bsdimp.com> Message-ID: <20090122230647.GN50103@cicely7.cicely.de> On Thu, Jan 22, 2009 at 03:57:41PM -0700, M. Warner Losh wrote: > In message: <20090122180518.GK50103@cicely7.cicely.de> > Bernd Walter writes: > : On Thu, Jan 22, 2009 at 08:02:14PM +0200, Alexander Motin wrote: > : > Bernd Walter wrote: > : > >As another point: > : > >Is it possible to support SHDC with mci some day, or is there a special > : > >hardware requirement for SDHC? > : > > : > SDHC (SD High Capacity) has just a different data addressing scheme (in > : > 512bytes blocks instead of bytes). There is no special hardware > : > requirements, only minor initialization differences. With present > : > mmc/mmcsd modules SDHC should work fine on any controller. > : > : Good news - thank you for clearification. > > Now all we need to do is to enhance the boot blocks to be able to boot > off the SDHC cards :) Yes, but since you wrote code to store the kernel inside SPI-flash there is a useable workaround available ;-) Full loader support would be more interesting than SDHC in boot code anyway. > BTW, I found and fixed the bug (at least I think so). We were > assuming that all transfers were 512 bytes long. The newly used 16 > and 64 byte transfers broke that assumption, which is why things broke > after Alexander's latest commits. There's still a small chance that > there's something borked in the byte swapping code, but I kinda doubt > it since I was able to mount root. > > svn commit r187603 is the fix. Great! -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From imp at bsdimp.com Thu Jan 22 15:27:02 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Jan 22 15:27:08 2009 Subject: Mount root from SD card? In-Reply-To: <20090122230647.GN50103@cicely7.cicely.de> References: <20090122180518.GK50103@cicely7.cicely.de> <20090122.155741.-470325804.imp@bsdimp.com> <20090122230647.GN50103@cicely7.cicely.de> Message-ID: <20090122.162633.1849591410.imp@bsdimp.com> In message: <20090122230647.GN50103@cicely7.cicely.de> Bernd Walter writes: : On Thu, Jan 22, 2009 at 03:57:41PM -0700, M. Warner Losh wrote: : > In message: <20090122180518.GK50103@cicely7.cicely.de> : > Bernd Walter writes: : > : On Thu, Jan 22, 2009 at 08:02:14PM +0200, Alexander Motin wrote: : > : > Bernd Walter wrote: : > : > >As another point: : > : > >Is it possible to support SHDC with mci some day, or is there a special : > : > >hardware requirement for SDHC? : > : > : > : > SDHC (SD High Capacity) has just a different data addressing scheme (in : > : > 512bytes blocks instead of bytes). There is no special hardware : > : > requirements, only minor initialization differences. With present : > : > mmc/mmcsd modules SDHC should work fine on any controller. : > : : > : Good news - thank you for clearification. : > : > Now all we need to do is to enhance the boot blocks to be able to boot : > off the SDHC cards :) : : Yes, but since you wrote code to store the kernel inside SPI-flash : there is a useable workaround available ;-) : Full loader support would be more interesting than SDHC in boot code : anyway. Raj@ did some interesting work in this area for the marvel port... : > BTW, I found and fixed the bug (at least I think so). We were : > assuming that all transfers were 512 bytes long. The newly used 16 : > and 64 byte transfers broke that assumption, which is why things broke : > after Alexander's latest commits. There's still a small chance that : > there's something borked in the byte swapping code, but I kinda doubt : > it since I was able to mount root. : > : > svn commit r187603 is the fix. : : Great! Well, it doesn't work in 4-bit bus mode. Of course, I'm not sure it ever worked in 4-bit bus mode... Warner From ticso at cicely7.cicely.de Thu Jan 22 15:57:20 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Thu Jan 22 15:57:26 2009 Subject: Mount root from SD card? In-Reply-To: <20090122.162633.1849591410.imp@bsdimp.com> References: <20090122180518.GK50103@cicely7.cicely.de> <20090122.155741.-470325804.imp@bsdimp.com> <20090122230647.GN50103@cicely7.cicely.de> <20090122.162633.1849591410.imp@bsdimp.com> Message-ID: <20090122235712.GO50103@cicely7.cicely.de> On Thu, Jan 22, 2009 at 04:26:33PM -0700, M. Warner Losh wrote: > In message: <20090122230647.GN50103@cicely7.cicely.de> > Bernd Walter writes: > : On Thu, Jan 22, 2009 at 03:57:41PM -0700, M. Warner Losh wrote: > : > In message: <20090122180518.GK50103@cicely7.cicely.de> > : > Bernd Walter writes: > : > : On Thu, Jan 22, 2009 at 08:02:14PM +0200, Alexander Motin wrote: > : > : > Bernd Walter wrote: > : > : > >As another point: > : > : > >Is it possible to support SHDC with mci some day, or is there a special > : > : > >hardware requirement for SDHC? > : > : > > : > : > SDHC (SD High Capacity) has just a different data addressing scheme (in > : > : > 512bytes blocks instead of bytes). There is no special hardware > : > : > requirements, only minor initialization differences. With present > : > : > mmc/mmcsd modules SDHC should work fine on any controller. > : > : > : > : Good news - thank you for clearification. > : > > : > Now all we need to do is to enhance the boot blocks to be able to boot > : > off the SDHC cards :) > : > : Yes, but since you wrote code to store the kernel inside SPI-flash > : there is a useable workaround available ;-) > : Full loader support would be more interesting than SDHC in boot code > : anyway. > > Raj@ did some interesting work in this area for the marvel port... I already noticed his work with great pleasure. > : > BTW, I found and fixed the bug (at least I think so). We were > : > assuming that all transfers were 512 bytes long. The newly used 16 > : > and 64 byte transfers broke that assumption, which is why things broke > : > after Alexander's latest commits. There's still a small chance that > : > there's something borked in the byte swapping code, but I kinda doubt > : > it since I was able to mount root. > : > > : > svn commit r187603 is the fix. > : > : Great! > > Well, it doesn't work in 4-bit bus mode. Of course, I'm not sure it > ever worked in 4-bit bus mode... It never worked - I tried it a while back and had interesting results, but it wasn't stable, which I asumed to be my bad knowledge on how this should be implemented correctly. Thanks to mav@ we have other controllers working and can test the sdmmc part unrelated from mci. Nevertheless: multiblock is the real speed issue. My speed tests were very impressive, but because of mci problems data were corrupted of course. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From imp at bsdimp.com Thu Jan 22 16:15:03 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Jan 22 16:15:10 2009 Subject: Mount root from SD card? In-Reply-To: <20090122235712.GO50103@cicely7.cicely.de> References: <20090122230647.GN50103@cicely7.cicely.de> <20090122.162633.1849591410.imp@bsdimp.com> <20090122235712.GO50103@cicely7.cicely.de> Message-ID: <20090122.171304.-1528842637.imp@bsdimp.com> In message: <20090122235712.GO50103@cicely7.cicely.de> Bernd Walter writes: : On Thu, Jan 22, 2009 at 04:26:33PM -0700, M. Warner Losh wrote: : > In message: <20090122230647.GN50103@cicely7.cicely.de> : > Bernd Walter writes: : > : On Thu, Jan 22, 2009 at 03:57:41PM -0700, M. Warner Losh wrote: : > : > In message: <20090122180518.GK50103@cicely7.cicely.de> : > : > Bernd Walter writes: : > : > : On Thu, Jan 22, 2009 at 08:02:14PM +0200, Alexander Motin wrote: : > : > : > Bernd Walter wrote: : > : > : > >As another point: : > : > : > >Is it possible to support SHDC with mci some day, or is there a special : > : > : > >hardware requirement for SDHC? : > : > : > : > : > : > SDHC (SD High Capacity) has just a different data addressing scheme (in : > : > : > 512bytes blocks instead of bytes). There is no special hardware : > : > : > requirements, only minor initialization differences. With present : > : > : > mmc/mmcsd modules SDHC should work fine on any controller. : > : > : : > : > : Good news - thank you for clearification. : > : > : > : > Now all we need to do is to enhance the boot blocks to be able to boot : > : > off the SDHC cards :) : > : : > : Yes, but since you wrote code to store the kernel inside SPI-flash : > : there is a useable workaround available ;-) : > : Full loader support would be more interesting than SDHC in boot code : > : anyway. : > : > Raj@ did some interesting work in this area for the marvel port... : : I already noticed his work with great pleasure. : : > : > BTW, I found and fixed the bug (at least I think so). We were : > : > assuming that all transfers were 512 bytes long. The newly used 16 : > : > and 64 byte transfers broke that assumption, which is why things broke : > : > after Alexander's latest commits. There's still a small chance that : > : > there's something borked in the byte swapping code, but I kinda doubt : > : > it since I was able to mount root. : > : > : > : > svn commit r187603 is the fix. : > : : > : Great! : > : > Well, it doesn't work in 4-bit bus mode. Of course, I'm not sure it : > ever worked in 4-bit bus mode... : : It never worked - I tried it a while back and had interesting results, : but it wasn't stable, which I asumed to be my bad knowledge on how this : should be implemented correctly. : Thanks to mav@ we have other controllers working and can test the : sdmmc part unrelated from mci. : Nevertheless: multiblock is the real speed issue. : My speed tests were very impressive, but because of mci problems data : were corrupted of course. I'll see if I can find an hour or two to look into the proper reset of the mci fifos after use... I'd also like to get 4-bit working too... Right now I'm only getting ~900kB/s (890-919) and we can do much better, no? Warner From mav at FreeBSD.org Fri Jan 23 01:17:39 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Jan 23 01:17:46 2009 Subject: Mount root from SD card? Message-ID: <200901231117070000@1426712698> > Right now I'm only getting ~900kB/s (890-919) and we can do much > better, no? I have started from alike values with sdmmc driver, but with multiblock transfers and 4 bits bus I have reached top possible for my controller 15Mbytes/s. Multiblock transfers are very important to reduce number of interrupts. -- Alexander Motin From ticso at cicely7.cicely.de Fri Jan 23 02:31:06 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Fri Jan 23 02:31:13 2009 Subject: Mount root from SD card? In-Reply-To: <200901231117070000@1426712698> References: <200901231117070000@1426712698> Message-ID: <20090123103053.GR50103@cicely7.cicely.de> On Fri, Jan 23, 2009 at 11:17:06AM +0200, Alexander Motin wrote: > > Right now I'm only getting ~900kB/s (890-919) and we can do much > > better, no? > > I have started from alike values with sdmmc driver, but with multiblock transfers and 4 bits bus I have reached top possible for my controller 15Mbytes/s. Multiblock transfers are very important to reduce number of interrupts. Not only that - they are important for card internal optimization. Especially with writing a transfer can issue read-modify-write cycles on the large cell blocks and writing a 16k FS block in 32 card transactions is not very perfect. Especially many MLC cards have a large write transaction overhead. With reading it just means opening the cells for reading, but some card designs are slow with this as well. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From krassi at bulinfo.net Fri Jan 23 08:06:26 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Fri Jan 23 08:06:33 2009 Subject: Mount root from SD card? In-Reply-To: <20090122.093007.1785588956.imp@bsdimp.com> References: <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de> <497896F3.9030908@bulinfo.net> <20090122.093007.1785588956.imp@bsdimp.com> Message-ID: <4979EAFE.2030407@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: > In message: <497896F3.9030908@bulinfo.net> > Krassimir Slavchev writes: > : Index: at91_mci.c > : =================================================================== > : --- at91_mci.c (revision 187590) > : +++ at91_mci.c (working copy) > : @@ -199,7 +199,7 @@ > : goto out; > : } > : sc->host.f_min = 375000; > : - sc->host.f_max = at91_master_clock / 2; /* Typically 30MHz */ > : + sc->host.f_max = AT91C_MASTER_CLOCK / 2; /* Typically 30MHz */ > : sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; > : if (sc->wire4) > : sc->host.caps = MMC_CAP_4_BIT_DATA; > > This change is wrong. Ok. I did this because at91_master_clock was not defined here. > > : @@ -399,8 +399,8 @@ > : WR4(sc, MCI_ARGR, cmd->arg); > : if (cmdr & MCI_CMDR_TRCMD_START) { > : if (cmdr & MCI_CMDR_TRDIR) { > : + WR4(sc, MCI_CMDR, cmdr); > : WR4(sc, PDC_PTCR, PDC_PTCR_RXTEN); > : - WR4(sc, MCI_CMDR, cmdr); > > This change is also wrong. It won't work. Also, why test the > direction at all if we're just going to do the same thing in both legs > of the branch? When I was developing the code, I originally had the > 'send a command and then enable PDC' logic. It didn't work for the > read case, so now we enable the reader and then send the command. We > do this based on the logic that it is OK to have the PDC enabled when > there's no data transfer going, but if we send the command, then take > an interrupt before we can enable the PDC, we'd lose data. And that > seemed to happen a lot. Ok but I was able to read correctly first blocks ... Looking at linux's driver they do the same, first sending CMD and then enable PDC for reading. Thanks for latest fixes! Best regards > > There's lots of races in programming this chip :( > > : } else { > : WR4(sc, MCI_CMDR, cmdr); > : WR4(sc, PDC_PTCR, PDC_PTCR_TXTEN); > > > Warner > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJeer9xJBWvpalMpkRAoe5AJ44dnZY2pKZY/ZphexulLPFFXzN7wCfS+T/ pV+SezanCxT/pYtWE6dsKVM= =GPct -----END PGP SIGNATURE----- From krassi at bulinfo.net Fri Jan 23 08:15:59 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Fri Jan 23 08:16:16 2009 Subject: Mount root from SD card? In-Reply-To: <20090122.171304.-1528842637.imp@bsdimp.com> References: <20090122230647.GN50103@cicely7.cicely.de> <20090122.162633.1849591410.imp@bsdimp.com> <20090122235712.GO50103@cicely7.cicely.de> <20090122.171304.-1528842637.imp@bsdimp.com> Message-ID: <4979ED3A.2020008@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: > In message: <20090122235712.GO50103@cicely7.cicely.de> > Bernd Walter writes: > : On Thu, Jan 22, 2009 at 04:26:33PM -0700, M. Warner Losh wrote: > : > In message: <20090122230647.GN50103@cicely7.cicely.de> > : > Bernd Walter writes: > : > : On Thu, Jan 22, 2009 at 03:57:41PM -0700, M. Warner Losh wrote: > : > : > In message: <20090122180518.GK50103@cicely7.cicely.de> > : > : > Bernd Walter writes: > : > : > : On Thu, Jan 22, 2009 at 08:02:14PM +0200, Alexander Motin wrote: > : > : > : > Bernd Walter wrote: > : > : > : > >As another point: > : > : > : > >Is it possible to support SHDC with mci some day, or is there a special > : > : > : > >hardware requirement for SDHC? > : > : > : > > : > : > : > SDHC (SD High Capacity) has just a different data addressing scheme (in > : > : > : > 512bytes blocks instead of bytes). There is no special hardware > : > : > : > requirements, only minor initialization differences. With present > : > : > : > mmc/mmcsd modules SDHC should work fine on any controller. > : > : > : > : > : > : Good news - thank you for clearification. > : > : > > : > : > Now all we need to do is to enhance the boot blocks to be able to boot > : > : > off the SDHC cards :) > : > : > : > : Yes, but since you wrote code to store the kernel inside SPI-flash > : > : there is a useable workaround available ;-) > : > : Full loader support would be more interesting than SDHC in boot code > : > : anyway. > : > > : > Raj@ did some interesting work in this area for the marvel port... > : > : I already noticed his work with great pleasure. > : > : > : > BTW, I found and fixed the bug (at least I think so). We were > : > : > assuming that all transfers were 512 bytes long. The newly used 16 > : > : > and 64 byte transfers broke that assumption, which is why things broke > : > : > after Alexander's latest commits. There's still a small chance that > : > : > there's something borked in the byte swapping code, but I kinda doubt > : > : > it since I was able to mount root. > : > : > > : > : > svn commit r187603 is the fix. > : > : > : > : Great! > : > > : > Well, it doesn't work in 4-bit bus mode. Of course, I'm not sure it > : > ever worked in 4-bit bus mode... > : > : It never worked - I tried it a while back and had interesting results, > : but it wasn't stable, which I asumed to be my bad knowledge on how this > : should be implemented correctly. > : Thanks to mav@ we have other controllers working and can test the > : sdmmc part unrelated from mci. > : Nevertheless: multiblock is the real speed issue. > : My speed tests were very impressive, but because of mci problems data > : were corrupted of course. > > I'll see if I can find an hour or two to look into the proper reset of > the mci fifos after use... I'd also like to get 4-bit working too... I have added some debug info with 4-bit mode enabled: http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump3 > > Right now I'm only getting ~900kB/s (890-919) and we can do much > better, no? > > Warner > _______________________________________________ > 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" > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJee06xJBWvpalMpkRAgZ/AJ9FzKp7Oq00CZqWC/KIb31Ve0EPAgCdGH/l B1mZQcf8IYmdI/8x7C29iLo= =y2Rs -----END PGP SIGNATURE----- From imp at bsdimp.com Fri Jan 23 08:18:43 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Jan 23 08:18:50 2009 Subject: Mount root from SD card? In-Reply-To: <4979EAFE.2030407@bulinfo.net> References: <497896F3.9030908@bulinfo.net> <20090122.093007.1785588956.imp@bsdimp.com> <4979EAFE.2030407@bulinfo.net> Message-ID: <20090123.091523.-192571782.imp@bsdimp.com> In message: <4979EAFE.2030407@bulinfo.net> Krassimir Slavchev writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : M. Warner Losh wrote: : > In message: <497896F3.9030908@bulinfo.net> : > Krassimir Slavchev writes: : > : Index: at91_mci.c : > : =================================================================== : > : --- at91_mci.c (revision 187590) : > : +++ at91_mci.c (working copy) : > : @@ -199,7 +199,7 @@ : > : goto out; : > : } : > : sc->host.f_min = 375000; : > : - sc->host.f_max = at91_master_clock / 2; /* Typically 30MHz */ : > : + sc->host.f_max = AT91C_MASTER_CLOCK / 2; /* Typically 30MHz */ : > : sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; : > : if (sc->wire4) : > : sc->host.caps = MMC_CAP_4_BIT_DATA; : > : > This change is wrong. : : Ok. I did this because at91_master_clock was not defined here. Yea, that's my bad, actually. I've since fixed it. : > : @@ -399,8 +399,8 @@ : > : WR4(sc, MCI_ARGR, cmd->arg); : > : if (cmdr & MCI_CMDR_TRCMD_START) { : > : if (cmdr & MCI_CMDR_TRDIR) { : > : + WR4(sc, MCI_CMDR, cmdr); : > : WR4(sc, PDC_PTCR, PDC_PTCR_RXTEN); : > : - WR4(sc, MCI_CMDR, cmdr); : > : > This change is also wrong. It won't work. Also, why test the : > direction at all if we're just going to do the same thing in both legs : > of the branch? When I was developing the code, I originally had the : > 'send a command and then enable PDC' logic. It didn't work for the : > read case, so now we enable the reader and then send the command. We : > do this based on the logic that it is OK to have the PDC enabled when : > there's no data transfer going, but if we send the command, then take : > an interrupt before we can enable the PDC, we'd lose data. And that : > seemed to happen a lot. : : Ok but I was able to read correctly first blocks ... : Looking at linux's driver they do the same, first sending CMD and then : enable PDC for reading. : : Thanks for latest fixes! Sure. The underlying problem was that we were doing 512 byte transfers for 64 byte requests. Ooops, that's bad. Warner From imp at bsdimp.com Fri Jan 23 08:45:44 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Jan 23 08:45:50 2009 Subject: Mount root from SD card? In-Reply-To: <4979ED3A.2020008@bulinfo.net> References: <20090122235712.GO50103@cicely7.cicely.de> <20090122.171304.-1528842637.imp@bsdimp.com> <4979ED3A.2020008@bulinfo.net> Message-ID: <20090123.094309.773732871.imp@bsdimp.com> In message: <4979ED3A.2020008@bulinfo.net> Krassimir Slavchev writes: : I have added some debug info with 4-bit mode enabled: : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump3 Looks like we're getting a FIFO error here. That's similar to what I'm seeing as well. I'm not sure why... I also have implemented a full reset of the device between reads, but I get a CRC error there. Time to look at the latest datasheet to see if I can find a better workaround. Warner From krassi at bulinfo.net Fri Jan 23 09:02:38 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Fri Jan 23 09:02:45 2009 Subject: Mount root from SD card? In-Reply-To: <20090123.094309.773732871.imp@bsdimp.com> References: <20090122235712.GO50103@cicely7.cicely.de> <20090122.171304.-1528842637.imp@bsdimp.com> <4979ED3A.2020008@bulinfo.net> <20090123.094309.773732871.imp@bsdimp.com> Message-ID: <4979F827.1010309@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: > In message: <4979ED3A.2020008@bulinfo.net> > Krassimir Slavchev writes: > : I have added some debug info with 4-bit mode enabled: > : > : http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump3 > > Looks like we're getting a FIFO error here. That's similar to what > I'm seeing as well. I'm not sure why... > > I also have implemented a full reset of the device between reads, but > I get a CRC error there. Time to look at the latest datasheet to see > if I can find a better workaround. > > Warner > Let me know if you want to test something. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJefgnxJBWvpalMpkRApfmAKC3BkB4JpP+pAzwHhXcg3uAZ1KAsgCgn8Jv aUMFhwV7Q2BhwLRQ+OadJWo= =AUNO -----END PGP SIGNATURE----- From gjb at semihalf.com Wed Jan 28 02:37:06 2009 From: gjb at semihalf.com (Grzegorz Bernacki) Date: Wed Jan 28 02:37:12 2009 Subject: svn commit: r186730 - in head... In-Reply-To: <200901071955.n07Jthqu057051@casselton.net> References: <200901071955.n07Jthqu057051@casselton.net> Message-ID: <4980356A.4090403@semihalf.com> Mark Tinguely wrote: > Here is the "svn diff" from a week or so ago. The url is below in case > the inclusion adds some extra characters. > > http://www.casselton.net/~tinguely/arm_pmap_unmanage.diff > Mark, I downloaded your patch and applied it (after a few modification to get rid of compile errors). However, when I boot the board with new code it hangs. The problem is with uma allocator for pv_entries. When there is no more entries available it create new ones. It includes mapping memory into kernel using pmap_qenter. And then recurrence starts, pmap_qenter calls pmap_kenter which tries to allocate pv_entry and so on. I think that pv_entries for pmap_kenter should be allocated from some special pool to avoid this problem. Or some threshold could be set for uma allocator to force allocation of new pv_entries if number of free entries drops below the threshold, but I am not sure if it is possible without extending uma interface. Grzesiek From tinguely at casselton.net Wed Jan 28 06:15:32 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Wed Jan 28 06:15:38 2009 Subject: svn commit: r186730 - in head... In-Reply-To: <4980356A.4090403@semihalf.com> Message-ID: <200901281415.n0SEFVsG075471@casselton.net> > I downloaded your patch and applied it (after a few modification to get rid of compile errors). However, when I boot the board with new code it hangs. The problem is with uma allocator for pv_entries. When there is no more entries available it create new ones. It includes mapping memory into kernel using pmap_qenter. And then recurrence starts, pmap_qenter calls pmap_kenter which tries to allocate pv_entry and so on. > I think that pv_entries for pmap_kenter should be allocated from some special pool to avoid this problem. Or some threshold could be set for uma allocator to force allocation of new pv_entries if number of free entries drops below the threshold, but I am not sure if it is possible without extending uma interface. > > Grzesiek Thank-you for the feedback. I should have anticipated that. If mapping the kernel mappings is the correct thing to do, we may add a map/virtual address entry to the md_page to remember the first mapping and then only manage on the duplicate kernel mapping. The extra check should be less overhead than managing every kernel mapping. --Mark Tinguely From thompsa at FreeBSD.org Thu Jan 29 23:56:30 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Thu Jan 29 23:56:37 2009 Subject: busdma problem Message-ID: <20090130072649.GF73709@citylink.fud.org.nz> Hi, I am having an issue with busdma when bounce buffers are used. I have patched _bus_dmamap_sync_bp() to print out the details when a bounce happens and also print the driver buffer before and after. During normal dma everything is fine, Before: 0xc7c1ab40 data=c1:4b:a4:80:c0:5d:ed:78:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02: [...do dma...] After: 0xc7c1ab40 data=2c:03:4e:00:6f:00:76:00:61:00:74:00:65:00:6c:00:20:00:57:00:69:00:72:00: The buffer 2c:03:4e:00:... is the correct response from the hardware. When a bounce buffer is used I see the correct data come in and be bcopy'd to my memory region but it is not visible when read later. Before: 0xc7c29b40 data=c1:50:19:00:c0:5d:ed:f8:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02: dma bounced 0x1271000 -> 0xc7c29b40 len=193 data=2c:03:4e:00:6f:00:76:00:61:00:74:00:65:00:6c:00:20:00:57:00:69:00:72:00: After: 0xc7c29b40 data=c1:50:19:00:c0:5d:ed:f8:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02: This is on an xscale ixp425 with 128m memory, the PCI dma tag is limited to 64m. Andrew Index: src/sys/arm/arm/busdma_machdep.c =================================================================== --- src/sys/arm/arm/busdma_machdep.c (revision 13717) +++ src/sys/arm/arm/busdma_machdep.c (working copy) @@ -1128,6 +1128,19 @@ } static void +dbgprint_safe(const uint8_t *buf, int len) +{ + const uint8_t *p; + int i; + + if (len > 24) + len = 24; + + for (i = 0, p = buf; i < len; i++, p++) + printf("%02x:", *p); +} + +static void _bus_dmamap_sync_bp(bus_dma_tag_t dmat, bus_dmamap_t map, bus_dmasync_op_t op) { struct bounce_page *bpage; @@ -1144,6 +1157,7 @@ cpu_l2cache_wb_range(bpage->vaddr, bpage->datacount); } + dmat->bounce_zone->total_bounced++; } if (op & BUS_DMASYNC_POSTREAD) { if (bpage->vaddr_nocache == 0) { @@ -1155,6 +1169,12 @@ bcopy((void *)(bpage->vaddr_nocache != 0 ? bpage->vaddr_nocache : bpage->vaddr), (void *)bpage->datavaddr, bpage->datacount); + printf("dma bounced %p -> %p len=%d data=", + (void *)bpage->busaddr, (void *)bpage->datavaddr, + bpage->datacount); + dbgprint_safe((void *)bpage->datavaddr, bpage->datacount); + printf("\n"); + dmat->bounce_zone->total_bounced++; } } } From thompsa at FreeBSD.org Fri Jan 30 09:31:53 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Fri Jan 30 09:31:59 2009 Subject: busdma problem In-Reply-To: <49833653.60509@freebsd.org> References: <20090130072649.GF73709@citylink.fud.org.nz> <49833653.60509@freebsd.org> Message-ID: <20090130173147.GC2160@citylink.fud.org.nz> On Fri, Jan 30, 2009 at 09:18:11AM -0800, Sam Leffler wrote: > Andrew Thompson wrote: >> Hi, >> >> >> I am having an issue with busdma when bounce buffers are used. I have >> patched _bus_dmamap_sync_bp() to print out the details when a bounce >> happens and also print the driver buffer before and after. >> >> During normal dma everything is fine, >> >> Before: 0xc7c1ab40 data=c1:4b:a4:80:c0:5d:ed:78:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02: >> [...do dma...] >> After: 0xc7c1ab40 data=2c:03:4e:00:6f:00:76:00:61:00:74:00:65:00:6c:00:20:00:57:00:69:00:72:00: >> >> The buffer 2c:03:4e:00:... is the correct response from the hardware. >> When a bounce buffer is used I see the correct data come in and be >> bcopy'd to my memory region but it is not visible when read later. >> >> Before: 0xc7c29b40 data=c1:50:19:00:c0:5d:ed:f8:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02: >> dma bounced 0x1271000 -> 0xc7c29b40 len=193 data=2c:03:4e:00:6f:00:76:00:61:00:74:00:65:00:6c:00:20:00:57:00:69:00:72:00: >> After: 0xc7c29b40 data=c1:50:19:00:c0:5d:ed:f8:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02: >> >> >> This is on an xscale ixp425 with 128m memory, the PCI dma tag is limited >> to 64m. >> > What device is involved? Is this on HEAD? This is usb/ehci. The specific function I am looking at is usbd_get_string() in usbdi.c, it does a usb request to fill usb_string_descriptor_t that is a stack variable. This is on HEAD, a simple way to see it is to run 'usbdevs -v' and see the vendor/product strings as garbage (sometimes). I have committed a fix so that total_bounces is actually incremented. Andrew From sam at freebsd.org Fri Jan 30 09:45:19 2009 From: sam at freebsd.org (Sam Leffler) Date: Fri Jan 30 09:45:25 2009 Subject: busdma problem In-Reply-To: <20090130072649.GF73709@citylink.fud.org.nz> References: <20090130072649.GF73709@citylink.fud.org.nz> Message-ID: <49833653.60509@freebsd.org> Andrew Thompson wrote: > Hi, > > > I am having an issue with busdma when bounce buffers are used. I have > patched _bus_dmamap_sync_bp() to print out the details when a bounce > happens and also print the driver buffer before and after. > > During normal dma everything is fine, > > Before: 0xc7c1ab40 data=c1:4b:a4:80:c0:5d:ed:78:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02: > [...do dma...] > After: 0xc7c1ab40 data=2c:03:4e:00:6f:00:76:00:61:00:74:00:65:00:6c:00:20:00:57:00:69:00:72:00: > > The buffer 2c:03:4e:00:... is the correct response from the hardware. > When a bounce buffer is used I see the correct data come in and be > bcopy'd to my memory region but it is not visible when read later. > > Before: 0xc7c29b40 data=c1:50:19:00:c0:5d:ed:f8:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02: > dma bounced 0x1271000 -> 0xc7c29b40 len=193 data=2c:03:4e:00:6f:00:76:00:61:00:74:00:65:00:6c:00:20:00:57:00:69:00:72:00: > After: 0xc7c29b40 data=c1:50:19:00:c0:5d:ed:f8:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02: > > > This is on an xscale ixp425 with 128m memory, the PCI dma tag is limited > to 64m. > > What device is involved? Is this on HEAD? Sam From tinguely at casselton.net Fri Jan 30 11:29:46 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Fri Jan 30 11:29:53 2009 Subject: svn commit: r186730 - in head... In-Reply-To: <4980356A.4090403@semihalf.com> Message-ID: <200901301929.n0UJTifW020980@casselton.net> > Mark Tinguely wrote: > > Here is the "svn diff" from a week or so ago. The url is below in case > > the inclusion adds some extra characters. > > > > http://www.casselton.net/~tinguely/arm_pmap_unmanage.diff > > > > Mark, > > I downloaded your patch and applied it (after a few modification to get rid of compile errors). However, when I boot the board with new code it hangs. The problem is with uma allocator for pv_entries. When there is no more entries available it create new ones. It includes mapping memory into kernel using pmap_qenter. And then recurrence starts, pmap_qenter calls pmap_kenter which tries to allocate pv_entry and so on. > I think that pv_entries for pmap_kenter should be allocated from some special pool to avoid this problem. Or some threshold could be set for uma allocator to force allocation of new pv_entries if number of free entries drops below the threshold, but I am not sure if it is possible without extending uma interface. > > Grzesiek I removed the patch at the above address and replaced it with one that stores the KVA in a the vm_page machine dependant variable pv_kva if this is the first mapping of the page. This pv_kva value should be removed anytime the pv_entry is removed. The vast majority of kernel mappings will never be shared, so this should be more effiecient than my earlier patch, and should not have the pv_entry UMA recursion problem. Now, I should also be able to remove the test to see if the pvzone is allocated since those pages are not shared. I also moved some code around to simply the tests and to avoid a potential error that has been in the pmap.c for a long time, but I just noticed it. at line 3431 of revision 184730 in pmap_enter_locked(), the pve could have been freed in the PG_UNMANAGED | PG_FICTITIOUS pages; the KASSERT in line 3429 would not catch the situation. Disclaimer: This is mostly a concept. I ran cc on this file and removed the syntax errors - sorry about that, but haven't gone much further. I will create a cross compiling machine that runs the emulator. --Mark Tinguely. From thompsa at FreeBSD.org Fri Jan 30 14:07:20 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Fri Jan 30 14:07:26 2009 Subject: busdma problem In-Reply-To: <20090130173147.GC2160@citylink.fud.org.nz> References: <20090130072649.GF73709@citylink.fud.org.nz> <49833653.60509@freebsd.org> <20090130173147.GC2160@citylink.fud.org.nz> Message-ID: <20090130220714.GA10743@citylink.fud.org.nz> On Fri, Jan 30, 2009 at 09:31:47AM -0800, Andrew Thompson wrote: > On Fri, Jan 30, 2009 at 09:18:11AM -0800, Sam Leffler wrote: > > Andrew Thompson wrote: > >> Hi, > >> > >> > >> I am having an issue with busdma when bounce buffers are used. I have > >> patched _bus_dmamap_sync_bp() to print out the details when a bounce > >> happens and also print the driver buffer before and after. > >> > >> During normal dma everything is fine, > >> > >> Before: 0xc7c1ab40 data=c1:4b:a4:80:c0:5d:ed:78:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02: > >> [...do dma...] > >> After: 0xc7c1ab40 data=2c:03:4e:00:6f:00:76:00:61:00:74:00:65:00:6c:00:20:00:57:00:69:00:72:00: > >> > >> The buffer 2c:03:4e:00:... is the correct response from the hardware. > >> When a bounce buffer is used I see the correct data come in and be > >> bcopy'd to my memory region but it is not visible when read later. > >> > >> Before: 0xc7c29b40 data=c1:50:19:00:c0:5d:ed:f8:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02: > >> dma bounced 0x1271000 -> 0xc7c29b40 len=193 data=2c:03:4e:00:6f:00:76:00:61:00:74:00:65:00:6c:00:20:00:57:00:69:00:72:00: > >> After: 0xc7c29b40 data=c1:50:19:00:c0:5d:ed:f8:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02: > >> > >> > >> This is on an xscale ixp425 with 128m memory, the PCI dma tag is limited > >> to 64m. > >> > > What device is involved? Is this on HEAD? > > This is usb/ehci. The specific function I am looking at is > usbd_get_string() in usbdi.c, it does a usb request to fill > usb_string_descriptor_t that is a stack variable. As suggested by Sam, this works properly when the buffer is malloc'd instead of taken from the stack. So is this now a bug or a feature?? Andrew From avinogradovs at clearpathnet.com Fri Jan 30 15:00:04 2009 From: avinogradovs at clearpathnet.com (Alex Vinogradovs) Date: Fri Jan 30 15:00:10 2009 Subject: NFS on ARM/IXP435 Message-ID: <49838270.7090301@clearpathnet.com> Guys, I was able to boot into multiuser on IXP435-based board using CAMBRIA kernel config from 8.0 current. The only problem I ran into was mounting NFS from userspace - it would just hang, although kernel would mount root via NFS without problems. Best regards, Alex Vinogradovs From sam at freebsd.org Fri Jan 30 17:58:32 2009 From: sam at freebsd.org (Sam Leffler) Date: Fri Jan 30 17:58:38 2009 Subject: NFS on ARM/IXP435 In-Reply-To: <49838270.7090301@clearpathnet.com> References: <49838270.7090301@clearpathnet.com> Message-ID: <4983B041.4050200@freebsd.org> Alex Vinogradovs wrote: > Guys, > > I was able to boot into multiuser on IXP435-based board using CAMBRIA > kernel config from > 8.0 current. The only problem I ran into was mounting NFS from > userspace - it would just hang, > although kernel would mount root via NFS without problems. > I've had no problems using nfs-root, cf-root, or mounting nfs filesystems after boot. The only thing to beware is to not use NPE-A as it doesn't work. Sam From avinogradovs at clearpathnet.com Fri Jan 30 18:21:15 2009 From: avinogradovs at clearpathnet.com (Alex Vinogradovs) Date: Fri Jan 30 18:21:21 2009 Subject: NFS on ARM/IXP435 In-Reply-To: <4983B041.4050200@freebsd.org> References: <49838270.7090301@clearpathnet.com> <4983B041.4050200@freebsd.org> Message-ID: <4983B5D2.9040500@clearpathnet.com> Sam Leffler wrote: > > I've had no problems using nfs-root, cf-root, or mounting nfs > filesystems after boot. The only thing to beware is to not use NPE-A > as it doesn't work. > > Sam > Yeah, my situation is kind of odd... I've got operational network, but whether it is during startup (via fstab), or manually later on, mount_nfs just hangs, while / is mounted via NFS by kernel. But since there is no proc/truss, I'm clueless how to see what is it doing... Indeed I've noticed I've only got one interface out of two, so you've answered my question ahead of time :D just in case, here are my boot messages: KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #6: Fri Jan 30 13:47:27 PST 2009 alexv@alexv:/usr/src.2/sys/arm/compile/flex100 CPU: IXP435 rev 1 (ARMv5TE) (XScale core) DC enabled IC enabled WB enabled LABT branch prediction enabled 32KB/32B 32-way Instruction cache 32KB/32B 32-way write-back-locking Data cache real memory = 134217728 (128 MB) avail memory = 125263872 (119 MB) ixp0: on motherboard ixp0: 37fff ixpclk0: on ixp0 ixpiic0: on ixp0 iicbb0: on ixpiic0 iicbus0: on iicbb0 master-only iic0: on iicbus0 iicbus0: at addr 0x5a ad74180: at addr 0x50 on iicbus0 ds16720: at addr 0xd0 on iicbus0 ixpwdog0: on ixp0 uart0: on ixp0 uart0: [FILTER] uart0: console (115200,n,8,1) ixpqmgr0: on ixp0 ixpqmgr0: [ITHREAD] ixpqmgr0: [ITHREAD] npe0: on ixp0 npe0: [ITHREAD] npe0: MAC at 0xc800a000 npe0: MII at 0xc800a000 npe0: load fw image IXP425.NPE-C Func 0x5 Rev 2.1 miibus0: on npe0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto npe0: Ethernet address: 00:03:47:df:32:a8 ata_avila0: on ixp0 ata_avila0: [ITHREAD] ata0: on ata_avila0 ata0: [ITHREAD] ehci0: on ixp0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb0: set host controller mode usb0: set big-endian mode usb0: EHCI version 1.0 usb0: stop timeout usb0: set host controller mode usb0: set big-endian mode usb0 on ehci0 usb0: USB revision 2.0 uhub0: on usb0 uhub0: 1 port with 1 removable, self powered ehci1: on ixp0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb1: set host controller mode usb1: set big-endian mode usb1: EHCI version 1.0 usb1: stop timeout usb1: set host controller mode usb1: set big-endian mode usb1 on ehci1 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 1 port with 1 removable, self powered ixpclk0: [FILTER] Timecounter "IXP4XX Timer" frequency 66666600 Hz quality 1000 Timecounters tick every 10.000 msec bootpc_init: wired to interface 'npe0' Sending DHCP Discover packet from interface npe0 (00:03:47:df:32:a8) Received DHCP Offer packet on npe0 from 10.1.16.109 (accepted) (no root path) Received DHCP Offer packet on npe0 from 10.1.8.100 via 10.1.16.2 (ignored) (no root path) Received DHCP Offer packet on npe0 from 10.1.8.100 via 10.1.16.3 (ignored) (no root path) Sending DHCP Request packet from interface npe0 (00:03:47:df:32:a8) Received DHCP Ack packet on npe0 from 10.1.16.109 (accepted) (got root path) npe0 at 10.1.16.114 server 10.1.16.109 boot file /tftpboot/flex100 subnet mask 255.255.255.0 router 10.1.16.1 rootfs 10.1.16.109:/armroot hostname flex100 Adjusted interface npe0 Trying to mount root from nfs: NFS ROOT: 10.1.16.109:/armroot 10.1.16.109:/armroot on / (nfs, read-only) devfs on /dev (devfs, local) /dev/md0 on /var (ufs, local) /dev/md1 on /tmp (ufs, local) npe0: flags=8843 metric 0 mtu 1500 ether 00:03:47:df:32:a8 inet 10.1.16.114 netmask 0xffffff00 broadcast 10.1.16.255 media: Ethernet autoselect (100baseTX ) status: active