From owner-freebsd-arm@freebsd.org Sun Sep 17 02:22:01 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E24D4E1B277 for ; Sun, 17 Sep 2017 02:22:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9FFB86D71C for ; Sun, 17 Sep 2017 02:22:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3115 invoked from network); 17 Sep 2017 02:21:59 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 17 Sep 2017 02:21:59 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 16 Sep 2017 22:21:59 -0400 (EDT) Received: (qmail 18446 invoked from network); 17 Sep 2017 02:21:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Sep 2017 02:21:58 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 2BD81EC86EE; Sat, 16 Sep 2017 19:21:58 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: Pine64+ 2GB (so A64) booting and non-debug vs. debug kernel: "APs not started" for failure cases only, possible missing atomic_load_acq_int's? Date: Sat, 16 Sep 2017 19:21:57 -0700 References: <1C18FF04-6772-4E9C-88C5-B8D5478C5809@dsl-only.net> <6D63486A-E933-4CC2-9A24-0688BE01A0DA@dsl-only.net> <8E15A747-3413-4537-9ECA-5EDAD1285351@dsl-only.net> <256CF612-1D52-4BCC-981B-E476F6EEC9AB@dsl-only.net> <2FC8A531-5E8F-4765-A1F3-A8D6A6AA0C14@dsl-only.net> To: Emmanuel Vadot , freebsd-arm , freebsd-hackers In-Reply-To: <2FC8A531-5E8F-4765-A1F3-A8D6A6AA0C14@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 02:22:02 -0000 [As the following does not flow well from the previous message and stands somewhat on its own in some respects: I top post this.] ffff0000005fb14c adrp x8, ffff000000aaa000 = ffff0000005fb150 add x8, x8, #0x778 ffff0000005fb154 adrp x0, ffff0000006c9000 = ffff0000005fb158 add x0, x0, #0xb8a ffff0000005fb15c stlr w20, [x8] ffff0000005fb160 sev I ran into the following mention of SEV and making sure it is appropriately delayed: > The mechanism that signals an event to other PEs is IMPLEMENTATION = DEFINED. The PE is not required to guarantee the ordering of this event = with respect to the completion of memory accesses by instructions before = the SEV instruction. Therefore, ARM recommends that software includes a = DSB instruction before any SEV instruction. >=20 > The SEVL instruction appears to execute in program order relative to = any subsequent WFE instruction executed on the same PE, without the need = for any explicit insertion of barrier instructions. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Sep-16, at 4:08 PM, Mark Millard wrote: > [Adding a couple of numbers that help > interpret what I found as far as what > specifically did not work as expected.] >=20 > On 2017-Sep-16, at 3:17 PM, Mark Millard wrote: >=20 >> A new finding: >>=20 >> When verbose boot messages are enabled >> there is an earlier contrast between when >> booting works overall vs. when it later >> fails: >>=20 >> When it works: >>=20 >> subsystem f000000 >> release_aps(0)... Release APs >> done. >>=20 >> When it fails:=20 >>=20 >> subsystem f000000 >> release_aps(0)... Release APs >> APs not started >> done. >>=20 >> And it well explains why ->pc_curthread >> ends up NULL for secondaries (in particular >> cpu =3D=3D 1), init_secondary had never executed >> the assignments show below:=20 >>=20 >> while (!aps_ready) >> __asm __volatile("wfe"); >>=20 >> /* Initialize curthread */ >> KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); >> pcpup->pc_curthread =3D pcpup->pc_idlethread; >> pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >>=20 >> The subsystem messages are from: >>=20 >> static void >> release_aps(void *dummy __unused) >> { =20 >> int i; >>=20 >> /* Only release CPUs if they exist */ >> if (mp_ncpus =3D=3D 1) >> return; >>=20 >> intr_pic_ipi_setup(IPI_AST, "ast", ipi_ast, NULL); >> intr_pic_ipi_setup(IPI_PREEMPT, "preempt", ipi_preempt, NULL); >> intr_pic_ipi_setup(IPI_RENDEZVOUS, "rendezvous", = ipi_rendezvous, NULL); >> intr_pic_ipi_setup(IPI_STOP, "stop", ipi_stop, NULL); >> intr_pic_ipi_setup(IPI_STOP_HARD, "stop hard", ipi_stop, NULL); >> intr_pic_ipi_setup(IPI_HARDCLOCK, "hardclock", ipi_hardclock, = NULL); >>=20 >> atomic_store_rel_int(&aps_ready, 1); >> /* Wake up the other CPUs */ >> __asm __volatile("sev"); >>=20 >> printf("Release APs\n"); >>=20 >> for (i =3D 0; i < 2000; i++) { >> if (smp_started) >> return; >> DELAY(1000); >> } >>=20 >> printf("APs not started\n"); >> } =20 >> SYSINIT(start_aps, SI_SUB_SMP, SI_ORDER_FIRST, release_aps, NULL); >>=20 >>=20 >> init_secondary has an example or two of not using >> atomic_load_acq_int when atomic_store_rel_int is in >> use. One is: >>=20 >> while (!aps_ready) >> __asm __volatile("wfe"); >>=20 >> /* Initialize curthread */ >> KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); >> pcpup->pc_curthread =3D pcpup->pc_idlethread; >> pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >>=20 >> where aps_ready was declared via: >>=20 >> /* Set to 1 once we're ready to let the APs out of the pen. */ >> volatile int aps_ready =3D 0; >>=20 >> where release_aps has the use of atomic_store_rel_int: >>=20 >> atomic_store_rel_int(&aps_ready, 1); >> /* Wake up the other CPUs */ >> __asm __volatile("sev"); >>=20 >> There is also in init_secondary: >>=20 >> atomic_add_rel_32(&smp_cpus, 1); >>=20 >> if (smp_cpus =3D=3D mp_ncpus) { >> /* enable IPI's, tlb shootdown, freezes etc */ >> atomic_store_rel_int(&smp_started, 1); >> } >>=20 >> where smp_cpus is accessed without being explicitly >> atomic. mp_ncpus seems to have no atomic use at all. >>=20 >> Where: >>=20 >> /usr/src/sys/sys/smp.h:extern int smp_cpus; >> /usr/src/sys/kern/subr_smp.c:int smp_cpus =3D 1; /* how many cpu's = running */ >>=20 >> So no "volatile", unlike the earlier example. >>=20 >> /usr/src/sys/kern/kern_umtx.c: if (smp_cpus > 1) { >> /usr/src/sys/kern/subr_smp.c:SYSCTL_INT(_kern_smp, OID_AUTO, cpus, = CTLFLAG_RD|CTLFLAG_CAPRD, &smp_cpus, 0, >>=20 >> /usr/src/sys/sys/smp.h:extern int mp_ncpus; >> /usr/src/sys/kern/subr_smp.c:int mp_ncpus; >>=20 >>=20 >> The smp_started is not explicitly accessed as atomic >> in release_aps but in init_secondary has its update >> to 1 via: >>=20 >> mtx_lock_spin(&ap_boot_mtx); >>=20 >> atomic_add_rel_32(&smp_cpus, 1); >>=20 >> if (smp_cpus =3D=3D mp_ncpus) { >> /* enable IPI's, tlb shootdown, freezes etc */ >> atomic_store_rel_int(&smp_started, 1); >> } >>=20 >> mtx_unlock_spin(&ap_boot_mtx); >>=20 >> where: >>=20 >> /usr/src/sys/sys/smp.h:extern volatile int smp_started; >> /usr/src/sys/kern/subr_smp.c:volatile int smp_started; >>=20 >> ("volatile" again for this context.) >>=20 >> I'll also note that for the sparc64 architecture >> there is some code like: >>=20 >> if (__predict_false(atomic_load_acq_int(&smp_started) =3D=3D 0)) >>=20 >> that is explicitly matched to the atomic_store_rel_int >> in its mp_machdep.c . >>=20 >> I do not have enough background aarch64 knowledge to >> know if it is provable that atomic_load_acq_int is not >> needed in some of these cases. >>=20 >> But getting "APs not started" at least sometimes >> suggests an intermittent failure of the code as >> it is. >>=20 >>=20 >> Another difference is lack of explicit initialization >> of smp_started but explicit initialization of aps_ready >> and smp_cpus . >>=20 >>=20 >>=20 >> I have no clue if the boot sequence is supposed to >> handle "APs not started" by reverting to not being >> a symmetric multiprocessing boot or some other >> specific way instead of trying to avoiding use of >> what was not initialized by: >>=20 >> pcpup->pc_curthread =3D pcpup->pc_idlethread; >> pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >>=20 >> in init_secondary. >=20 >=20 > Example mp_ncpus and smp_cpus figures from a > failed Pine64+ 2GB boot: >=20 > db> print/x *smp_cpus > 1 > db> print/x *mp_ncpus > 138800000004 >=20 > But that should be a 4 byte width. Showing > some context for reference: >=20 > db> x/bx mp_ncpus-4,4=20 > rebooting: 0 0 0 0 > db> x/bx mp_ncpus,4 > mp_ncpus: 4 0 0 0 > db> x/bx mp_ncpus+4,4=20 > scsi_delay: 88 13 0 0 >=20 > For completeness: >=20 > db> x/bx smp_cpus-4,4 > sysctl___kern_smp_disabled+0x5c: 0 0 0 0 > db> x/bx smp_cpus,4 > smp_cpus: 1 0 0 0 > db> x/bx smp_cpus+4,4=20 > smp_cpus+0x4: 0 0 0 0 >=20 > So smp_cpus was not incremented in memory. This > goes along with no occurances of: >=20 > pcpup->pc_curthread =3D pcpup->pc_idlethread; > pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >=20 > updates happening in init_secondary: >=20 > /* Spin until the BSP releases the APs */ > while (!aps_ready) > __asm __volatile("wfe"); >=20 > /* Initialize curthread */ > KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); > pcpup->pc_curthread =3D pcpup->pc_idlethread; > pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; > . . . > mtx_lock_spin(&ap_boot_mtx); >=20 > atomic_add_rel_32(&smp_cpus, 1); >=20 > if (smp_cpus =3D=3D mp_ncpus) { > /* enable IPI's, tlb shootdown, freezes etc */ > atomic_store_rel_int(&smp_started, 1); > } >=20 > mtx_unlock_spin(&ap_boot_mtx); >=20 > Which seems to imply that the aps_ready > update: >=20 > atomic_store_rel_int(&aps_ready, 1); > /* Wake up the other CPUs */ > __asm __volatile("sev"); >=20 > in release_aps was not seen in the: >=20 > while (!aps_ready) > __asm __volatile("wfe"); >=20 > in init_secondary. >=20 > My guess is that "while (!aps_ready)" needs > to be explicit about its atomic status. > aps_ready is already volatile but apparently > that is not enough for this context to be > reliable. >=20 > The other potential needs for explicit atomics > are for later execution but may be required > overall as well. From owner-freebsd-arm@freebsd.org Sun Sep 17 02:48:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D62AE1CD05 for ; Sun, 17 Sep 2017 02:48:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EC256E26A for ; Sun, 17 Sep 2017 02:48:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26071 invoked from network); 17 Sep 2017 02:48:04 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 17 Sep 2017 02:48:04 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 16 Sep 2017 22:48:04 -0400 (EDT) Received: (qmail 2970 invoked from network); 17 Sep 2017 02:48:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Sep 2017 02:48:04 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B3016EC86EE; Sat, 16 Sep 2017 19:48:03 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: SOLVED (patch): FYI: Pine64+ 2GB (so A64) booting and non-debug vs. debug kernel: "APs not started" for failure cases only: solved with patch Date: Sat, 16 Sep 2017 19:48:03 -0700 References: <1C18FF04-6772-4E9C-88C5-B8D5478C5809@dsl-only.net> <6D63486A-E933-4CC2-9A24-0688BE01A0DA@dsl-only.net> <8E15A747-3413-4537-9ECA-5EDAD1285351@dsl-only.net> <256CF612-1D52-4BCC-981B-E476F6EEC9AB@dsl-only.net> <2FC8A531-5E8F-4765-A1F3-A8D6A6AA0C14@dsl-only.net> To: Emmanuel Vadot , freebsd-arm , freebsd-hackers In-Reply-To: Message-Id: <514378CB-4E18-4BA6-B1BF-AEFFAFB7ADED@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 02:48:06 -0000 On 2017-Sep-16, at 7:21 PM, Mark Millard wrote: > [As the following does not flow well from the previous > message and stands somewhat on its own in some respects: > I top post this.] >=20 > ffff0000005fb14c adrp x8, ffff000000aaa000 = > ffff0000005fb150 add x8, x8, #0x778 > ffff0000005fb154 adrp x0, ffff0000006c9000 = > ffff0000005fb158 add x0, x0, #0xb8a > ffff0000005fb15c stlr w20, [x8] > ffff0000005fb160 sev >=20 > I ran into the following mention of SEV and making sure > it is appropriately delayed: >=20 >> The mechanism that signals an event to other PEs is IMPLEMENTATION = DEFINED. The PE is not required to guarantee the ordering of this event = with respect to the completion of memory accesses by instructions before = the SEV instruction. Therefore, ARM recommends that software includes a = DSB instruction before any SEV instruction. >>=20 >> The SEVL instruction appears to execute in program order relative to = any subsequent WFE instruction executed on the same PE, without the need = for any explicit insertion of barrier instructions. The following patch has allowed me to boot the pine64+ 2GB with even a non-debug kernel. # svnlite diff /usr/src/sys/arm64/arm64/mp_machdep.c Index: /usr/src/sys/arm64/arm64/mp_machdep.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm64/arm64/mp_machdep.c (revision 323246) +++ /usr/src/sys/arm64/arm64/mp_machdep.c (working copy) @@ -236,7 +236,9 @@ =20 atomic_store_rel_int(&aps_ready, 1); /* Wake up the other CPUs */ - __asm __volatile("sev"); + __asm __volatile( + "dsb ish \n" + "sev \n"); =20 printf("Release APs\n"); I will add this patch to bugzilla 222234. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Sep-16, at 4:08 PM, Mark Millard wrote: > [Adding a couple of numbers that help > interpret what I found as far as what > specifically did not work as expected.] >=20 > On 2017-Sep-16, at 3:17 PM, Mark Millard wrote: >=20 >> A new finding: >>=20 >> When verbose boot messages are enabled >> there is an earlier contrast between when >> booting works overall vs. when it later >> fails: >>=20 >> When it works: >>=20 >> subsystem f000000 >> release_aps(0)... Release APs >> done. >>=20 >> When it fails:=20 >>=20 >> subsystem f000000 >> release_aps(0)... Release APs >> APs not started >> done. >>=20 >> And it well explains why ->pc_curthread >> ends up NULL for secondaries (in particular >> cpu =3D=3D 1), init_secondary had never executed >> the assignments show below:=20 >>=20 >> while (!aps_ready) >> __asm __volatile("wfe"); >>=20 >> /* Initialize curthread */ >> KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); >> pcpup->pc_curthread =3D pcpup->pc_idlethread; >> pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >>=20 >> The subsystem messages are from: >>=20 >> static void >> release_aps(void *dummy __unused) >> { =20 >> int i; >>=20 >> /* Only release CPUs if they exist */ >> if (mp_ncpus =3D=3D 1) >> return; >>=20 >> intr_pic_ipi_setup(IPI_AST, "ast", ipi_ast, NULL); >> intr_pic_ipi_setup(IPI_PREEMPT, "preempt", ipi_preempt, NULL); >> intr_pic_ipi_setup(IPI_RENDEZVOUS, "rendezvous", ipi_rendezvous, = NULL); >> intr_pic_ipi_setup(IPI_STOP, "stop", ipi_stop, NULL); >> intr_pic_ipi_setup(IPI_STOP_HARD, "stop hard", ipi_stop, NULL); >> intr_pic_ipi_setup(IPI_HARDCLOCK, "hardclock", ipi_hardclock, = NULL); >>=20 >> atomic_store_rel_int(&aps_ready, 1); >> /* Wake up the other CPUs */ >> __asm __volatile("sev"); >>=20 >> printf("Release APs\n"); >>=20 >> for (i =3D 0; i < 2000; i++) { >> if (smp_started) >> return; >> DELAY(1000); >> } >>=20 >> printf("APs not started\n"); >> } =20 >> SYSINIT(start_aps, SI_SUB_SMP, SI_ORDER_FIRST, release_aps, NULL); >>=20 >>=20 >> init_secondary has an example or two of not using >> atomic_load_acq_int when atomic_store_rel_int is in >> use. One is: >>=20 >> while (!aps_ready) >> __asm __volatile("wfe"); >>=20 >> /* Initialize curthread */ >> KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); >> pcpup->pc_curthread =3D pcpup->pc_idlethread; >> pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >>=20 >> where aps_ready was declared via: >>=20 >> /* Set to 1 once we're ready to let the APs out of the pen. */ >> volatile int aps_ready =3D 0; >>=20 >> where release_aps has the use of atomic_store_rel_int: >>=20 >> atomic_store_rel_int(&aps_ready, 1); >> /* Wake up the other CPUs */ >> __asm __volatile("sev"); >>=20 >> There is also in init_secondary: >>=20 >> atomic_add_rel_32(&smp_cpus, 1); >>=20 >> if (smp_cpus =3D=3D mp_ncpus) { >> /* enable IPI's, tlb shootdown, freezes etc */ >> atomic_store_rel_int(&smp_started, 1); >> } >>=20 >> where smp_cpus is accessed without being explicitly >> atomic. mp_ncpus seems to have no atomic use at all. >>=20 >> Where: >>=20 >> /usr/src/sys/sys/smp.h:extern int smp_cpus; >> /usr/src/sys/kern/subr_smp.c:int smp_cpus =3D 1; /* how many cpu's = running */ >>=20 >> So no "volatile", unlike the earlier example. >>=20 >> /usr/src/sys/kern/kern_umtx.c: if (smp_cpus > 1) { >> /usr/src/sys/kern/subr_smp.c:SYSCTL_INT(_kern_smp, OID_AUTO, cpus, = CTLFLAG_RD|CTLFLAG_CAPRD, &smp_cpus, 0, >>=20 >> /usr/src/sys/sys/smp.h:extern int mp_ncpus; >> /usr/src/sys/kern/subr_smp.c:int mp_ncpus; >>=20 >>=20 >> The smp_started is not explicitly accessed as atomic >> in release_aps but in init_secondary has its update >> to 1 via: >>=20 >> mtx_lock_spin(&ap_boot_mtx); >>=20 >> atomic_add_rel_32(&smp_cpus, 1); >>=20 >> if (smp_cpus =3D=3D mp_ncpus) { >> /* enable IPI's, tlb shootdown, freezes etc */ >> atomic_store_rel_int(&smp_started, 1); >> } >>=20 >> mtx_unlock_spin(&ap_boot_mtx); >>=20 >> where: >>=20 >> /usr/src/sys/sys/smp.h:extern volatile int smp_started; >> /usr/src/sys/kern/subr_smp.c:volatile int smp_started; >>=20 >> ("volatile" again for this context.) >>=20 >> I'll also note that for the sparc64 architecture >> there is some code like: >>=20 >> if (__predict_false(atomic_load_acq_int(&smp_started) =3D=3D 0)) >>=20 >> that is explicitly matched to the atomic_store_rel_int >> in its mp_machdep.c . >>=20 >> I do not have enough background aarch64 knowledge to >> know if it is provable that atomic_load_acq_int is not >> needed in some of these cases. >>=20 >> But getting "APs not started" at least sometimes >> suggests an intermittent failure of the code as >> it is. >>=20 >>=20 >> Another difference is lack of explicit initialization >> of smp_started but explicit initialization of aps_ready >> and smp_cpus . >>=20 >>=20 >>=20 >> I have no clue if the boot sequence is supposed to >> handle "APs not started" by reverting to not being >> a symmetric multiprocessing boot or some other >> specific way instead of trying to avoiding use of >> what was not initialized by: >>=20 >> pcpup->pc_curthread =3D pcpup->pc_idlethread; >> pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >>=20 >> in init_secondary. >=20 >=20 > Example mp_ncpus and smp_cpus figures from a > failed Pine64+ 2GB boot: >=20 > db> print/x *smp_cpus > 1 > db> print/x *mp_ncpus > 138800000004 >=20 > But that should be a 4 byte width. Showing > some context for reference: >=20 > db> x/bx mp_ncpus-4,4=20 > rebooting: 0 0 0 0 > db> x/bx mp_ncpus,4 > mp_ncpus: 4 0 0 0 > db> x/bx mp_ncpus+4,4=20 > scsi_delay: 88 13 0 0 >=20 > For completeness: >=20 > db> x/bx smp_cpus-4,4 > sysctl___kern_smp_disabled+0x5c: 0 0 0 0 > db> x/bx smp_cpus,4 > smp_cpus: 1 0 0 0 > db> x/bx smp_cpus+4,4=20 > smp_cpus+0x4: 0 0 0 0 >=20 > So smp_cpus was not incremented in memory. This > goes along with no occurances of: >=20 > pcpup->pc_curthread =3D pcpup->pc_idlethread; > pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; >=20 > updates happening in init_secondary: >=20 > /* Spin until the BSP releases the APs */ > while (!aps_ready) > __asm __volatile("wfe"); >=20 > /* Initialize curthread */ > KASSERT(PCPU_GET(idlethread) !=3D NULL, ("no idle thread")); > pcpup->pc_curthread =3D pcpup->pc_idlethread; > pcpup->pc_curpcb =3D pcpup->pc_idlethread->td_pcb; > . . . > mtx_lock_spin(&ap_boot_mtx); >=20 > atomic_add_rel_32(&smp_cpus, 1); >=20 > if (smp_cpus =3D=3D mp_ncpus) { > /* enable IPI's, tlb shootdown, freezes etc */ > atomic_store_rel_int(&smp_started, 1); > } >=20 > mtx_unlock_spin(&ap_boot_mtx); >=20 > Which seems to imply that the aps_ready > update: >=20 > atomic_store_rel_int(&aps_ready, 1); > /* Wake up the other CPUs */ > __asm __volatile("sev"); >=20 > in release_aps was not seen in the: >=20 > while (!aps_ready) > __asm __volatile("wfe"); >=20 > in init_secondary. >=20 > My guess is that "while (!aps_ready)" needs > to be explicit about its atomic status. > aps_ready is already volatile but apparently > that is not enough for this context to be > reliable. >=20 > The other potential needs for explicit atomics > are for later execution but may be required > overall as well. From owner-freebsd-arm@freebsd.org Sun Sep 17 06:18:10 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61897E2641E for ; Sun, 17 Sep 2017 06:18:10 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDF6473EA3 for ; Sun, 17 Sep 2017 06:18:09 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id b127so5416807lfe.9 for ; Sat, 16 Sep 2017 23:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=o7eimd/+km0qTZ55q1yQXUyNXbQEwAO/tJYV+qBAQFU=; b=vR0Ud+iZXqH44uOc4sPdQDfMPpQ3E6h4r/y7YEAob6iN61uLlUDHBLxOnf2xXXimV7 BRfKgJm8ir1YVJfSQ96X7JRC4Ui1hSa1GiWaYadrxgKxo2gAM1C5po3J5npmATd+5L+B XJrZNQj1Njsij32QtT3fJNquI5ThRhD3DN93mz2qbUcbM+E5+cGsP2oeO+UVwfqWga7O 381I1euyykJaEKikNTZXP8cs1vnxwwr2UDklisPkX3E8lSy7/6jnNp79J0PF+tOPkD+S aE65uzCsOlIMMI38U7P67LeL0LVklYlCJ9F3wkMbTXIRL+MqZokBvocNO2qGr159UnWl +rrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=o7eimd/+km0qTZ55q1yQXUyNXbQEwAO/tJYV+qBAQFU=; b=E/PaT5RuTf842qlSV4MxV8A4Fjn/t7Mry1o2M6DZcVdXl3Ne3dCOQ7iMmE7ADmBOp6 DvqKCj+rcjrlzcJVg1LCzPJEUw8QgJJRMSXMyvsPVOvp1rzv2XcVkWGmdTp6hQHA7eyD ptuxiPPOd3UWyPyxrdoIWk7QTLdHwZlY4lznA/sznaZDeUo9MbKegzIJDxds1wDPWF/Z 9F1PV3o3lLPan3nPh0IiTP97ac/6wAfVlyW/V5DIjVql3hfvUDV4pNlRQ7/EkWHQK5oa SZaAJzK1lYv9EIyC2E6myayPWVbjDZghMyML4GNgI5jb/lRR4bwgWbw1g4NiRONGWZmP E9Jg== X-Gm-Message-State: AHPjjUiBRyfTqklsmiKQKDgeW26PUApQmuWzgoH96YySXkUjW0f1WrCr Oeh8CgCX//lh0GUjD6YeGNOt3F4w1XxP6vjbKRdnUg== X-Google-Smtp-Source: AOwi7QAFH+y4hZBc1QlNxEkbQZ1qXcFF2I7GM/os/BPLG9TT2X4Fk2jNIGQmq4AGF/NBUqsldi5mJCoQ8QRdF5OsEtk= X-Received: by 10.25.41.67 with SMTP id p64mr2353363lfp.200.1505629086666; Sat, 16 Sep 2017 23:18:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.18 with HTTP; Sat, 16 Sep 2017 23:18:06 -0700 (PDT) From: Russell Haley Date: Sat, 16 Sep 2017 23:18:06 -0700 Message-ID: Subject: Unexpected Results from nuttcp testing wifi on arm To: freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 06:18:10 -0000 Hi, Well I WAS going to bed and then I looked at the results of my testing for the BBB/wifi stuff. This is NOT on a BBB and I have a different wifi adapter so I started a new post. When testing wifi on my imx6 (hummingboard) I get drastically different results depending on which side is the client or the server. Host =3D amd64 TrueOS wired 100Mbps Target =3D imx6 FBSD 12 wifi (MAC/BBP RT3572 ) amd64 (wired) client -> imx6 Server russellh@prescott:~% nuttcp -n 1000 -v -i1 192.168.2.62 > /tmp/prescott1.ou= t http://termbin.com/7o1w #Summary: nuttcp-t: 62.5000 MB in 60.77 real seconds =3D 1053.13 KB/sec =3D 8.6273 Mb= ps ----------------------------------------------------------- imx6 client -> amd64 (wired) Server root@imx6:~ # nuttcp -i 1 -v -n 1000 prescott > /tmp/out.txt http://termbin.com/8vvh #Summary: nuttcp-t: 9.0000 MB in 108.96 real seconds =3D 84.58 KB/sec =3D 0.6929 Mbps Is this abnormal? (Please say yes!) Russ (more setup details below) IMX6 test setup: root@imx6:~ # uname -a FreeBSD imx6 12.0-CURRENT FreeBSD 12.0-CURRENT #13 r321601M: Thu Sep 14 20:43:21 PDT 2017 russellh@prescott.highfell.local:/usr/home/russellh/FreeBSD/rh-armv6/obj/ar= m.armv6/usr/home/russellh/FreeBSD/rh-armv6/src/sys/IMX6 arm root@imx6:~ # dmesg | grep run0 run0 on uhub2 run0: <1.0> on usbus1 run0: MAC/BBP RT3572 (rev 0x0223), RF RT3052 (MIMO 2T2R), address 60:a4:4c:ec:c9:a5 run0: firmware RT3071 ver. 0.33 loaded #root@imx6:~ # ifconfig wlan0 wlan0: flags=3D8843 metric 0 mtu 15= 00 ether 60:a4:4c:ec:c9:a5 hwaddr 60:a4:4c:ec:c9:a5 inet 192.168.2.62 netmask 0xffffff00 broadcast 192.168.2.255 groups: wlan ssid Haleys_DownStairs channel 8 (2447 MHz 11g) bssid ac:9e:17:67:8= 5:90 regdomain FCC country US authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 60 protmode CTS wme roaming MANUAL media: IEEE 802.11 Wireless Ethernet DS/1Mbps mode 11g status: associated nd6 options=3D29 #amd64 test setup: russellh@prescott:~% uname -a FreeBSD prescott.highfell.local 12.0-CURRENT FreeBSD 12.0-CURRENT #66 ac2f0aa3b(trueos-stable)-dirty: Wed Jun 21 01:09:23 UTC 2017 root@gauntlet:/usr/obj/usr/src/sys/GENERIC amd64 russellh@prescott:~% ifconfig re0 re0: flags=3D8843 metric 0 mtu 1500 options=3D8209b ether 0c:54:a5:18:c1:5b hwaddr 0c:54:a5:18:c1:5b inet6 fe80::e54:a5ff:fe18:c15b%re0 prefixlen 64 scopeid 0x1 inet 192.168.2.47 netmask 0xffffff00 broadcast 192.168.2.255 nd6 options=3D23 media: Ethernet autoselect (100baseTX ) status: active ---------- Forwarded message ---------- From: Russell Haley Date: Sat, Sep 16, 2017 at 10:43 PM Subject: Re: Beaglebone Black + FreeBSD + USB WiFi =3D WAP? To: Chris Gordon On Tue, Sep 12, 2017 at 7:00 PM, Chris Gordon wrote: > >> On Sep 6, 2017, at 8:13 PM, Russell Haley wrote: >> >> Argh! I was just in Maryland and we flew home from Dulles!!! I made >> the client push the date forward to last week so I could be home for >> Labour Day. >> >> Have fun! (sob, sob, sob). ;) > > Sorry you missed it. I agree that timing wasn=E2=80=99t great with a hol= iday weekend (for the US at least) on one side and EuroBSDcon very soon aft= erward, but constraints on the availability of the hotel drove the exact da= te. Maybe we can see you in 2019 (we do the conference every other year, o= pposite MeetBSD). > >>>> I used nuttcp for testing the wired connection, so I would plan to use= that for the Wifi. >> >> nuttcp. Got it, I'll start playing with it. > > For the testing described in my original email and the data below, I used= the most basic options from https://fasterdata.es.net/performance-testing/= network-troubleshooting-tools/nuttcp/. Specifically: > > Server: > nuttcp -S > > Client: > nuttcp -i1 server_hostname > and > nuttcp -i1 -r server_hostname > nuttcp client only runs for a maybe 10 requests (it varies) and then stops? root@imx6:~ # nuttcp -i1 -r prescott 0.9375 MB / 1.01 sec =3D 7.8054 Mbps 1.0000 MB / 0.99 sec =3D 8.4466 Mbps 0.9375 MB / 1.00 sec =3D 7.8644 Mbps 0.9375 MB / 1.00 sec =3D 7.8643 Mbps 0.9375 MB / 1.05 sec =3D 7.4824 Mbps 0.9375 MB / 0.95 sec =3D 8.2873 Mbps 0.9375 MB / 1.00 sec =3D 7.8643 Mbps 1.0625 MB / 1.00 sec =3D 8.9129 Mbps 0.9375 MB / 1.00 sec =3D 7.8640 Mbps 0.8750 MB / 1.00 sec =3D 7.3403 Mbps 9.6159 MB / 10.19 sec =3D 7.9151 Mbps 0 %TX 2 %RX 0 host-retrans 2.19 msRTT This is true with both my host (amd64 TrueOS/FBSD 12-Current) and my humingboard (imx6 12-current). I tried to force it with -n 1000 and got maybe 20 requests. Verbose didn't tell me anything about why it stopped. I also can't connect to wpa_cli? Error: % wpa_cli wpa_cli v2.5 Copyright (c) 2004-2015, Jouni Malinen and contributors This software may be distributed under the terms of the BSD license. See README for more details. Interactive mode Could not connect to wpa_supplicant: (nil) - re-trying ^c The interweb says on Linux I need to adjust my wpa_supplicant.conf so I will try that. I'm having trouble sifting all the emails so I apologise if you've already answered this. Have you done a tcpdump capture of the system and checked if there is anything telling in the transmissions? If I remember correctly you can roll the file output to make it digestible. I've used sshfs once on Linux to transfer to a host computer that had more storage (perhaps over serial would reduce test-effect on the unit?), but sd cards are nice and big now. Night, Russ >>>> - Can you run the bbb as a standard device (not an access point) and >>>> test the performance of the wlan0 interface using the method of >>>> measurement pointed above? I will do the same at some point with my >>>> wi-fi dongle. >>> >>> Yes, that should be easy to do, but will be next week before I have a c= hance. > > I did the above -- setup the BBB as a simple WiFi client to my existing (= ancient) access point. I ran nuttcp between the BBB and my desktop (wired = network, access point connected to same wired network). Both the BBBB and = desktop were run as server and client for nuttcp. Many runs of the various= combinations were run. I saw the following: > - In general between 10 and 20 Mbps, typically on the lower side. This i= s consistent for what I see for other devices going to my access point (aga= in, it=E2=80=99s an old access point, circa 2008, so I don=E2=80=99t expect= too much from it) > - I did have one period of slow traffic, 1 Mbps and lower. After a few = runs of this, I did a =E2=80=9Cservice netif restart=E2=80=9D, dealt with p= ets for a couple of minutes and when I returned performance was back. > - I just hit another period of slow traffic, but this is around 2.5 Mbps = instead of the really bad < 1 Mbps. Instead of resetting the network, I=E2= =80=99m going to let the BBB sit until morning and test again then. I did= test my iPad with a speed test app and it=E2=80=99s getting a little more = than 10 Mbps to the internet through the same access point that the BBB is = using. > > I=E2=80=99ll follow up with what I see in the morning. My theories at t= his time (neither very good) are: > > - There is a lot of wifi congestion around me and when others are heavily= using their wifi, I suffer. This is exacerbated by something about the us= b wifi NIC I have in the BBB. This doesn=E2=80=99t impact the iPad or othe= r devices due to differences in antennae or some other aspect of their devi= ces. This idea doesn=E2=80=99t quite fit with everything, but a guess. > - There is something in kernel or wireless stack that degrades over time/= amount of traffic passed that ends up limiting performance. > > Thanks, > Chris > From owner-freebsd-arm@freebsd.org Sun Sep 17 08:09:09 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 198C5E02AB2 for ; Sun, 17 Sep 2017 08:09:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D46BE7682C for ; Sun, 17 Sep 2017 08:09:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13868 invoked from network); 17 Sep 2017 08:09:06 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 17 Sep 2017 08:09:06 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 17 Sep 2017 04:09:06 -0400 (EDT) Received: (qmail 15000 invoked from network); 17 Sep 2017 08:09:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Sep 2017 08:09:06 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id C9638EC86EE for ; Sun, 17 Sep 2017 01:09:05 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Part of why Pine64+ 2GB gets "uhub_attach: getting USB 2.0 HUB descriptor failed,error=USB_ERR_SHORT_XFER" (and so USB fails) Message-Id: Date: Sun, 17 Sep 2017 01:09:05 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 08:09:09 -0000 For booting a Pine64+ 2GB it reports: usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on = usbus0 uhub_attach: getting USB 2.0 HUB descriptor = failed,error=3DUSB_ERR_SHORT_XFER device_attach: uhub0 attach returned 6 usbus0: Root HUB problem, error=3DUSB_ERR_NO_ROOT_HUB /usr/src/sys/dev/usb/usb_hub.c has: . . . switch (udev->speed) { case USB_SPEED_LOW: case USB_SPEED_FULL: case USB_SPEED_HIGH: /* assuming that there is one port */ err =3D usbd_req_get_hub_descriptor(udev, NULL, = &hubdesc20, 1); if (err) { DPRINTFN(0, "getting USB 2.0 HUB descriptor = failed," "error=3D%s\n", usbd_errstr(err)); goto error; } /* get number of ports */ nports =3D hubdesc20.bNbrPorts; . . . (The 1 in usbd_req_get_hub_descriptor(udev, NULL, &hubdesc20, 1) being the assumed "one port".) where /usr/src/sys/dev/usb/usb_request.c 's usbd_req_get_hub_descriptor is: usb_error_t usbd_req_get_hub_descriptor(struct usb_device *udev, struct mtx *mtx, struct usb_hub_descriptor *hd, uint8_t nports) { struct usb_device_request req; uint16_t len =3D (nports + 7 + (8 * 8)) / 8; req.bmRequestType =3D UT_READ_CLASS_DEVICE; req.bRequest =3D UR_GET_DESCRIPTOR; USETW2(req.wValue, UDESC_HUB, 0); USETW(req.wIndex, 0); USETW(req.wLength, len); return (usbd_do_request(udev, mtx, &req, hd)); } Note that len =3D=3D (1 + 7 + (8 * 8)) / 8 i.e., len =3D=3D 9. which eventually gets to /usr/src/sys/dev/usb/controller/ohci.c 's ohci_roothub_exec : . . . ohci_softc_t *sc =3D OHCI_BUS2SC(udev->bus); . . . #define C(x,y) ((x) | ((y) << 8)) . . . case C(UR_GET_DESCRIPTOR, UT_READ_CLASS_DEVICE): if ((value & 0xff) !=3D 0) { err =3D USB_ERR_IOERROR; goto done; } v =3D OREAD4(sc, OHCI_RH_DESCRIPTOR_A); sc->sc_hub_desc.hubd =3D ohci_hubd; sc->sc_hub_desc.hubd.bNbrPorts =3D sc->sc_noport; USETW(sc->sc_hub_desc.hubd.wHubCharacteristics, (v & OHCI_NPS ? UHD_PWR_NO_SWITCH : v & OHCI_PSM ? UHD_PWR_GANGED : UHD_PWR_INDIVIDUAL) /* XXX overcurrent */ ); sc->sc_hub_desc.hubd.bPwrOn2PwrGood =3D = OHCI_GET_POTPGT(v); v =3D OREAD4(sc, OHCI_RH_DESCRIPTOR_B); for (l =3D 0; l < sc->sc_noport; l++) { if (v & 1) { sc->sc_hub_desc.hubd.DeviceRemovable[l / = 8] |=3D (1 << (l % 8)); } v >>=3D 1; } sc->sc_hub_desc.hubd.bDescLength =3D 8 + ((sc->sc_noport + 7) / 8); len =3D sc->sc_hub_desc.hubd.bDescLength; break; . . . done: *plength =3D len; *pptr =3D ptr; return (err); } Note that sc->sc_noport !=3D 1 is possible but 8 + ((1 + 7) / 8) =3D=3D 9 and so sc->sc_noport=3D=3D1 would match. In the middle between is usbd_do_request which is a macro for usbd_do_request_flags with 4 specific final arguments. The code that gets to ohci_roothub_exec is: . . . uint16_t length; uint16_t temp; . . . length =3D UGETW(req->wLength); . . . USB_BUS_LOCK(udev->bus); err =3D (hr_func) (udev, req, &desc, &temp); USB_BUS_UNLOCK(udev->bus); if (err) goto done; if (length > temp) { if (!(flags & USB_SHORT_XFER_OK)) { err =3D USB_ERR_SHORT_XFER; goto done; } length =3D temp; } =20 which is where the USB_ERR_SHORT_XFER comes from as far as I can tell. length > temp then means that: 9 > 8 + ((sc->sc_noport + 7) / 8) which means that sc->sc_noport=3D=3D0 . As for what ofwdump reports relative to usb, first the overall node list: # ofwdump -a Node 0x48:=20 Node 0xe8: memory Node 0x120: cpus Node 0x14c: cpu@0 Node 0x1b8: cpu@1 Node 0x224: cpu@2 Node 0x290: cpu@3 Node 0x300: osc24M_clk Node 0x380: osc32k_clk Node 0x400: internal-osc-clk Node 0x498: psci Node 0x4d4: timer Node 0x53c: soc Node 0x588: mmc@1c0f000 Node 0x700: mmc@1c10000 Node 0x804: mmc@1c11000 Node 0x908: usb@01c19000 Node 0xa0c: phy@01c19400 Node 0xb54: usb@01c1b000 Node 0xc44: usb@01c1b400 Node 0xd24: clock@01c20000 Node 0xde4: pinctrl@1c20800 Node 0xed4: i2c1_pins Node 0xf3c: mmc0-pins Node 0xfc4: mmc1-pins Node 0x102c: mmc2-pins Node 0x10b4: uart0@0 Node 0x110c: uart1_pins Node 0x1148: uart1_rts_cts_pins Node 0x118c: rmii_pins Node 0x1214: rgmii_pins Node 0x12d8: serial@1c28000 Node 0x13bc: serial@1c28400 Node 0x1480: serial@1c28800 Node 0x1544: serial@1c28c00 Node 0x1608: serial@1c29000 Node 0x16cc: i2c@1c2ac00 Node 0x1790: i2c@1c2b000 Node 0x1874: i2c@1c2b400 Node 0x1938: interrupt-controller@1c81000 Node 0x19f8: rtc@1f00000 Node 0x1a68: clock@1f01400 Node 0x1b30: pinctrl@01f02c00 Node 0x1c14: ethernet@01c30000 Node 0x1d78: ethernet-phy@1 Node 0x1dc8: aliases Node 0x1e1c: chosen Node 0x1e8c: vcc3v3 Note: Later lines starting with "( " and ending with " )" are my hand translation to text when multiple '\0' bytes were present, with a space for each separating '\0' byte. Now the usb specific nodes: # ofwdump -p /soc/usb@01c19000 Node 0x908: usb@01c19000 compatible: 61 6c 6c 77 69 6e 6e 65 72 2c 73 75 6e 38 69 2d 61 33 33 2d=20 6d 75 73 62 00=20 'allwinner,sun8i-a33-musb' reg: 01 c1 90 00 00 00 04 00=20 clocks: 00 00 00 02 00 00 00 29=20 resets: 00 00 00 02 00 00 00 12=20 interrupts: 00 00 00 00 00 00 00 47 00 00 00 04=20 interrupt-names: 6d 63 00=20 'mc' phys: 00 00 00 06 00 00 00 00=20 phy-names: 75 73 62 00=20 'usb' extcon: 00 00 00 06 00 00 00 00=20 status: 6f 6b 61 79 00=20 'okay' dr_mode: 68 6f 73 74 00=20 'host' # ofwdump -p /soc/phy@01c19400 Node 0xa0c: phy@01c19400 compatible: 61 6c 6c 77 69 6e 6e 65 72 2c 73 75 6e 35 30 69 2d 61 36 34=20 2d 75 73 62 2d 70 68 79 00=20 'allwinner,sun50i-a64-usb-phy' reg: 01 c1 94 00 00 00 00 14 01 c1 a8 00 00 00 00 04 01 c1 b8 00=20 00 00 00 04=20 reg-names: 70 68 79 5f 63 74 72 6c 00 70 6d 75 30 00 70 6d 75 31 00=20 ( phy_ctrl pmu0 pmu1 ) clocks: 00 00 00 02 00 00 00 56 00 00 00 02 00 00 00 57=20 clock-names: 75 73 62 30 5f 70 68 79 00 75 73 62 31 5f 70 68 79 00=20 ( usb0_phy usb1_phy ) resets: 00 00 00 02 00 00 00 00 00 00 00 02 00 00 00 01=20 reset-names: 75 73 62 30 5f 72 65 73 65 74 00 75 73 62 31 5f 72 65 73 65=20 74 00=20 ( usb0_reset usb1_reset ) status: 6f 6b 61 79 00=20 'okay' #phy-cells: 00 00 00 01=20 linux,phandle: 00 00 00 06=20 phandle: 00 00 00 06 # ofwdump -p /soc/usb@01c1b000 Node 0xb54: usb@01c1b000 compatible: 61 6c 6c 77 69 6e 6e 65 72 2c 73 75 6e 35 30 69 2d 61 36 34=20 2d 65 68 63 69 00 67 65 6e 65 72 69 63 2d 65 68 63 69 00=20 ( allwinner,sun50i-a64-ehci generic-ehci ) reg: 01 c1 b0 00 00 00 01 00=20 interrupts: 00 00 00 00 00 00 00 4a 00 00 00 04=20 clocks: 00 00 00 02 00 00 00 2d 00 00 00 02 00 00 00 2b 00 00 00 02=20 00 00 00 5d=20 resets: 00 00 00 02 00 00 00 16 00 00 00 02 00 00 00 14=20 phys: 00 00 00 06 00 00 00 01=20 phy-names: 75 73 62 00=20 'usb' status: 6f 6b 61 79 00=20 'okay' # ofwdump -p /soc/usb@01c1b400 Node 0xc44: usb@01c1b400 compatible: 61 6c 6c 77 69 6e 6e 65 72 2c 73 75 6e 35 30 69 2d 61 36 34=20 2d 6f 68 63 69 00 67 65 6e 65 72 69 63 2d 6f 68 63 69 00=20 ( allwinner,sun50i-a64-ohci generic-ohci ) reg: 01 c1 b4 00 00 00 01 00=20 interrupts: 00 00 00 00 00 00 00 4b 00 00 00 04=20 clocks: 00 00 00 02 00 00 00 2d 00 00 00 02 00 00 00 5d=20 resets: 00 00 00 02 00 00 00 16=20 phys: 00 00 00 06 00 00 00 01=20 phy-names: 75 73 62 00=20 'usb' status: 6f 6b 61 79 00=20 'okay' (Not that I know what to make of it or if it matches what is expected/required by FreeBSD.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Sep 17 08:59:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54E7DE048C1 for ; Sun, 17 Sep 2017 08:59:06 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A83777BDC for ; Sun, 17 Sep 2017 08:59:05 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 077582606E1; Sun, 17 Sep 2017 10:58:56 +0200 (CEST) Subject: Re: Part of why Pine64+ 2GB gets "uhub_attach: getting USB 2.0 HUB descriptor failed,error=USB_ERR_SHORT_XFER" (and so USB fails) To: Mark Millard , freebsd-arm References: From: Hans Petter Selasky Message-ID: <46d91194-84ff-50e3-97e6-6f9cef3ea2e7@selasky.org> Date: Sun, 17 Sep 2017 10:56:27 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 08:59:06 -0000 On 09/17/17 10:09, Mark Millard wrote: > . . . > uint16_t length; > uint16_t temp; > . . . > length = UGETW(req->wLength); > . . . > USB_BUS_LOCK(udev->bus); > err = (hr_func) (udev, req, &desc, &temp); > USB_BUS_UNLOCK(udev->bus); > > if (err) > goto done; > > if (length > temp) { > if (!(flags & USB_SHORT_XFER_OK)) { > err = USB_ERR_SHORT_XFER; > goto done; > } > length = temp; > } Can you dump the length arguments. Usually short transfer means that the descriptor was shorter than expected. --HPS From owner-freebsd-arm@freebsd.org Sun Sep 17 12:31:08 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97829E0ED1E for ; Sun, 17 Sep 2017 12:31:08 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A75A81BBD for ; Sun, 17 Sep 2017 12:31:07 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 836d9677; Sun, 17 Sep 2017 14:30:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; s=mail; bh=hufkPn sIRymFoghunWEexHImt4Q=; b=WZ+GgFAU3donmWXp5IIGWZzmwCBEtwlzWlfsac uRCezIrD3iA4zGmI6lyN+sqeq9y2VSqg4Leyw/Zmo3pcB5Z/VI+fog6sToXvpgTQ KCxpNtNRhyBYqrYyUFs0d8zRM1j4WcDwDm0S5BkPsUi3cZrV+RFxck11em7J1SjY CoTuo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; q=dns; s=mail; b= f4R8qRuiat6rm2mh/cCRgBi4AUyHIKZyrTTgCVbD7BIHp3p8Jtdbv95697in33u2 DMoiQ5q6qeh8uO/frgbsqkmlIXuv8pYmpm9XAqsrVZmCax1WaTLu0wLZMLOSnVK2 VTOS8xf6Sp+L4175hdTnIwr5HWi4emKxYFKLG0Q0hAI= Received: from webmail.megadrive.org (www1.blih.net [212.83.177.180]) by mail.blih.net (OpenSMTPD) with ESMTP id f87be862; Sun, 17 Sep 2017 14:30:56 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 17 Sep 2017 14:30:56 +0200 From: Emmanuel Vadot To: Mark Millard Cc: freebsd-arm Subject: Re: Part of why Pine64+ 2GB gets "uhub_attach: getting USB 2.0 HUB descriptor failed,error=USB_ERR_SHORT_XFER" (and so USB fails) Organization: Bidouilliste In-Reply-To: References: Message-ID: X-Sender: manu@bidouilliste.com User-Agent: Roundcube Webmail/1.1.1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 12:31:08 -0000 On 2017-09-17 10:09, Mark Millard wrote: > For booting a Pine64+ 2GB it reports: > > usbus0: 12Mbps Full Speed USB v1.0 > ugen0.1: at usbus0 > uhub0: on > usbus0 > uhub_attach: getting USB 2.0 HUB descriptor > failed,error=USB_ERR_SHORT_XFER > device_attach: uhub0 attach returned 6 > usbus0: Root HUB problem, error=USB_ERR_NO_ROOT_HUB Did you test latest head ? I've fixed OHCI, see commit messages for more information. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sun Sep 17 18:50:54 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52E10E245F8 for ; Sun, 17 Sep 2017 18:50:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0FCF1696E5 for ; Sun, 17 Sep 2017 18:50:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 304 invoked from network); 17 Sep 2017 18:50:50 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Sep 2017 18:50:50 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 17 Sep 2017 14:50:50 -0400 (EDT) Received: (qmail 14709 invoked from network); 17 Sep 2017 18:50:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Sep 2017 18:50:50 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id BCE7AEC8804; Sun, 17 Sep 2017 11:50:49 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r323641 - head/sys/arm/allwinner (BananapiM3 [an A83T] and USB: BPI-M3 historically had usb nodes listed in ofwdump -a) Message-Id: Date: Sun, 17 Sep 2017 11:50:49 -0700 To: Emmanuel Vadot , svn-src-head@freebsd.org, freebsd-arm X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 18:50:54 -0000 > Author: manu > Date: Sat Sep 16 15:58:20 2017 > New Revision: 323641 > URL:=20 > https://svnweb.freebsd.org/changeset/base/323641 >=20 >=20 > Log: > Allwinner usb phy: Rework resource allocation > =20 > . . . > =20 > While here remove A83T code as upstream and FreeBSD dts don't have > nodes for USB. > =20 > . . . > =20 > EHCI is still buggy on Pine64 (hang the board) so do not enable it = for now. > =20 > Tested On: Bananapi (A20), BananapiM2 (A31S), OrangePi One (H3) = Pine64 (A64) I have a BPI-M3 (A83T based) that has not been updated since head -r317015M. It has the root file system on a USB SSD for how I normally boot it. The ubldr and ubldr.bin go back to 2016-Oct-24 or before (file system date). sysutils/u-boot-sinovoip-bpi-m3/files/ has not been updated since then. Nor has the distinfo or pkg-descr files. The Makefile has had only one change since then: Revision 430454 - (view) (download) (annotate) - [select for diffs]=20 Modified Tue Jan 3 11:01:05 2017 UTC (8 months, 1 week ago) by mat=20 File length: 1369 byte(s)=20 Diff to previous 419007 Cleanup BROKEN/IGNORE for 10.3- Sponsored by: Absolight The BPI-M3 has usb nodes show in ofwdump. . . # uname -apKU FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r317015M arm armv6 = 1200028 1200028 ofwdump -a shows usb nodes: Node 0x38:=20 . . . Node 0x19e0: soc . . . Node 0x1e80: pinctrl@01c20800 . . . Node 0x21f0: usb0_vbus_pin@0 Node 0x2270: usb1_vbus_pin@0 Node 0x22f4: usb2_vbus_pin@0 . . . Node 0x32ec: phy@01c19400 Node 0x3458: usb@01c1a000 Node 0x3550: usb@01c1b000 . . . Node 0x39fc: usb0-vbus Node 0x3ae8: usb1-vbus Node 0x3bdc: usb2-vbus More fully (followed by usb specific ofwdump -p listings): # ofwdump -a Node 0x38:=20 Node 0xcc: chosen Node 0x108: aliases Node 0x13c: memory Node 0x174: cpus Node 0x1a0: cpu@0 Node 0x248: cpu@1 Node 0x294: cpu@2 Node 0x2e0: cpu@3 Node 0x32c: cpu@100 Node 0x3d4: cpu@101 Node 0x420: cpu@102 Node 0x46c: cpu@103 Node 0x4bc: timer Node 0x524: clocks Node 0x55c: osc24M_clk Node 0x5dc: osc16M_clk Node 0x65c: osc16Md512_clk Node 0x70c: clk@01c20028 Node 0x7b8: pll6d2_clk Node 0x860: clk@01c20054 Node 0x918: apb1_clk@01c20054 Node 0x9c8: clk@01c20058 Node 0xa80: clk@01c2005c Node 0xb2c: clk@01c20060 Node 0xe18: clk@01c20088 Node 0xedc: clk@01c2008c Node 0xfa0: clk@01c20090 Node 0x1064: clk@01f01400 Node 0x111c: ahb0_clk Node 0x11c4: clk@01f0140c Node 0x1270: clk@01f01428 Node 0x1384: clk@01c20000 Node 0x1438: clk@01c20004 Node 0x14ec: c0clk@01c20050 Node 0x159c: c1clk@01c20050 Node 0x164c: clk@01c20044 Node 0x16fc: clk@01c200cc Node 0x180c: clk@1 Node 0x188c: clk@2 Node 0x190c: clk@01c00030 Node 0x19e0: soc Node 0x1a2c: mmc@01c0f000 Node 0x1bcc: mmc@01c10000 Node 0x1d00: mmc@01c11000 Node 0x1e80: pinctrl@01c20800 Node 0x1f74: mmc0@0 Node 0x1ffc: mmc0_cd_pin@0 Node 0x2078: uart0@0 Node 0x20f0: uart0@1 Node 0x216c: ahci_pwr_pin@0 Node 0x21f0: usb0_vbus_pin@0 Node 0x2270: usb1_vbus_pin@0 Node 0x22f4: usb2_vbus_pin@0 Node 0x2374: mmc2_8bit Node 0x241c: emac_rgmii@0 Node 0x24e0: i2c0@0 Node 0x2558: i2c1@0 Node 0x25d0: i2c2@0 Node 0x264c: reset@01c202c0 Node 0x26d4: reset@01c202d0 Node 0x275c: reset@01c202d8 Node 0x27e4: timer@01c20c00 Node 0x286c: watchdog@01c20ca0 Node 0x28e8: serial@01c28000 Node 0x29ec: interrupt-controller@01c81000 Node 0x2ac8: reset@01f014b0 Node 0x2b50: pinctrl@01f02c00 Node 0x2c40: r_rsb Node 0x2cbc: i2c@01f03400 Node 0x2dd0: pmic@3a3 Node 0x2e6c: regulators Node 0x2e7c: dcdc2 Node 0x2ec0: dcdc3 Node 0x2f10: interrupt-controller@01f00c0c Node 0x2fc8: i2c@01c2ac00 Node 0x30d4: i2c@01c2b000 Node 0x31e0: i2c@01c2b400 Node 0x32ec: phy@01c19400 Node 0x3458: usb@01c1a000 Node 0x3550: usb@01c1b000 Node 0x3648: ethernet@01c30000 Node 0x37b4: ethernet-phy@1 Node 0x3800: eeprom@01c14000 Node 0x3874: rtp@01f04000 Node 0x3910: ahci-5v Node 0x39fc: usb0-vbus Node 0x3ae8: usb1-vbus Node 0x3bdc: usb2-vbus Node 0x3cd4: vcc3v0 Node 0x3d54: vcc3v3 Node 0x3dd4: vcc5v0 Node 0x3e54: pmu Node 0x3ed0: leds Node 0x3ef4: green_led Node 0x3f34: blue_led Node 0x3f78: __symbols__ # ofwdump -p /soc/pinctrl@01c20800/usb0_vbus_pin@0 Node 0x21f0: usb0_vbus_pin@0 allwinner,pins: 50 42 39 00=20 'PB9' allwinner,function: 67 70 69 6f 5f 6f 75 74 00=20 'gpio_out' allwinner,drive: 00 00 00 00=20 allwinner,pull: 00 00 00 00=20 linux,phandle: 00 00 00 32=20 phandle: 00 00 00 32=20 # ofwdump -p /soc/pinctrl@01c20800/usb1_vbus_pin@0 Node 0x2270: usb1_vbus_pin@0 allwinner,pins: 50 44 32 34 00=20 'PD24' allwinner,function: 67 70 69 6f 5f 6f 75 74 00=20 'gpio_out' allwinner,drive: 00 00 00 00=20 allwinner,pull: 00 00 00 00=20 linux,phandle: 00 00 00 33=20 phandle: 00 00 00 33=20 # ofwdump -p /soc/pinctrl@01c20800/usb2_vbus_pin@0 Node 0x22f4: usb2_vbus_pin@0 allwinner,pins: 50 48 33 00=20 'PH3' allwinner,function: 67 70 69 6f 5f 6f 75 74 00=20 'gpio_out' allwinner,drive: 00 00 00 00=20 allwinner,pull: 00 00 00 00=20 linux,phandle: 00 00 00 34=20 phandle: 00 00 00 34=20 # ofwdump -p /soc/phy@01c19400 Node 0x32ec: phy@01c19400 compatible: 61 6c 6c 77 69 6e 6e 65 72 2c 73 75 6e 38 69 2d 61 38 33 74=20 2d 75 73 62 2d 70 68 79 00=20 'allwinner,sun8i-a83t-usb-phy' reg: 01 c1 94 00 00 00 00 2c 01 c1 a8 00 00 00 00 04 01 c1 b8 00=20 00 00 00 04=20 clocks: 00 00 00 2b 00 00 00 08 00 00 00 2b 00 00 00 09 00 00 00 2b=20 00 00 00 0a 00 00 00 2b 00 00 00 0b=20 clock-names: 75 73 62 30 5f 70 68 79 00 75 73 62 31 5f 70 68 79 00 68 73=20 69 63 5f 70 6c 6c 00 68 73 69 63 5f 31 32 6d 00=20 resets: 00 00 00 2b 00 00 00 00 00 00 00 2b 00 00 00 01 00 00 00 2b=20 00 00 00 02=20 reset-names: 75 73 62 30 5f 72 65 73 65 74 00 75 73 62 31 5f 72 65 73 65=20 74 00 75 73 62 32 5f 72 65 73 65 74 00=20 status: 6f 6b 61 79 00=20 'okay' #phy-cells: 00 00 00 01=20 usb1_vbus-supply: 00 00 00 2c=20 linux,phandle: 00 00 00 2d=20 phandle: 00 00 00 2d=20 # ofwdump -p /soc/usb@01c1a000 Node 0x3458: usb@01c1a000 compatible: 61 6c 6c 77 69 6e 6e 65 72 2c 73 75 6e 38 69 2d 61 38 33 74=20 2d 65 68 63 69 00 67 65 6e 65 72 69 63 2d 65 68 63 69 00=20 reg: 01 c1 a0 00 00 00 01 00=20 interrupts: 00 00 00 00 00 00 00 48 00 00 00 04=20 clocks: 00 00 00 17 00 00 00 1a=20 resets: 00 00 00 19 00 00 00 1a=20 phys: 00 00 00 2d 00 00 00 01=20 phy-names: 75 73 62 00=20 'usb' status: 6f 6b 61 79 00=20 'okay' linux,phandle: 00 00 00 41=20 phandle: 00 00 00 41=20 # ofwdump -p /soc/usb@01c1b000 Node 0x3550: usb@01c1b000 compatible: 61 6c 6c 77 69 6e 6e 65 72 2c 73 75 6e 38 69 2d 61 38 33 74=20 2d 65 68 63 69 00 67 65 6e 65 72 69 63 2d 65 68 63 69 00=20 reg: 01 c1 b0 00 00 00 01 00=20 interrupts: 00 00 00 00 00 00 00 4a 00 00 00 04=20 clocks: 00 00 00 17 00 00 00 1b=20 resets: 00 00 00 19 00 00 00 1b=20 phys: 00 00 00 2d 00 00 00 02=20 phy-names: 75 73 62 00=20 'usb' status: 6f 6b 61 79 00=20 'okay' linux,phandle: 00 00 00 42=20 phandle: 00 00 00 42=20 # ofwdump -p /usb0-vbus Node 0x39fc: usb0-vbus compatible: 72 65 67 75 6c 61 74 6f 72 2d 66 69 78 65 64 00=20 'regulator-fixed' pinctrl-names: 64 65 66 61 75 6c 74 00=20 'default' pinctrl-0: 00 00 00 32=20 regulator-name: 75 73 62 30 2d 76 62 75 73 00=20 'usb0-vbus' regulator-min-microvolt: 00 4c 4b 40=20 regulator-max-microvolt: 00 4c 4b 40=20 enable-active-high: gpio: 00 00 00 1d 00 00 00 01 00 00 00 09 00 00 00 00=20 status: 64 69 73 61 62 6c 65 64 00=20 'disabled' linux,phandle: 00 00 00 47=20 phandle: 00 00 00 47=20 # ofwdump -p /usb1-vbus Node 0x3ae8: usb1-vbus compatible: 72 65 67 75 6c 61 74 6f 72 2d 66 69 78 65 64 00=20 'regulator-fixed' pinctrl-names: 64 65 66 61 75 6c 74 00=20 'default' pinctrl-0: 00 00 00 33=20 regulator-name: 75 73 62 31 2d 76 62 75 73 00=20 'usb1-vbus' regulator-min-microvolt: 00 4c 4b 40=20 regulator-max-microvolt: 00 4c 4b 40=20 regulator-boot-on: enable-active-high: gpio: 00 00 00 1d 00 00 00 03 00 00 00 18 00 00 00 00=20 status: 6f 6b 61 79 00=20 'okay' linux,phandle: 00 00 00 2c=20 phandle: 00 00 00 2c=20 # ofwdump -p /usb2-vbus Node 0x3bdc: usb2-vbus compatible: 72 65 67 75 6c 61 74 6f 72 2d 66 69 78 65 64 00=20 'regulator-fixed' pinctrl-names: 64 65 66 61 75 6c 74 00=20 'default' pinctrl-0: 00 00 00 34=20 regulator-name: 75 73 62 32 2d 76 62 75 73 00=20 'usb2-vbus' regulator-min-microvolt: 00 4c 4b 40=20 regulator-max-microvolt: 00 4c 4b 40=20 regulator-boot-on: enable-active-high: gpio: 00 00 00 1d 00 00 00 07 00 00 00 03 00 00 00 00=20 status: 64 69 73 61 62 6c 65 64 00=20 'disabled' linux,phandle: 00 00 00 48=20 phandle: 00 00 00 48=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Sep 17 19:29:07 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1920E26534; Sun, 17 Sep 2017 19:29:07 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 189C26A8B3; Sun, 17 Sep 2017 19:29:06 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 4de6ae09; Sun, 17 Sep 2017 21:29:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=yflQhIe3mjzc9q+emDNJVW3cZH8=; b=VbkePRBTYKK6X1IMYf4fTHl/2VOl HNwAMyxOc1muZcPtBd2N+C4eiob+5eq1jXKaGBw2sBCJLPLS/Wle1MW7flJsZvfp JBEkurL7nZgmeTkJpnzWFJsRKP0X2kkRwp8RZRoA791WSmIIfMJ2GyH+qa2oU+3E om2IV5E6b46/mco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=pk+NAiQZeqQEi/k2+B888JG+yg0Rs5KuvZNkjLYyc9bZZ2R6SHUBJwz1 vJVzHhDVchSJUp1aJ32D65RPKcWmse8C/kDVA7f4LxsGsJJocgPDkm+MkC6SS2Hz Z0qX+Sb5v6wKgkAbFFbMJ+XWlA2A+cNm3f+kzgPQugAkS2r+umI= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 6ddc91d9 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sun, 17 Sep 2017 21:29:03 +0200 (CEST) Date: Sun, 17 Sep 2017 21:28:58 +0200 From: Emmanuel Vadot To: Mark Millard Cc: Emmanuel Vadot , svn-src-head@freebsd.org, freebsd-arm Subject: Re: svn commit: r323641 - head/sys/arm/allwinner (BananapiM3 [an A83T] and USB: BPI-M3 historically had usb nodes listed in ofwdump -a) Message-Id: <20170917212858.58fda5174908940ff1ffcc49@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 19:29:07 -0000 On Sun, 17 Sep 2017 11:50:49 -0700 Mark Millard wrote: > > Author: manu > > Date: Sat Sep 16 15:58:20 2017 > > New Revision: 323641 > > URL: > > https://svnweb.freebsd.org/changeset/base/323641 > > > > > > Log: > > Allwinner usb phy: Rework resource allocation > > > > . . . > > > > While here remove A83T code as upstream and FreeBSD dts don't have > > nodes for USB. > > > > . . . > > > > EHCI is still buggy on Pine64 (hang the board) so do not enable it for now. > > > > Tested On: Bananapi (A20), BananapiM2 (A31S), OrangePi One (H3) Pine64 (A64) > > I have a BPI-M3 (A83T based) that has not been updated > since head -r317015M. It has the root file system on a > USB SSD for how I normally boot it. The ubldr and > ubldr.bin go back to 2016-Oct-24 or before (file > system date). > > sysutils/u-boot-sinovoip-bpi-m3/files/ has not > been updated since then. Nor has the distinfo > or pkg-descr files. The Makefile has had only > one change since then: > > Revision 430454 - (view) (download) (annotate) - [select for diffs] > Modified Tue Jan 3 11:01:05 2017 UTC (8 months, 1 week ago) by mat > File length: 1369 byte(s) > Diff to previous 419007 > Cleanup BROKEN/IGNORE for 10.3- > > Sponsored by: Absolight I don't have the board so if you want to update u-boot for it please provide a patch. > > The BPI-M3 has usb nodes show in ofwdump. . . > Yeah I miss-read the DTS because 4 of them are used for one board ... I don't want to update the dts in sys/boot/fdt/dts/arm and I will remove them soon. Upstream DTS don't have usb in it but it will be easy to add it. You could send a patch to linux-arm if you want but note that upstream DTS now uses clkng binding (i.e. not all clocks are under /clocks node) so it will require a driver on our side. And please no need to send a 1km long email. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sun Sep 17 19:44:16 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38942E00357 for ; Sun, 17 Sep 2017 19:44:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0B416B3D5 for ; Sun, 17 Sep 2017 19:44:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13181 invoked from network); 17 Sep 2017 19:44:14 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 17 Sep 2017 19:44:14 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 17 Sep 2017 15:44:14 -0400 (EDT) Received: (qmail 13981 invoked from network); 17 Sep 2017 19:44:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Sep 2017 19:44:14 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id ABDA7EC85D5; Sun, 17 Sep 2017 12:44:13 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r323641 - head/sys/arm/allwinner (BananapiM3 [an A83T] and USB: BPI-M3 historically had usb nodes listed in ofwdump -a) Date: Sun, 17 Sep 2017 12:44:13 -0700 References: To: Emmanuel Vadot , svn-src-head@freebsd.org, freebsd-arm In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 19:44:16 -0000 [I went looking in the tree for head -r323676 and found *.dts* files listing usb things for the BPI-M3 and a83t. So I add notes about that.] On 2017-Sep-17, at 11:50 AM, Mark Millard wrote: >> Author: manu >> Date: Sat Sep 16 15:58:20 2017 >> New Revision: 323641 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/323641 >>=20 >>=20 >> Log: >> Allwinner usb phy: Rework resource allocation >>=20 >> . . . >>=20 >> While here remove A83T code as upstream and FreeBSD dts don't have >> nodes for USB. >>=20 >> . . . >>=20 >> EHCI is still buggy on Pine64 (hang the board) so do not enable it = for now. >>=20 >> Tested On: Bananapi (A20), BananapiM2 (A31S), OrangePi One (H3) = Pine64 (A64) >=20 > I have a BPI-M3 (A83T based) that has not been updated > since head -r317015M. It has the root file system on a > USB SSD for how I normally boot it. The ubldr and > ubldr.bin go back to 2016-Oct-24 or before (file > system date). >=20 > sysutils/u-boot-sinovoip-bpi-m3/files/ has not > been updated since then. Nor has the distinfo > or pkg-descr files. The Makefile has had only > one change since then: >=20 > Revision 430454 - (view) (download) (annotate) - [select for diffs]=20 > Modified Tue Jan 3 11:01:05 2017 UTC (8 months, 1 week ago) by mat=20 > File length: 1369 byte(s)=20 > Diff to previous 419007 > Cleanup BROKEN/IGNORE for 10.3- >=20 > Sponsored by: Absolight >=20 >=20 >=20 > The BPI-M3 has usb nodes show in ofwdump. . . >=20 > # uname -apKU > FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r317015M arm armv6 = 1200028 1200028 >=20 > ofwdump -a shows usb nodes: >=20 > Node 0x38:=20 > . . . > Node 0x19e0: soc > . . . > Node 0x1e80: pinctrl@01c20800 > . . . > Node 0x21f0: usb0_vbus_pin@0 > Node 0x2270: usb1_vbus_pin@0 > Node 0x22f4: usb2_vbus_pin@0 > . . . > Node 0x32ec: phy@01c19400 > Node 0x3458: usb@01c1a000 > Node 0x3550: usb@01c1b000 > . . . > Node 0x39fc: usb0-vbus > Node 0x3ae8: usb1-vbus > Node 0x3bdc: usb2-vbus >=20 > More fully (followed by usb specific > ofwdump -p listings): >=20 > # ofwdump -a > Node 0x38:=20 > Node 0xcc: chosen > Node 0x108: aliases > Node 0x13c: memory > Node 0x174: cpus > Node 0x1a0: cpu@0 > Node 0x248: cpu@1 > Node 0x294: cpu@2 > Node 0x2e0: cpu@3 > Node 0x32c: cpu@100 > Node 0x3d4: cpu@101 > Node 0x420: cpu@102 > Node 0x46c: cpu@103 > Node 0x4bc: timer > Node 0x524: clocks > Node 0x55c: osc24M_clk > Node 0x5dc: osc16M_clk > Node 0x65c: osc16Md512_clk > Node 0x70c: clk@01c20028 > Node 0x7b8: pll6d2_clk > Node 0x860: clk@01c20054 > Node 0x918: apb1_clk@01c20054 > Node 0x9c8: clk@01c20058 > Node 0xa80: clk@01c2005c > Node 0xb2c: clk@01c20060 > Node 0xe18: clk@01c20088 > Node 0xedc: clk@01c2008c > Node 0xfa0: clk@01c20090 > Node 0x1064: clk@01f01400 > Node 0x111c: ahb0_clk > Node 0x11c4: clk@01f0140c > Node 0x1270: clk@01f01428 > Node 0x1384: clk@01c20000 > Node 0x1438: clk@01c20004 > Node 0x14ec: c0clk@01c20050 > Node 0x159c: c1clk@01c20050 > Node 0x164c: clk@01c20044 > Node 0x16fc: clk@01c200cc > Node 0x180c: clk@1 > Node 0x188c: clk@2 > Node 0x190c: clk@01c00030 > Node 0x19e0: soc > Node 0x1a2c: mmc@01c0f000 > Node 0x1bcc: mmc@01c10000 > Node 0x1d00: mmc@01c11000 > Node 0x1e80: pinctrl@01c20800 > Node 0x1f74: mmc0@0 > Node 0x1ffc: mmc0_cd_pin@0 > Node 0x2078: uart0@0 > Node 0x20f0: uart0@1 > Node 0x216c: ahci_pwr_pin@0 > Node 0x21f0: usb0_vbus_pin@0 > Node 0x2270: usb1_vbus_pin@0 > Node 0x22f4: usb2_vbus_pin@0 > Node 0x2374: mmc2_8bit > Node 0x241c: emac_rgmii@0 > Node 0x24e0: i2c0@0 > Node 0x2558: i2c1@0 > Node 0x25d0: i2c2@0 > Node 0x264c: reset@01c202c0 > Node 0x26d4: reset@01c202d0 > Node 0x275c: reset@01c202d8 > Node 0x27e4: timer@01c20c00 > Node 0x286c: watchdog@01c20ca0 > Node 0x28e8: serial@01c28000 > Node 0x29ec: interrupt-controller@01c81000 > Node 0x2ac8: reset@01f014b0 > Node 0x2b50: pinctrl@01f02c00 > Node 0x2c40: r_rsb > Node 0x2cbc: i2c@01f03400 > Node 0x2dd0: pmic@3a3 > Node 0x2e6c: regulators > Node 0x2e7c: dcdc2 > Node 0x2ec0: dcdc3 > Node 0x2f10: interrupt-controller@01f00c0c > Node 0x2fc8: i2c@01c2ac00 > Node 0x30d4: i2c@01c2b000 > Node 0x31e0: i2c@01c2b400 > Node 0x32ec: phy@01c19400 > Node 0x3458: usb@01c1a000 > Node 0x3550: usb@01c1b000 > Node 0x3648: ethernet@01c30000 > Node 0x37b4: ethernet-phy@1 > Node 0x3800: eeprom@01c14000 > Node 0x3874: rtp@01f04000 > Node 0x3910: ahci-5v > Node 0x39fc: usb0-vbus > Node 0x3ae8: usb1-vbus > Node 0x3bdc: usb2-vbus > Node 0x3cd4: vcc3v0 > Node 0x3d54: vcc3v3 > Node 0x3dd4: vcc5v0 > Node 0x3e54: pmu > Node 0x3ed0: leds > Node 0x3ef4: green_led > Node 0x3f34: blue_led > Node 0x3f78: __symbols__ >=20 > # ofwdump -p /soc/pinctrl@01c20800/usb0_vbus_pin@0 > Node 0x21f0: usb0_vbus_pin@0 > allwinner,pins: > 50 42 39 00=20 > 'PB9' > allwinner,function: > 67 70 69 6f 5f 6f 75 74 00=20 > 'gpio_out' > allwinner,drive: > 00 00 00 00=20 > allwinner,pull: > 00 00 00 00=20 > linux,phandle: > 00 00 00 32=20 > phandle: > 00 00 00 32=20 >=20 > # ofwdump -p /soc/pinctrl@01c20800/usb1_vbus_pin@0 > Node 0x2270: usb1_vbus_pin@0 > allwinner,pins: > 50 44 32 34 00=20 > 'PD24' > allwinner,function: > 67 70 69 6f 5f 6f 75 74 00=20 > 'gpio_out' > allwinner,drive: > 00 00 00 00=20 > allwinner,pull: > 00 00 00 00=20 > linux,phandle: > 00 00 00 33=20 > phandle: > 00 00 00 33=20 >=20 > # ofwdump -p /soc/pinctrl@01c20800/usb2_vbus_pin@0 > Node 0x22f4: usb2_vbus_pin@0 > allwinner,pins: > 50 48 33 00=20 > 'PH3' > allwinner,function: > 67 70 69 6f 5f 6f 75 74 00=20 > 'gpio_out' > allwinner,drive: > 00 00 00 00=20 > allwinner,pull: > 00 00 00 00=20 > linux,phandle: > 00 00 00 34=20 > phandle: > 00 00 00 34=20 >=20 > # ofwdump -p /soc/phy@01c19400 > Node 0x32ec: phy@01c19400 > compatible: > 61 6c 6c 77 69 6e 6e 65 72 2c 73 75 6e 38 69 2d 61 38 33 74=20 > 2d 75 73 62 2d 70 68 79 00=20 > 'allwinner,sun8i-a83t-usb-phy' > reg: > 01 c1 94 00 00 00 00 2c 01 c1 a8 00 00 00 00 04 01 c1 b8 00=20 > 00 00 00 04=20 > clocks: > 00 00 00 2b 00 00 00 08 00 00 00 2b 00 00 00 09 00 00 00 2b=20 > 00 00 00 0a 00 00 00 2b 00 00 00 0b=20 > clock-names: > 75 73 62 30 5f 70 68 79 00 75 73 62 31 5f 70 68 79 00 68 73=20 > 69 63 5f 70 6c 6c 00 68 73 69 63 5f 31 32 6d 00=20 > resets: > 00 00 00 2b 00 00 00 00 00 00 00 2b 00 00 00 01 00 00 00 2b=20 > 00 00 00 02=20 > reset-names: > 75 73 62 30 5f 72 65 73 65 74 00 75 73 62 31 5f 72 65 73 65=20 > 74 00 75 73 62 32 5f 72 65 73 65 74 00=20 > status: > 6f 6b 61 79 00=20 > 'okay' > #phy-cells: > 00 00 00 01=20 > usb1_vbus-supply: > 00 00 00 2c=20 > linux,phandle: > 00 00 00 2d=20 > phandle: > 00 00 00 2d=20 >=20 > # ofwdump -p /soc/usb@01c1a000 > Node 0x3458: usb@01c1a000 > compatible: > 61 6c 6c 77 69 6e 6e 65 72 2c 73 75 6e 38 69 2d 61 38 33 74=20 > 2d 65 68 63 69 00 67 65 6e 65 72 69 63 2d 65 68 63 69 00=20 > reg: > 01 c1 a0 00 00 00 01 00=20 > interrupts: > 00 00 00 00 00 00 00 48 00 00 00 04=20 > clocks: > 00 00 00 17 00 00 00 1a=20 > resets: > 00 00 00 19 00 00 00 1a=20 > phys: > 00 00 00 2d 00 00 00 01=20 > phy-names: > 75 73 62 00=20 > 'usb' > status: > 6f 6b 61 79 00=20 > 'okay' > linux,phandle: > 00 00 00 41=20 > phandle: > 00 00 00 41=20 >=20 > # ofwdump -p /soc/usb@01c1b000 > Node 0x3550: usb@01c1b000 > compatible: > 61 6c 6c 77 69 6e 6e 65 72 2c 73 75 6e 38 69 2d 61 38 33 74=20 > 2d 65 68 63 69 00 67 65 6e 65 72 69 63 2d 65 68 63 69 00=20 > reg: > 01 c1 b0 00 00 00 01 00=20 > interrupts: > 00 00 00 00 00 00 00 4a 00 00 00 04=20 > clocks: > 00 00 00 17 00 00 00 1b=20 > resets: > 00 00 00 19 00 00 00 1b=20 > phys: > 00 00 00 2d 00 00 00 02=20 > phy-names: > 75 73 62 00=20 > 'usb' > status: > 6f 6b 61 79 00=20 > 'okay' > linux,phandle: > 00 00 00 42=20 > phandle: > 00 00 00 42=20 >=20 > # ofwdump -p /usb0-vbus > Node 0x39fc: usb0-vbus > compatible: > 72 65 67 75 6c 61 74 6f 72 2d 66 69 78 65 64 00=20 > 'regulator-fixed' > pinctrl-names: > 64 65 66 61 75 6c 74 00=20 > 'default' > pinctrl-0: > 00 00 00 32=20 > regulator-name: > 75 73 62 30 2d 76 62 75 73 00=20 > 'usb0-vbus' > regulator-min-microvolt: > 00 4c 4b 40=20 > regulator-max-microvolt: > 00 4c 4b 40=20 > enable-active-high: > gpio: > 00 00 00 1d 00 00 00 01 00 00 00 09 00 00 00 00=20 > status: > 64 69 73 61 62 6c 65 64 00=20 > 'disabled' > linux,phandle: > 00 00 00 47=20 > phandle: > 00 00 00 47=20 >=20 > # ofwdump -p /usb1-vbus > Node 0x3ae8: usb1-vbus > compatible: > 72 65 67 75 6c 61 74 6f 72 2d 66 69 78 65 64 00=20 > 'regulator-fixed' > pinctrl-names: > 64 65 66 61 75 6c 74 00=20 > 'default' > pinctrl-0: > 00 00 00 33=20 > regulator-name: > 75 73 62 31 2d 76 62 75 73 00=20 > 'usb1-vbus' > regulator-min-microvolt: > 00 4c 4b 40=20 > regulator-max-microvolt: > 00 4c 4b 40=20 > regulator-boot-on: > enable-active-high: > gpio: > 00 00 00 1d 00 00 00 03 00 00 00 18 00 00 00 00=20 > status: > 6f 6b 61 79 00=20 > 'okay' > linux,phandle: > 00 00 00 2c=20 > phandle: > 00 00 00 2c=20 >=20 > # ofwdump -p /usb2-vbus > Node 0x3bdc: usb2-vbus > compatible: > 72 65 67 75 6c 61 74 6f 72 2d 66 69 78 65 64 00=20 > 'regulator-fixed' > pinctrl-names: > 64 65 66 61 75 6c 74 00=20 > 'default' > pinctrl-0: > 00 00 00 34=20 > regulator-name: > 75 73 62 32 2d 76 62 75 73 00=20 > 'usb2-vbus' > regulator-min-microvolt: > 00 4c 4b 40=20 > regulator-max-microvolt: > 00 4c 4b 40=20 > regulator-boot-on: > enable-active-high: > gpio: > 00 00 00 1d 00 00 00 07 00 00 00 03 00 00 00 00=20 > status: > 64 69 73 61 62 6c 65 64 00=20 > 'disabled' > linux,phandle: > 00 00 00 48=20 > phandle: > 00 00 00 48=20 I might not have found all the usb references but the below is a start. /usr/src/sys/boot/fdt/dts/arm/sinovoip-bpi-m3.dts has: &ehci0 { status =3D "okay"; }; &ehci1 { status =3D "okay"; }; . . . ®_usb1_vbus { gpio =3D <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */ status =3D "okay"; }; &usb1_vbus_pin_a { allwinner,pins =3D "PD24"; }; &usbphy { usb1_vbus-supply =3D <®_usb1_vbus>; status =3D "okay"; }; Via #include there is: /usr/src/sys/boot/fdt/dts/arm/sun8i-a83t.dtsi has: bus_gates: clk@01c20060 { . . . clock-output-names =3D . . . "bus_spi1", "bus_usb_otg", "bus_ehci0", "bus_ehci1", "bus_ohci0", "bus_ve", . . . }; /usr/src/sys/gnu/dts/arm/sunxi-common-regulators.dtsi has: &pio { . . . usb0_vbus_pin_a: usb0_vbus_pin@0 { pins =3D "PB9"; function =3D "gpio_out"; }; usb1_vbus_pin_a: usb1_vbus_pin@0 { pins =3D "PH6"; function =3D "gpio_out"; }; usb2_vbus_pin_a: usb2_vbus_pin@0 { pins =3D "PH3"; function =3D "gpio_out"; }; }; / { . . . reg_usb0_vbus: usb0-vbus { compatible =3D "regulator-fixed"; pinctrl-names =3D "default"; pinctrl-0 =3D <&usb0_vbus_pin_a>; regulator-name =3D "usb0-vbus"; regulator-min-microvolt =3D <5000000>; regulator-max-microvolt =3D <5000000>; enable-active-high; gpio =3D <&pio 1 9 GPIO_ACTIVE_HIGH>; status =3D "disabled"; }; reg_usb1_vbus: usb1-vbus { compatible =3D "regulator-fixed"; pinctrl-names =3D "default"; pinctrl-0 =3D <&usb1_vbus_pin_a>; regulator-name =3D "usb1-vbus"; regulator-min-microvolt =3D <5000000>; regulator-max-microvolt =3D <5000000>; regulator-boot-on; enable-active-high; gpio =3D <&pio 7 6 GPIO_ACTIVE_HIGH>; status =3D "disabled"; }; reg_usb2_vbus: usb2-vbus { compatible =3D "regulator-fixed"; pinctrl-names =3D "default"; pinctrl-0 =3D <&usb2_vbus_pin_a>; regulator-name =3D "usb2-vbus"; regulator-min-microvolt =3D <5000000>; regulator-max-microvolt =3D <5000000>; regulator-boot-on; enable-active-high; gpio =3D <&pio 7 3 GPIO_ACTIVE_HIGH>; status =3D "disabled"; }; . . . /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi has: clocks { . . . usb_clk: clk@01c200cc { #clock-cells =3D <1>; #reset-cells =3D <1>; compatible =3D "allwinner,sun8i-a83t-usb-clk"; reg =3D <0x01c200cc 0x4>; clocks =3D <&osc24M>, <&pll_hsic>; clock-indices =3D <8>, <9>, <10>, <11>, <16>; clock-output-names =3D "usb_phy0", "usb_phy1", "usb_hsic_pll", = "usb_hsic_12m", "usb_ohci0"; }; . . . soc { . . . usbphy: phy@01c19400 { compatible =3D "allwinner,sun8i-a83t-usb-phy"; reg =3D <0x01c19400 0x2c>, <0x01c1a800 0x4>, <0x01c1b800 0x4>; clocks =3D <&usb_clk 8>, <&usb_clk 9>, <&usb_clk 10>, <&usb_clk 11>; clock-names =3D "usb0_phy", "usb1_phy", "hsic_pll", "hsic_12m"; resets =3D <&usb_clk 0>, <&usb_clk 1>, <&usb_clk 2>; reset-names =3D "usb0_reset", "usb1_reset", "usb2_reset"; status =3D "disabled"; #phy-cells =3D <1>; }; =20 ehci0: usb@01c1a000 { compatible =3D "allwinner,sun8i-a83t-ehci", = "generic-ehci"; reg =3D <0x01c1a000 0x100>; interrupts =3D ; clocks =3D <&bus_gates 26>; resets =3D <&ahb_reset 26>; phys =3D <&usbphy 1>; phy-names =3D "usb"; status =3D "disabled"; }; =20 ehci1: usb@01c1b000 { compatible =3D "allwinner,sun8i-a83t-ehci", = "generic-ehci"; reg =3D <0x01c1b000 0x100>; interrupts =3D ; clocks =3D <&bus_gates 27>; resets =3D <&ahb_reset 27>; phys =3D <&usbphy 2>; phy-names =3D "usb"; status =3D "disabled"; }; =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Sep 17 20:30:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 047E3E0307E for ; Sun, 17 Sep 2017 20:30:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A684A6CC5D for ; Sun, 17 Sep 2017 20:30:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2932 invoked from network); 17 Sep 2017 20:30:22 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Sep 2017 20:30:22 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 17 Sep 2017 16:30:22 -0400 (EDT) Received: (qmail 15150 invoked from network); 17 Sep 2017 20:30:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Sep 2017 20:30:21 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 1E343EC85D5; Sun, 17 Sep 2017 13:30:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r323641 - head/sys/arm/allwinner (BananapiM3 [an A83T] and USB: BPI-M3 historically had usb nodes listed in ofwdump -a) From: Mark Millard In-Reply-To: <20170917212858.58fda5174908940ff1ffcc49@bidouilliste.com> Date: Sun, 17 Sep 2017 13:30:20 -0700 Cc: Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: <8D50DB46-D6BD-4F93-9F4A-FA1E405901AA@dsl-only.net> References: <20170917212858.58fda5174908940ff1ffcc49@bidouilliste.com> To: Emmanuel Vadot , svn-src-head@freebsd.org, freebsd-arm X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 20:30:24 -0000 On 2017-Sep-17, at 12:28 PM, Emmanuel Vadot = wrote: > On Sun, 17 Sep 2017 11:50:49 -0700 > Mark Millard wrote: >=20 >>> Author: manu >>> Date: Sat Sep 16 15:58:20 2017 >>> New Revision: 323641 >>> URL:=20 >>> https://svnweb.freebsd.org/changeset/base/323641 >>>=20 >>>=20 >>> Log: >>> Allwinner usb phy: Rework resource allocation >>>=20 >>> . . . >>>=20 >>> While here remove A83T code as upstream and FreeBSD dts don't have >>> nodes for USB. >>>=20 >>> . . . >>>=20 >>> EHCI is still buggy on Pine64 (hang the board) so do not enable it = for now. >>>=20 >>> Tested On: Bananapi (A20), BananapiM2 (A31S), OrangePi One (H3) = Pine64 (A64) >>=20 >> I have a BPI-M3 (A83T based) that has not been updated >> since head -r317015M. It has the root file system on a >> USB SSD for how I normally boot it. The ubldr and >> ubldr.bin go back to 2016-Oct-24 or before (file >> system date). >>=20 >> sysutils/u-boot-sinovoip-bpi-m3/files/ has not >> been updated since then. Nor has the distinfo >> or pkg-descr files. The Makefile has had only >> one change since then: >>=20 >> Revision 430454 - (view) (download) (annotate) - [select for diffs]=20= >> Modified Tue Jan 3 11:01:05 2017 UTC (8 months, 1 week ago) by mat=20 >> File length: 1369 byte(s)=20 >> Diff to previous 419007 >> Cleanup BROKEN/IGNORE for 10.3- >>=20 >> Sponsored by: Absolight >=20 > I don't have the board so if you want to update u-boot for it please > provide a patch. Unfortunately while I can readily look around and identify things that mention "usb", "ehci", "ohci", and "phy" in ofwdump output and in *.dt* files I've no clue about u-boot, *.dt* 's, and the like --and very little clue about the kernel. It would be more of a from-scratch research project, much like finding that "dts ish" before "sev" would, for example, again allow the Pine64+ 2GB to boot from a modern non-debug kernel. That was a lot of exploration to find a single instruction to add. When I started I had no clue it would end up as something like that. [Sometimes when I explore like that someone with the proper background picks out what the core issue is and how to fix before I get as far as a likely suboptimal solution that points in a very specific direction. Other times I get there first.] So if an BPI-M3 u-boot update waits for me it is likely to be a significant wait. Someone with more background likely would work better. Hopefully I'd be able to test trial updates since I have a board. For now it looks like I'll need to set up a non-USB configuration to progress to modern head. >>=20 >> The BPI-M3 has usb nodes show in ofwdump. . . >>=20 >=20 > Yeah I miss-read the DTS because 4 of them are used for one board ... > I don't want to update the dts in sys/boot/fdt/dts/arm and I will > remove them soon. Upstream DTS don't have usb in it but it will be = easy > to add it. You could send a patch to linux-arm if you want but note > that upstream DTS now uses clkng binding (i.e. not all clocks are > under /clocks node) so it will require a driver on our side. >=20 > And please no need to send a 1km long email. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Sep 18 03:29:29 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3038E1A698 for ; Mon, 18 Sep 2017 03:29:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92B047CC8D for ; Mon, 18 Sep 2017 03:29:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26507 invoked from network); 18 Sep 2017 03:29:22 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 18 Sep 2017 03:29:22 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 17 Sep 2017 23:29:22 -0400 (EDT) Received: (qmail 19895 invoked from network); 18 Sep 2017 03:29:22 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 18 Sep 2017 03:29:22 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id D371DEC918C; Sun, 17 Sep 2017 20:29:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Part of why Pine64+ 2GB gets "uhub_attach: getting USB 2.0 HUB descriptor failed,error=USB_ERR_SHORT_XFER" (and so USB fails) From: Mark Millard In-Reply-To: Date: Sun, 17 Sep 2017 20:29:21 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Emmanuel Vadot X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 03:29:30 -0000 On 2017-Sep-17, at 5:30 AM, Emmanuel Vadot = wrote: > On 2017-09-17 10:09, Mark Millard wrote: >> For booting a Pine64+ 2GB it reports: >> usbus0: 12Mbps Full Speed USB v1.0 >> ugen0.1: at usbus0 >> uhub0: on = usbus0 >> uhub_attach: getting USB 2.0 HUB descriptor = failed,error=3DUSB_ERR_SHORT_XFER >> device_attach: uhub0 attach returned 6 >> usbus0: Root HUB problem, error=3DUSB_ERR_NO_ROOT_HUB >=20 > Did you test latest head ? I've fixed OHCI, see commit messages for = more information. Thanks. I had synchronized before your checkins. I've resynchronized and USB 1.1 speed based behavior (ohci behavior) seems to be working fine. (But it has been a long time since I've dealt with "disk" I/O that was this time consuming. I'll probably revert back to avoiding USB until echi is available.) So far my use of "dsb ish" just before the 2 "sev" instructions seem to be working fine (including the one before the release_aps "sev"). The non-debug kernel builds seem to work fine once those are added. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Sep 18 07:01:21 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6985E248FD for ; Mon, 18 Sep 2017 07:01:21 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh503-vm4.bullet.mail.kks.yahoo.co.jp (nh503-vm4.bullet.mail.kks.yahoo.co.jp [183.79.56.190]) by mx1.freebsd.org (Postfix) with SMTP id 5DF568236A for ; Mon, 18 Sep 2017 07:01:20 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.138] by nh503.bullet.mail.kks.yahoo.co.jp with NNFMP; 18 Sep 2017 06:59:04 -0000 Received: from [183.79.100.136] by t501.bullet.mail.kks.yahoo.co.jp with NNFMP; 18 Sep 2017 06:59:04 -0000 Received: from [127.0.0.1] by omp505.mail.kks.yahoo.co.jp with NNFMP; 18 Sep 2017 06:59:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 768606.11280.bm@omp505.mail.kks.yahoo.co.jp Received: (qmail 81793 invoked by uid 60001); 18 Sep 2017 06:59:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1505717944; bh=ZWTE5PxII8kWKaXyxoBxjP8P0434jj14Fo3C7DGd/Qw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=sUEghw8VZpJxOU+DN3gWTs0KLvo8yxLZ5///PgMoQI3psRMBMThAz9TCfPWsuErhCDv59Mkxtq8TNzXA6X/NIYcCyOsqdjFGXsGUVgaxXWbusA8cOAR4E1ZWK/jExRDJqt0ePhqi8HardGflBpTGG6rXtLNbnc/izrhbrzvQF38= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=RRsmP+A0SfOv8+HMTdX/wnt35Ht1UWKCrBfUdt2TDcz9XUm5jj57Ln2zpdYww+jigoGduD7hbSsQ2kUMJiI2KAQgNU8kKU5KB+DbR2RsmYR3b6aL8ds2UnsEBbjiDggP1x2Qy3f2RB0b8gtLWkk2VvaGLrXqKY3r5ZrfOyrNYpI=; Message-ID: <509836.65470.qm@web101704.mail.ssk.yahoo.co.jp> X-YMail-OSG: rC4UdqAVM1lvXmo4dnsUOQXAJ1J_bPKGBJsuvFrqFD4jFJlXeOlP8KJ67dc6_nHWzSvuUt0HjtmI2Md5UslFauw2MQ_BR.QxSLE0nLUO4yjOIXYBY91wwPanKoFE29PrYl5eoKS_Bab2x45ZT2x2P6V.vuAWojLGBQSaPIQrkqzOrku6snZ4XJfu5z4nHuzJPvR2afUUKiuEsCW33ncalmwOZNI7RatybF5Vj3W3_Ee0ep1W7zF_EwNiEBJwqOzKKZpHVZ8bfcpf8SeLVE9EHvx.qEeBQeCRgMQAEo6LQhGnrvALlW08XYhW2QTSPfB9Z4kjeScGUF5qt11rkpHdEck0opm7Sj0o3WbNGVl7EowjCiRNHo58rUGVpLRcGTmEDJtjZJM.4wU73KGYauW7vsQcR81OPk9QMVQy738Q0uCwko16dyZKYDZQsX2fN5fsOk1212P0kgNJQyZQ1y.aJ1UySIvXMKOrWYLEMoIilA7Ijx.5P6SDjxJevUCl8q4ER1R8bOUbCtfDh5oxNsMJLj8jda9a2eY3zgbHbuzy53hW46bePG0Hpi_cGYhS.vVi7i3lscSHBR6zYvhGS9QDRk9BZuY6HVWCTx27R1vO6A-- Received: from [210.20.200.168] by web101704.mail.ssk.yahoo.co.jp via HTTP; Mon, 18 Sep 2017 15:59:04 JST X-Mailer: YahooMailWebService/0.8.111_73 X-YMail-JAS: XzCUB5UVM1nxaYoufz7k4Y9Oecpg7nXz.IoFLfptLjQwcJLlsstSEaFc6bZEel7D2UwYo7evj1O2I537hoX26kAaIpeKYy_J9oUdJUbEiZ6AJWGSWq2TOayoOpd6t6vhVuYK Date: Mon, 18 Sep 2017 15:59:04 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Hang up at boot on armv5t To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 07:01:22 -0000 Hi=0A=0ANow head is hung up at boot on armv5t.=A0=0A=0AKDB: debugger backen= ds: ddb=0AKDB: current backend: ddb=0ACopyright (c) 1992-2017 The FreeBSD P= roject.=0ACopyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 199= 3, 1994=0A=A0 =A0 =A0 =A0 The Regents of the University of California. All = rights reserved.=0AFreeBSD is a registered trademark of The FreeBSD Foundat= ion.=0AFreeBSD 12.0-CURRENT #2 a3dbcdd(zrouter)-dirty: Mon Sep 11 18:04:22 = JST 2017=0A=A0 =A0 hiroki@microserver:/storage/home/hiroki/obj/storage/home= /hiroki/zrouter/tmp/=0Aarm.arm/storage/home/hiroki/freebsd/sys/Buffalo_WZR2= -G300N arm=0AFreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (b= ased on LLVM 5.0.0=0Asvn)=0A=0ALast month build is fine.=0A=0Ahttps://gist.= github.com/yamori813/88224f1c96c9c592fb611b12a15e4ab5=0A=0A=0AHiroki Mori= =0A From owner-freebsd-arm@freebsd.org Mon Sep 18 07:07:50 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63081E24D01 for ; Mon, 18 Sep 2017 07:07:50 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 301E0825C1 for ; Mon, 18 Sep 2017 07:07:50 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 0B20A26034B; Mon, 18 Sep 2017 09:07:46 +0200 (CEST) Subject: Re: Hang up at boot on armv5t To: Mori Hiroki , "freebsd-arm@freebsd.org" References: <509836.65470.qm@web101704.mail.ssk.yahoo.co.jp> From: Hans Petter Selasky Message-ID: <2290cdb6-bae9-c850-a003-d046cca9d4e1@selasky.org> Date: Mon, 18 Sep 2017 09:05:19 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <509836.65470.qm@web101704.mail.ssk.yahoo.co.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 07:07:50 -0000 On 09/18/17 08:59, Mori Hiroki wrote: > Hi > > Now head is hung up at boot on armv5t. > > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2017 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 12.0-CURRENT #2 a3dbcdd(zrouter)-dirty: Mon Sep 11 18:04:22 JST 2017 > hiroki@microserver:/storage/home/hiroki/obj/storage/home/hiroki/zrouter/tmp/ > arm.arm/storage/home/hiroki/freebsd/sys/Buffalo_WZR2-G300N arm > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0 > svn) > > Last month build is fine. > > https://gist.github.com/yamori813/88224f1c96c9c592fb611b12a15e4ab5 > You might want to diff sys/arm directory and look for relevant changes. --HPS From owner-freebsd-arm@freebsd.org Mon Sep 18 15:32:37 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EB35E18A12 for ; Mon, 18 Sep 2017 15:32:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF1936E4DC for ; Mon, 18 Sep 2017 15:32:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id o200so1346870itg.0 for ; Mon, 18 Sep 2017 08:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4nyyDzn86JGknG/KTDLBIINZ9xX/ph0uLox112rwEJI=; b=LPB9YiKRBVanDCpk0uvmYd94znjDoTgqbkpx1U3p+rWmubSgfEPLNQTKPkW2zJFNIF AK5N48JZJe32nFwRb3CZTdIYYDdfpYAMk9h/I+vDlWCpqe3B31/pqUWvyXOaVHXBVFsS zdorvVGPmR9H9ZW29gbVM+mSeRCoJUQFSgNZWAK+zQ9Ec9ZuSSToftX6KZ740nibH7JY a/B+hixkPpVpxZPFTUVVWUCzWGRCwMOJNflcTL9tTZtr8ptZz11pcjkE6EP4cnFcApIr plnXohBoI9EgRgQT+rQcOlTB5/HcB2/stj4y2/C3DRfNH9BW/Xt58Km2ZbeuqaDwbWpF xjVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4nyyDzn86JGknG/KTDLBIINZ9xX/ph0uLox112rwEJI=; b=MaIa3xDApNKSMnm5/RGfzPiGI1yHa3Au9LIMndpn3yMHeTwN+sI9EVqPx+/9/OieNq Ql6EV4Ew6sfLAfe5lIrMW0bYoSeEZJIVclh7cnrKYYilMkOo4Iz1u7h6b7PF28tCo34P 6k2iVHzuDtYpWzm5EffynAOuXYRR18BCd7YibKwkg3niumUZGtZU9MJaeUf+m+eFLFf0 IkqOCyHB6zciM0UsPe5yeOuws847bsjQlcpfWrOOMZfLKx+AT9o5Fl5+cZTzRBLI1pDT tp4LUOW/cAutc970SfieVV9CAaa8DK1o49LDz6kY8hU5X33nNAs5AAK8Y1B0+0Lp/5pI fZKQ== X-Gm-Message-State: AHPjjUi+mqUMLEkgv6qoYv3DLNV1jPsbMCPDnj9ZmULKgaLyYjVlYNSL XTeYt92xBtlUQTXg506aUa7xmFiF3YJ9aJGj+8pCjg== X-Google-Smtp-Source: AOwi7QAOpRqh1QnBGMps7GalaU18/5IZ7Fj4cWho+oDMZudS5HMAMQEOd4rrFtFOYytEd5F7EHhZ/kjDeTCqpDP+vL4= X-Received: by 10.36.73.23 with SMTP id z23mr15691607ita.136.1505748756237; Mon, 18 Sep 2017 08:32:36 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Mon, 18 Sep 2017 08:32:35 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:60a7:d7e6:aef8:c203] In-Reply-To: <509836.65470.qm@web101704.mail.ssk.yahoo.co.jp> References: <509836.65470.qm@web101704.mail.ssk.yahoo.co.jp> From: Warner Losh Date: Mon, 18 Sep 2017 09:32:35 -0600 X-Google-Sender-Auth: jE2Stje46Cwv3VktKF0Q21nFRlw Message-ID: Subject: Re: Hang up at boot on armv5t To: Mori Hiroki Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 15:32:37 -0000 On Mon, Sep 18, 2017 at 12:59 AM, Mori Hiroki wrote: > Hi > > Now head is hung up at boot on armv5t. > > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2017 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 12.0-CURRENT #2 a3dbcdd(zrouter)-dirty: Mon Sep 11 18:04:22 JST > 2017 > hiroki@microserver:/storage/home/hiroki/obj/storage/home/ > hiroki/zrouter/tmp/ > arm.arm/storage/home/hiroki/freebsd/sys/Buffalo_WZR2-G300N arm > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM > 5.0.0 > svn) > > Last month build is fine. > > https://gist.github.com/yamori813/88224f1c96c9c592fb611b12a15e4ab5 You might want to do a binary search between the working and broken builds to see where it breaks. Without that, it's hard to make progress. Warner From owner-freebsd-arm@freebsd.org Mon Sep 18 20:30:58 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 214D6E05155 for ; Mon, 18 Sep 2017 20:30:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B01A27ED07 for ; Mon, 18 Sep 2017 20:30:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3400 invoked from network); 18 Sep 2017 20:30:55 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 18 Sep 2017 20:30:55 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 18 Sep 2017 16:30:55 -0400 (EDT) Received: (qmail 5251 invoked from network); 18 Sep 2017 20:30:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 18 Sep 2017 20:30:55 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id CD956EC85D5; Mon, 18 Sep 2017 13:30:54 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: allwinner question: New CLR4(sc->phy_ctrl, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG) for phyno !=0 vs. CLR4(sc, 0, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG) before. . . Message-Id: Date: Mon, 18 Sep 2017 13:30:54 -0700 To: Emmanuel Vadot , freebsd-arm X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 20:30:58 -0000 It probably just my ignorance of the code's intent but for A64 it used to be that phyno ==1 had code that did CLR4 for phyno==0 (hard coded): if (sc->phy_type == AWUSBPHY_TYPE_A64) { CLR4(sc, phyno, PMU_UNK_H3, PMU_UNK_H3_CLR); /* EHCI0 and OTG share a PHY */ if (phyno == 0) SET4(sc, 0, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); else if (phyno == 1) CLR4(sc, 0, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); } So: that last CLR4 manipulated phyno==0 as far as I can tell, no matter what the passed-in phyno was. In the new code there seems to be no hook for phyno==1 to manipulate phyno==0 similarly: if (sc->phy_conf->phy0_route == true) { if (phyno == 0) SET4(sc->phy_ctrl, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); else CLR4(sc->phy_ctrl, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); } That CLR4 seems to be manipulating phyno==1 instead and seems to have no means of doing otherwise. Was the old code wrong? === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Sep 18 20:42:38 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5DA0E05E5F for ; Mon, 18 Sep 2017 20:42:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 85E4D7F3D0 for ; Mon, 18 Sep 2017 20:42:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6805 invoked from network); 18 Sep 2017 20:42:37 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 18 Sep 2017 20:42:37 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 18 Sep 2017 16:42:37 -0400 (EDT) Received: (qmail 14603 invoked from network); 18 Sep 2017 20:42:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 18 Sep 2017 20:42:36 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 4181DEC938A; Mon, 18 Sep 2017 13:42:36 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: allwinner question: New CLR4(sc->phy_ctrl, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG) for phyno !=0 vs. CLR4(sc, 0, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG) before. . . Date: Mon, 18 Sep 2017 13:42:35 -0700 References: To: Emmanuel Vadot , freebsd-arm In-Reply-To: Message-Id: <5830ABC8-6544-4588-BDB6-483C2D1B3D3E@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 20:42:38 -0000 On 2017-Sep-18, at 1:30 PM, Mark Millard wrote: > It probably just my ignorance of the code's intent > but for A64 it used to be that phyno ==1 had code > that did CLR4 for phyno==0 (hard coded): > > if (sc->phy_type == AWUSBPHY_TYPE_A64) { > CLR4(sc, phyno, PMU_UNK_H3, PMU_UNK_H3_CLR); > > /* EHCI0 and OTG share a PHY */ > if (phyno == 0) > SET4(sc, 0, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); > else if (phyno == 1) > CLR4(sc, 0, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); > } > > So: that last CLR4 manipulated phyno==0 as far as I can tell, > no matter what the passed-in phyno was. > > In the new code there seems to be no hook for phyno==1 > to manipulate phyno==0 similarly: > > if (sc->phy_conf->phy0_route == true) { > if (phyno == 0) > SET4(sc->phy_ctrl, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); > else > CLR4(sc->phy_ctrl, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); > } > > That CLR4 seems to be manipulating phyno==1 instead and > seems to have no means of doing otherwise. > > Was the old code wrong? May be I asked the reverse of the right question: that first CLR 4 in the old code varied by phyno but now always uses phy_ctrl: if (sc->phy_conf->pmu_unk1 == true) CLR4(sc->phy_ctrl, PMU_UNK_H3, PMU_UNK_H3_CLR); Overall one part or the other seems to be a mismatch with the old code for A64. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Sep 19 06:30:03 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8671AE25B4D for ; Tue, 19 Sep 2017 06:30:03 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh601-vm3.bullet.mail.ssk.yahoo.co.jp (nh601-vm3.bullet.mail.ssk.yahoo.co.jp [182.22.90.12]) by mx1.freebsd.org (Postfix) with SMTP id 1A3BC6C66A for ; Tue, 19 Sep 2017 06:30:02 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [182.22.66.103] by nh601.bullet.mail.ssk.yahoo.co.jp with NNFMP; 19 Sep 2017 06:27:05 -0000 Received: from [182.22.91.129] by t601.bullet.mail.ssk.yahoo.co.jp with NNFMP; 19 Sep 2017 06:27:05 -0000 Received: from [127.0.0.1] by omp602.mail.ssk.yahoo.co.jp with NNFMP; 19 Sep 2017 06:27:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 3271.18976.bm@omp602.mail.ssk.yahoo.co.jp Received: (qmail 38687 invoked by uid 60001); 19 Sep 2017 06:27:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1505802424; bh=yUJl/JLj2v1HWsgEWZuAOUyAogQg5RUpk43i9545ESo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hvpyUFFtBwGEpNA029QXHutRXpRxhKoGcxNi+2oljTY6J9ifuIQ7JnsJaC1D0blooa6g5ebfvAXh9/01yYbrj149avbIziNt3uBBUOIyXtPN6DmXqSrte9hC2hrUG7AGPVrGm5IpGUnG5crAywdMRgM2oSn6vZh9LGrUPIoyBvY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Lp9BueZqc7DMuV/4pYYBPSzZ/xmJAeOdPFb08jN9mxd6DwGD7q24yZUApM1vQT7fC42CI7acLIWWTPvaBI5hbwJvorkbEMcp6rW5K3LdJFbNNCVV5PulmdI0hIEWoAhkNLr2/SzRnASIz/G7yWLRD/uAHgLvOQz6ol9C+nQF3II=; Message-ID: <818825.27559.qm@web101705.mail.ssk.yahoo.co.jp> X-YMail-OSG: zn25flwVM1n1el9qtyI.RmKei6g9suhj0DWLMkJWbfOWMAlWs.8k3LZu4BWSsqIzZDbqMyzRQuO34Z26ZSZgO6OiLC4wJD5I_e3HIbRu4mABdOxnG8EyF18fAIvipeeNgzx81qXqDkZnoPH5bNqLf136eq_MvSUwIAaXZDvUCjF2g61HQyYhEMgbs7A5i7P17Ff3.r_KARTvLTlwc0YfYGB1WFS0nURrChuu6YIbGwAjnEe_eh0IMrVe3sQx3b6nz08cDbGi5F7ch.Du_ZXjn_9M1glRzwXJ8UAFzVjli5LYAGXd2_ok66hzkS0eotKPbKjZzzITn75fESAf9sqgzDXhXc99Kj99PAgxm0m_WkK8_H6Fgnxk07m1OMOCUtWjOAD3U7x2GUQKyV5PD1edX_RHJXB3gPC0m9mAqYUK5eKBuzLf81op7zntJVWk7qVi7lcKsQROPQVSxLeoYt3SCUi.h79dv_PTs_IbJDnldXLvBhcjIU49BAGHxSBLLZ.k8WMg0JEl2CwzvpTN2f9yHN70daE_28q3JF6D57dBceG2j7uLDZ3pW1FRS86nIsYJJRoaIXwdgxwxUMozGDno1.ENMb5mEqvlmVJZJ7P5fvQ3c6aIYYwLGKNRwSlLUu7EohgFgy80g3Nw94WNOPqg123fdQ-- Received: from [210.20.200.168] by web101705.mail.ssk.yahoo.co.jp via HTTP; Tue, 19 Sep 2017 15:27:04 JST X-Mailer: YahooMailWebService/0.8.111_73 X-YMail-JAS: 7BLUHTcVM1kunFnIIzeUzN0pHQUazjp470o9dXD1T_zxLWu.x_Y1KAp9LHwoMG4OYZO48HrMn9sFucUZN0XA2BdPJohzZE3TBKAz3joYodakGn7HwQbaESlOiXCC0Fk7yJ0C References: <509836.65470.qm@web101704.mail.ssk.yahoo.co.jp> Date: Tue, 19 Sep 2017 15:27:04 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Re: Hang up at boot on armv5t To: Warner Losh Cc: "freebsd-arm@freebsd.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 06:30:03 -0000 Hi=0A=0A----- Original Message -----=0A>From: Warner Losh = =0A>To: Mori Hiroki =0A>Cc: "freebsd-arm@freebsd.or= g" =0A>Date: 2017/9/19, Tue 00:32=0A>Subject: Re: = Hang up at boot on armv5t=0A> =0A>=0A>=0A>=0A>=0A>=0A>On Mon, Sep 18, 2017 = at 12:59 AM, Mori Hiroki wrote:=0A>=0A>Hi=0A>>=0A>>= Now head is hung up at boot on armv5t.=A0=0A>>=0A>>KDB: debugger backends: = ddb=0A>>KDB: current backend: ddb=0A>>Copyright (c) 1992-2017 The FreeBSD P= roject.=0A>>Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1= 993, 1994=0A>>=A0 =A0 =A0 =A0 The Regents of the University of California. = All rights reserved.=0A>>FreeBSD is a registered trademark of The FreeBSD F= oundation.=0A>>FreeBSD 12.0-CURRENT #2 a3dbcdd(zrouter)-dirty: Mon Sep 11 1= 8:04:22 JST 2017=0A>>=A0 =A0 hiroki@microserver:/storage/ home/hiroki/obj/s= torage/home/ hiroki/zrouter/tmp/=0A>>arm.arm/storage/home/hiroki/ freebsd/s= ys/Buffalo_WZR2-G300N arm=0A>>FreeBSD clang version 5.0.0 (tags/RELEASE_500= /final 312559) (based on LLVM 5.0.0=0A>>svn)=0A>>=0A>>Last month build is f= ine.=0A>>=0A>>https://gist.github.com/ yamori813/ 88224f1c96c9c592fb611b12a= 15e4a b5=0A>=0A>=0A>You might want to do a binary search between the workin= g and broken builds to see where it breaks. Without that, it's hard to make= progress.=0A>=0A>=0A>Warner=A0=0A=0A=0AThis is RT1310 build by sys/arm/ral= ink.=0A=0AI get debug log by VERBOSE_SYSINIT.=0A=0A=0ACopyright (c) 1992-20= 17 The FreeBSD Project.=0ACopyright (c) 1979, 1980, 1983, 1986, 1988, 1989,= 1991, 1992, 1993, 1994=0A=A0 =A0 =A0 =A0 The Regents of the University of = California. All rights reserved.=0AFreeBSD is a registered trademark of The= FreeBSD Foundation.=0AFreeBSD 12.0-CURRENT #1 a3dbcdd(zrouter)-dirty: Tue = Sep 19 15:03:43 JST 2017=0A=A0 =A0 hiroki@microserver:/storage/home/hiroki/= obj/storage/home/hiroki/zrouter/tmp/=0Aarm.arm/storage/home/hiroki/freebsd/= sys/Buffalo_WZR2-G300N arm=0AFreeBSD clang version 5.0.0 (tags/RELEASE_500/= final 312559) (based on LLVM 5.0.0=0Asvn)=0Asubsystem 1000000=0A=A0=A0 0xc0= 1c1674(0)... done.=0A=A0=A0 0xc01d3a0c(0)... done.=0Asubsystem 1800000=0A= =A0=A0 0xc00b9cb4(0)... done.=0A=A0=A0 0xc0097fc4(0)... done.=0A=A0=A0 0xc0= 097c00(0xc0280580)...=A0=0A=0AI checked last address by objdump -D.=0A=0Ac0= 097c00 :=0Ac0280580 :=0A=0AWhat is wrong ?=0A=0AI use = git repository on build. If I change git branch then arm platform is build = take=0A=0A=A06 hour by my server. It is very hard debugging.=A0=0A=0AHiroki= Mori=0A From owner-freebsd-arm@freebsd.org Tue Sep 19 07:45:25 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59535E02565 for ; Tue, 19 Sep 2017 07:45:25 +0000 (UTC) (envelope-from hrabanek@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E06C36F0AA for ; Tue, 19 Sep 2017 07:45:24 +0000 (UTC) (envelope-from hrabanek@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id i189so2626125wmf.1 for ; Tue, 19 Sep 2017 00:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=tsYSRsGvC3ZCe8RTtuB+sLmGk7lzEcz5poBDvhp1t4o=; b=LHapkv6WCJbHbOEuO0ZyFryLNJAs1/0X7LJOuBWBNaTWH2xMRXS9XzIKBwGgvMJ6Xy pU1hoT3g6xDqPfrMmP7ZBub/8vQML6pqTaxhk+PBYRDAY8u34/lNuyw/xEXkuyonIlYO 2KHAzvsvN0eu7tKZuwwfL5CxJaAx0LGv3pD5g28a9LNzs4Cg0z7nJmDM88QBk3wVZQ5U 2n2/Aum5brBxJu0Ngw/U5GDiPeSIrrPsLv5j9W0IQazAQJyp6YikjR4SH3uNIGmU2Bbj kmdG1iQfbl/QkoFE34XdnDVoGRzApxKoI8p1tUQpTLo4MK3lGQX42SGrlq0cDeX8GtPh IFXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tsYSRsGvC3ZCe8RTtuB+sLmGk7lzEcz5poBDvhp1t4o=; b=gdSWp1dzUUJfzPJQhR6Qe5JAjeelxv8byOO5tJiUGT/eG6FQjjcotFnGfeB0c3eeDy xAN3beaVsuejP9TKwM/w/XKf8A3yijgNOHmXB+KaRR/TwmOHfCn9Gwj7OC7ovx6bEeIC WGfDw3DM2ZqbQ4l/Bvm1cTYXeUeHL9KWKCV+cG7y0o1mRPhmP5hsMp4DWfaMJmFGK6Vt o1i+ANrGqxK8ycYV9inAtRrIHDXe7x/ZGTSkW9TaTfQ553/oqy0mumvJjCWbgSXnLJzx 8GS3R7qbxbBpWn6yEerU3UTubO6lNFOmvCHfl4hsBNgr6qEv90E+d64Ae3vWvvHz3jKd wLtA== X-Gm-Message-State: AHPjjUha5Q3so9q04J5Y6hvSDNwFcY8r4kzhbLNZIO4GytT865LYS9Qc H4YVsT7MUdx8ujrraJ5PPCFa0ip/W1F45zAXL3h01z2a X-Google-Smtp-Source: AOwi7QBKyhYXb0ICbFDAT4jSqYkCuQ63eglHGxLj3gR6NPH89WK7ci7XnEeMUT1ilebIXYCYnkoSdEMNdrcxClU7+nk= X-Received: by 10.80.144.242 with SMTP id d47mr833299eda.79.1505807122653; Tue, 19 Sep 2017 00:45:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.183.36 with HTTP; Tue, 19 Sep 2017 00:45:22 -0700 (PDT) From: Michael Hrabanek Date: Tue, 19 Sep 2017 09:45:22 +0200 Message-ID: Subject: Allwinner H3 (NanoPi Neo): Getting PORTL (on /dev/gpioc1) to work To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 07:45:25 -0000 Hi everybody, I'm running 12.0-CURRENT (rev 323710) using GENERIC kernel on NanoPi Neo (allwinner H3). I can use and control all gpio pins on /dev/gpioc0 without any issue, but if I try to configure any pin on /dev/gpioc1 (there are only PORTL pins there), nothing happens (pin configuration stays the same, gpioctl returns 0 and no error in log). root@nanopi-neo:~ # gpioctl -f /dev/gpioc1 -lv pin 00: 0 PL0, caps: pin 01: 0 PL1, caps: pin 02: 0 PL2<>, caps: pin 03: 0 PL3<>, caps: pin 04: 0 PL4<>, caps: pin 05: 0 PL5<>, caps: pin 06: 0 PL6<>, caps: pin 07: 0 PL7<>, caps: pin 08: 0 PL8<>, caps: pin 09: 0 PL9<>, caps: pin 10: 0 PL10<>, caps: pin 11: 0 PL11<>, caps: root@nanopi-neo:~ # gpioctl -f /dev/gpioc1 -c 10 OUT root@nanopi-neo:~ # gpioctl -f /dev/gpioc1 -lv <...> pin 10: 0 PL10<>, caps: pin 11: 0 PL11<>, caps: Did anyone managed to get pins on PORTL working? (btw there are two LEDs on nanopi neo, the blue one on PA10, which I can control normally and the green (pwr) one, wired to PL10, which only slightly dims (ie. pin is not configured as output)). Any idea what's wrong? Is there an issue with FDT config? (I'm using default one from src nanopi-neo.dtb) Or some bug in kernel? I'm not afraid of some kernel hacking, but I'd welcome some pointers where to look first. Any suggestions would be greatly appreciated, Michael From owner-freebsd-arm@freebsd.org Tue Sep 19 17:51:55 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3334E20DB6 for ; Tue, 19 Sep 2017 17:51:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76B7F6543F for ; Tue, 19 Sep 2017 17:51:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22383 invoked from network); 19 Sep 2017 17:51:48 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 19 Sep 2017 17:51:48 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 19 Sep 2017 13:51:48 -0400 (EDT) Received: (qmail 16586 invoked from network); 19 Sep 2017 17:51:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Sep 2017 17:51:48 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 97E0AEC8F85; Tue, 19 Sep 2017 10:51:47 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: allwinner question reformulalted: sc->phy_ctrl vs. sc->pmu[phyno], which should be used with PMU_UNK_H3 and PMU_UNK_H3_CLR? (sc->phy_ctrl actually used currently) Date: Tue, 19 Sep 2017 10:51:46 -0700 References: <5830ABC8-6544-4588-BDB6-483C2D1B3D3E@dsl-only.net> To: Emmanuel Vadot , freebsd-arm In-Reply-To: <5830ABC8-6544-4588-BDB6-483C2D1B3D3E@dsl-only.net> Message-Id: <3EFEF9A2-774E-4321-ABF0-49C1CD52ECFB@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 17:51:55 -0000 The modern, updated sys/arm/allwinner/aw_usbphy.c code uses PMU_UNK_H3 and PMU_UNK_H3_CLR with sc->phy_ctrl : if (sc->phy_conf->pmu_unk1 == true) CLR4(sc->phy_ctrl, PMU_UNK_H3, PMU_UNK_H3_CLR); but uses sc->pmu[phyno] for PMU_IRQ_ENABLE and: PMU_ULPI_BYPASS | PMU_AHB_INCR8 | PMU_AHB_INCR4 | PMU_AHB_INCRX_ALIGN in: SET4(sc->pmu[phyno], PMU_IRQ_ENABLE, PMU_ULPI_BYPASS | PMU_AHB_INCR8 | PMU_AHB_INCR4 | PMU_AHB_INCRX_ALIGN); Having PMU_ not used with sc->pmu[phyno] looks a little odd. For reference: the older code used: if (sc->phy_type == AWUSBPHY_TYPE_A64) { CLR4(sc, phyno, PMU_UNK_H3, PMU_UNK_H3_CLR); and: if (phyno > 0) { /* Enable passby */ SET4(sc, phyno, PMU_IRQ_ENABLE, PMU_ULPI_BYPASS | PMU_AHB_INCR8 | PMU_AHB_INCR4 | PMU_AHB_INCRX_ALIGN); } where: that involved use of: (sc)->res[(phyno)] via: #define RD4(sc, i, o) bus_read_4((sc)->res[(i)], (o)) #define WR4(sc, i, o, v) bus_write_4((sc)->res[(i)], (o), (v)) #define CLR4(sc, i, o, m) WR4(sc, i, o, RD4(sc, i, o) & ~(m)) #define SET4(sc, i, o, m) WR4(sc, i, o, RD4(sc, i, o) | (m)) === Mark Millard markmi at dsl-only.net On 2017-Sep-18, at 1:42 PM, Mark Millard wrote: On 2017-Sep-18, at 1:30 PM, Mark Millard wrote: > It probably just my ignorance of the code's intent > but for A64 it used to be that phyno ==1 had code > that did CLR4 for phyno==0 (hard coded): > > if (sc->phy_type == AWUSBPHY_TYPE_A64) { > CLR4(sc, phyno, PMU_UNK_H3, PMU_UNK_H3_CLR); > > /* EHCI0 and OTG share a PHY */ > if (phyno == 0) > SET4(sc, 0, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); > else if (phyno == 1) > CLR4(sc, 0, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); > } > > So: that last CLR4 manipulated phyno==0 as far as I can tell, > no matter what the passed-in phyno was. > > In the new code there seems to be no hook for phyno==1 > to manipulate phyno==0 similarly: > > if (sc->phy_conf->phy0_route == true) { > if (phyno == 0) > SET4(sc->phy_ctrl, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); > else > CLR4(sc->phy_ctrl, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); > } > > That CLR4 seems to be manipulating phyno==1 instead and > seems to have no means of doing otherwise. > > Was the old code wrong? May be I asked the reverse of the right question: that first CLR 4 in the old code varied by phyno but now always uses phy_ctrl: if (sc->phy_conf->pmu_unk1 == true) CLR4(sc->phy_ctrl, PMU_UNK_H3, PMU_UNK_H3_CLR); Overall one part or the other seems to be a mismatch with the old code for A64. === Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Sep 20 00:07:39 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A450FE0FCB0; Wed, 20 Sep 2017 00:07:39 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75A8E73137; Wed, 20 Sep 2017 00:07:39 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pg0-x22e.google.com with SMTP id j16so730452pga.1; Tue, 19 Sep 2017 17:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:message-id:date:subject:from :to; bh=p2IzbOvfrFq5m0ZuUbf3JZqIkdyCv4CQiQKmo2o8Io0=; b=MCdVzZUhB9TN3nzZ6gpCHnDvDdoowzaNu7iHQXHVIOKiyVZ2YCuZ1oMEfMix18fbI5 OkIkpl/hE7xn4g5OAjBfEGQAzrwnhw9GpChJXfzxxaRSjjgXJtzI0o9sTZRy8LtR7/ai p3Mx2ku6C9HBHXpJrKqjz1Tk3IwZnDf8uRAQIzK7dbjg1YZAA7QPpUkS9aTFIyShjqev SQVfDT8XzaxHC1yoMwPyC0BQg13dkOuoVFbKDBqbgvPps6iu12xBuVA1+sMQxl+7zUIh mMMmeZ79/ryBQyNRnnf/+0jeazdwULBUpZEL7Gr2MEqXxn+2K4amD0mtceab+Dxfgmae vyMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:to; bh=p2IzbOvfrFq5m0ZuUbf3JZqIkdyCv4CQiQKmo2o8Io0=; b=B/lqogcE969zqtxC/6IWrDYB1s2DaT/NZ4t03lrHoQMzf4Xf4m/Cz7o7n4tOwJnbYR SjHcl8b+vXUTElElJhtJnfTefLDFFHHYi00QQs8Ad1umSGLMlMVizNTRWsc+58DC7gWZ fxBHDy0F6oSuv6wEex+ri/D3RF5cErM1M0MYZkBl5D6h7Mlb3OJWy2RHyDVXIEbY8x0h Txz1ckawWp44GpVcqOSzksJ0O2kgamO7CM+MWjcXb3FmDuVa6R0fm+1oCzhW0iYyPU5Q QUKdfRMu39PQGB0dTiQ4oj9SYIG6ZcsfeO3ZiJnL51bhhkTOMguxIZgnsNpfbbVHwmSW uG7w== X-Gm-Message-State: AHPjjUhozHSnlu1UxDLbwoDocojjEyY6LPSwq4IBUvEnL0dDOVu+skYz 8I28prSZJR7Lz6fnJvIcyeKcgFHV X-Google-Smtp-Source: AOwi7QD/HnV9n+ll0pUEswV2DFQsRLsV7ay5PIVvkwX+osr1lzuZHTpvGeKuXWwM/vowGkGnxafT/Q== X-Received: by 10.99.109.71 with SMTP id i68mr329498pgc.252.1505866058656; Tue, 19 Sep 2017 17:07:38 -0700 (PDT) Received: from [127.0.0.1] ([184.151.231.189]) by smtp.gmail.com with ESMTPSA id s4sm4504460pgr.32.2017.09.19.17.07.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Sep 2017 17:07:37 -0700 (PDT) X-Mailer: BlackBerry Email (10.3.3.2163) Message-ID: <20170920000736.6557780.5724.32195@gmail.com> Date: Tue, 19 Sep 2017 17:07:36 -0700 Subject: Funny From: Russell Haley To: Freebsd-mono , freebsd-arm , Lua mailing list MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 00:07:39 -0000 From owner-freebsd-arm@freebsd.org Wed Sep 20 06:07:05 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23E8BE24C2F for ; Wed, 20 Sep 2017 06:07:05 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87EDC814A1 for ; Wed, 20 Sep 2017 06:07:04 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id 80so1644572lfy.4 for ; Tue, 19 Sep 2017 23:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=Jd0A7Ldgm9BWsExNmwJgLqpFW3uWhYcIlXeSEO4m36Q=; b=U97bv9wCM7X2J7pz0PQvOSH41AssmbyYLitU/PtqgmeCk5zP+6gC79v7urboD94r62 pQVJ9SjHsrw8ZlnV8vBVu02mZram3LrT6i5suKB3oqVSvxUdv9T6eGFTK2BaD29aGt3t zFe69n+2myHfZH1Y5Vfro94myomO8zYPWEekdH2gaCLBHcVUzabXGmpU0aeriIfOoQBf y3XxkpaEdRMDW8U3c7oZKJJ5tVGCph0g2TtYA9u0uVhVd6TOkHOHgnlHtyPNs4hiL3Gk hboiKzC3dnzwdkTjQVdHaUEWBDhsLK4Jsr23qzmuyQl62udYKaoA203SG6VDMmjFo2lR JJxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=Jd0A7Ldgm9BWsExNmwJgLqpFW3uWhYcIlXeSEO4m36Q=; b=i/MRlWbDeXxSdOyEHpZu0PYoXkqCJ5VfiHY4ZtZHCkSFCWLuMlpjMm9WPnUE8VvRQI 9weuP0dbqc+JpJfIcjqqXHPhVCKf5/DufZMp5WBiEcvRCleWQf1P+OAAv/6/fsESfv8Q 3QxC0jTBh56LkpIrB8wqoZADaGJT31mlr7+RLfwMp59H5NmLJugt4QQCK57V+ip4iQuc YTCoUm4j8JwG5bJsQPPZpH16NxuoMSsEBucGkiE5FVrc2EWVcxHeH8HodupvRMv/POmR K1837NRleZrqseHUem9Gm9o092o6+Zwbrm9J0Z/KL5gPU0OK1nZvScl1kQmaHYlSW64g eF6Q== X-Gm-Message-State: AHPjjUg7JwIRycsuWzU1xCdLt1EIhtZZl3r7NE6IazoW0Ux69Gks15ev cQs9pipcMwTpJqgt1P71vP0CnNrVaohjDUtCO7gftA== X-Google-Smtp-Source: AOwi7QANJhynMHX2Wp9PEvTCBOPvBy/iLCjRXzcPUErabJlOYLRKDyQttGloRx7skiAsnm87naDTi1ESqfPzbgZvqQU= X-Received: by 10.25.41.67 with SMTP id p64mr410057lfp.200.1505887622452; Tue, 19 Sep 2017 23:07:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Tue, 19 Sep 2017 23:07:01 -0700 (PDT) In-Reply-To: References: From: Russell Haley Date: Tue, 19 Sep 2017 23:07:01 -0700 Message-ID: Subject: Re: Unexpected Results from nuttcp testing wifi on arm To: freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 06:07:05 -0000 Hi, So I am consistently getting very low throughput when testing with nuttcp if I use my arm board as the client. If the desktop is the client, I am averaging ~8 Mbps. When my arm board is the client, I get an average of just over 1 Mbps. This doesn't seem right to me. Any input or confirmation that this is incorrect would be grand. My assumption is I have done something wrong. :-/ Russ On Sat, Sep 16, 2017 at 11:18 PM, Russell Haley wrot= e: > Hi, > > Well I WAS going to bed and then I looked at the results of my testing > for the BBB/wifi stuff. This is NOT on a BBB and I have a different > wifi adapter so I started a new post. > > When testing wifi on my imx6 (hummingboard) I get drastically > different results depending on which side is the client or the server. > > Host =3D amd64 TrueOS wired 100Mbps > Target =3D imx6 FBSD 12 wifi (MAC/BBP RT3572 ) > > > amd64 (wired) client -> imx6 Server > russellh@prescott:~% nuttcp -n 1000 -v -i1 192.168.2.62 > /tmp/prescott1.= out > http://termbin.com/7o1w > #Summary: > nuttcp-t: 62.5000 MB in 60.77 real seconds =3D 1053.13 KB/sec =3D 8.6273 = Mbps > > ----------------------------------------------------------- > > imx6 client -> amd64 (wired) Server > root@imx6:~ # nuttcp -i 1 -v -n 1000 prescott > /tmp/out.txt > > http://termbin.com/8vvh > #Summary: > nuttcp-t: 9.0000 MB in 108.96 real seconds =3D 84.58 KB/sec =3D 0.6929 Mb= ps > > Is this abnormal? (Please say yes!) > > Russ (more setup details below) > > > IMX6 test setup: > > root@imx6:~ # uname -a > FreeBSD imx6 12.0-CURRENT FreeBSD 12.0-CURRENT #13 r321601M: Thu Sep > 14 20:43:21 PDT 2017 > russellh@prescott.highfell.local:/usr/home/russellh/FreeBSD/rh-armv6/obj/= arm.armv6/usr/home/russellh/FreeBSD/rh-armv6/src/sys/IMX6 > arm > > root@imx6:~ # dmesg | grep run0 > run0 on uhub2 > run0: <1.0> on usbus1 > run0: MAC/BBP RT3572 (rev 0x0223), RF RT3052 (MIMO 2T2R), address > 60:a4:4c:ec:c9:a5 > run0: firmware RT3071 ver. 0.33 loaded > > #root@imx6:~ # ifconfig wlan0 > wlan0: flags=3D8843 metric 0 mtu = 1500 > ether 60:a4:4c:ec:c9:a5 > hwaddr 60:a4:4c:ec:c9:a5 > inet 192.168.2.62 netmask 0xffffff00 broadcast 192.168.2.255 > groups: wlan > ssid Haleys_DownStairs channel 8 (2447 MHz 11g) bssid ac:9e:17:67= :85:90 > regdomain FCC country US authmode WPA2/802.11i privacy ON > deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 60 > protmode CTS wme roaming MANUAL > media: IEEE 802.11 Wireless Ethernet DS/1Mbps mode 11g > status: associated > nd6 options=3D29 > > > #amd64 test setup: > russellh@prescott:~% uname -a > FreeBSD prescott.highfell.local 12.0-CURRENT FreeBSD 12.0-CURRENT #66 > ac2f0aa3b(trueos-stable)-dirty: Wed Jun 21 01:09:23 UTC 2017 > root@gauntlet:/usr/obj/usr/src/sys/GENERIC amd64 > > russellh@prescott:~% ifconfig re0 > re0: flags=3D8843 metric 0 mtu > 1500 > options=3D8209b > ether 0c:54:a5:18:c1:5b > hwaddr 0c:54:a5:18:c1:5b > inet6 fe80::e54:a5ff:fe18:c15b%re0 prefixlen 64 scopeid 0x1 > inet 192.168.2.47 netmask 0xffffff00 broadcast 192.168.2.255 > nd6 options=3D23 > media: Ethernet autoselect (100baseTX ) > status: active > > > ---------- Forwarded message ---------- > From: Russell Haley > Date: Sat, Sep 16, 2017 at 10:43 PM > Subject: Re: Beaglebone Black + FreeBSD + USB WiFi =3D WAP? > To: Chris Gordon > > > On Tue, Sep 12, 2017 at 7:00 PM, Chris Gordon wrot= e: >> >>> On Sep 6, 2017, at 8:13 PM, Russell Haley wrote: >>> >>> Argh! I was just in Maryland and we flew home from Dulles!!! I made >>> the client push the date forward to last week so I could be home for >>> Labour Day. >>> >>> Have fun! (sob, sob, sob). ;) >> >> Sorry you missed it. I agree that timing wasn=E2=80=99t great with a ho= liday weekend (for the US at least) on one side and EuroBSDcon very soon af= terward, but constraints on the availability of the hotel drove the exact d= ate. Maybe we can see you in 2019 (we do the conference every other year, = opposite MeetBSD). >> >>>>> I used nuttcp for testing the wired connection, so I would plan to us= e that for the Wifi. >>> >>> nuttcp. Got it, I'll start playing with it. >> >> For the testing described in my original email and the data below, I use= d the most basic options from https://fasterdata.es.net/performance-testing= /network-troubleshooting-tools/nuttcp/. Specifically: >> >> Server: >> nuttcp -S >> >> Client: >> nuttcp -i1 server_hostname >> and >> nuttcp -i1 -r server_hostname >> > nuttcp client only runs for a maybe 10 requests (it varies) and then stop= s? > > root@imx6:~ # nuttcp -i1 -r prescott > 0.9375 MB / 1.01 sec =3D 7.8054 Mbps > 1.0000 MB / 0.99 sec =3D 8.4466 Mbps > 0.9375 MB / 1.00 sec =3D 7.8644 Mbps > 0.9375 MB / 1.00 sec =3D 7.8643 Mbps > 0.9375 MB / 1.05 sec =3D 7.4824 Mbps > 0.9375 MB / 0.95 sec =3D 8.2873 Mbps > 0.9375 MB / 1.00 sec =3D 7.8643 Mbps > 1.0625 MB / 1.00 sec =3D 8.9129 Mbps > 0.9375 MB / 1.00 sec =3D 7.8640 Mbps > 0.8750 MB / 1.00 sec =3D 7.3403 Mbps > > 9.6159 MB / 10.19 sec =3D 7.9151 Mbps 0 %TX 2 %RX 0 host-retrans > 2.19 msRTT > > This is true with both my host (amd64 TrueOS/FBSD 12-Current) and my > humingboard (imx6 12-current). I tried to force it with -n 1000 and > got maybe 20 requests. Verbose didn't tell me anything about why it > stopped. > > I also can't connect to wpa_cli? Error: > > % wpa_cli > wpa_cli v2.5 > Copyright (c) 2004-2015, Jouni Malinen and contributors > > This software may be distributed under the terms of the BSD > license. > See README for more details. > > > > Interactive mode > > Could not connect to wpa_supplicant: (nil) - re-trying > ^c > > The interweb says on Linux I need to adjust my wpa_supplicant.conf so > I will try that. > > I'm having trouble sifting all the emails so I apologise if you've > already answered this. Have you done a tcpdump capture of the system > and checked if there is anything telling in the transmissions? If I > remember correctly you can roll the file output to make it digestible. > I've used sshfs once on Linux to transfer to a host computer that had > more storage (perhaps over serial would reduce test-effect on the > unit?), but sd cards are nice and big now. > > Night, > > Russ > > >>>>> - Can you run the bbb as a standard device (not an access point) and >>>>> test the performance of the wlan0 interface using the method of >>>>> measurement pointed above? I will do the same at some point with my >>>>> wi-fi dongle. >>>> >>>> Yes, that should be easy to do, but will be next week before I have a = chance. >> >> I did the above -- setup the BBB as a simple WiFi client to my existing = (ancient) access point. I ran nuttcp between the BBB and my desktop (wired= network, access point connected to same wired network). Both the BBBB and= desktop were run as server and client for nuttcp. Many runs of the variou= s combinations were run. I saw the following: >> - In general between 10 and 20 Mbps, typically on the lower side. This = is consistent for what I see for other devices going to my access point (ag= ain, it=E2=80=99s an old access point, circa 2008, so I don=E2=80=99t expec= t too much from it) >> - I did have one period of slow traffic, 1 Mbps and lower. After a few= runs of this, I did a =E2=80=9Cservice netif restart=E2=80=9D, dealt with = pets for a couple of minutes and when I returned performance was back. >> - I just hit another period of slow traffic, but this is around 2.5 Mbps= instead of the really bad < 1 Mbps. Instead of resetting the network, I= =E2=80=99m going to let the BBB sit until morning and test again then. I = did test my iPad with a speed test app and it=E2=80=99s getting a little mo= re than 10 Mbps to the internet through the same access point that the BBB = is using. >> >> I=E2=80=99ll follow up with what I see in the morning. My theories at = this time (neither very good) are: >> >> - There is a lot of wifi congestion around me and when others are heavil= y using their wifi, I suffer. This is exacerbated by something about the u= sb wifi NIC I have in the BBB. This doesn=E2=80=99t impact the iPad or oth= er devices due to differences in antennae or some other aspect of their dev= ices. This idea doesn=E2=80=99t quite fit with everything, but a guess. >> - There is something in kernel or wireless stack that degrades over time= /amount of traffic passed that ends up limiting performance. >> >> Thanks, >> Chris >> From owner-freebsd-arm@freebsd.org Wed Sep 20 07:32:22 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E8B8E27DDF for ; Wed, 20 Sep 2017 07:32:22 +0000 (UTC) (envelope-from unto.foru13@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D3F48F5 for ; Wed, 20 Sep 2017 07:32:21 +0000 (UTC) (envelope-from unto.foru13@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id i189so4536069wmf.1 for ; Wed, 20 Sep 2017 00:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jcwOKfXzrT95+bvurdnq/6iU6dzZqJkuExb5ya/hSwU=; b=ZOsUmw2ETZDf3EdpmmfCVAyEBuJLmDph5uXAbD8lC8x0QBa9qfLs9IHHyjcefmJw8c qsunY3y+EI7Qe0gq4sVfeUm+dMS7Sn43jz70XQdT9ceB6y22OEOr6o/v0O3NS4F6GWWO DDvbo30cpY4SOjyQcrjYfqKoOJU6t1MJ0XYFdj6hxbdvWEONtJ8kkeOuDWVaOcefgHPi iXABIyoyCtAYJ/7TAYm4KK1Zu5AfSICVcwSuL3lzBgazVNuNmgLIRFJn2ZkqHpwvEh3T 2mArwnA6HG0j9XjATIqmMptbBUfhaEZxEw3acIVgttglpWot3v/3IIkC2fggwr3mj6H1 tbfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jcwOKfXzrT95+bvurdnq/6iU6dzZqJkuExb5ya/hSwU=; b=ZPNyqASjJmQ46Nqt+h5quvjR58o5nqr/2Pttuju6pN+nDKFxH0rULfiXHYy0ZYoFeF hI5cpDoeStEkI0Jf4keuZ/bfJoaVFToJ7B3E+m7mmTygkabyEGOnrLwxpc8r6sOQNirY OKKcl0zazWy+ft1KbEazFPq93Jc9iB0Iogo29OP6tw4mJuoPNj3xy3bgcsr3sNx6nasD u1vC4d0QM9rJe8wrFEELL+u1yasPNOnlPZ+Jh9TnXuYwgokaFzomid5iA+BZmefSEMCU h8CGkJiUtzrvWa20LWlGt2wxn424vXw+BhICG8X5LsC0c7U/kwe1Ubt3lASX4xF0NHRF BN6g== X-Gm-Message-State: AHPjjUgFPTGzQmHW9KHPJ3W097imfkjm/whr6KrXCNntTiaLrbT+r39N xHURdWvOdkKc1pHrfNgiePnV0sfl9WCpWJK7h/rBIg== X-Google-Smtp-Source: AOwi7QAeTpiZXVi+Kvb8VFoL7bR4SWnPvXuxf9d9y2IakCOLFMHcqGuKJbxaT920DxTjgTMKpJy9A9phKsQHQWlsKH8= X-Received: by 10.80.146.194 with SMTP id l2mr3871405eda.71.1505892738993; Wed, 20 Sep 2017 00:32:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.204.6 with HTTP; Wed, 20 Sep 2017 00:32:18 -0700 (PDT) In-Reply-To: <20170914134321.9873e02f3d9937e0a6fe4b46@bidouilliste.com> References: <20170914134321.9873e02f3d9937e0a6fe4b46@bidouilliste.com> From: =?UTF-8?B?6Zi/6YeR?= Date: Wed, 20 Sep 2017 15:32:18 +0800 Message-ID: Subject: Re: how to build GENERIC kernel for orange pi To: Emmanuel Vadot Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 07:32:22 -0000 Hi everybody, According to https://www.bsdcan.org/2017/schedule/events/833.en.html, seem need a specific source to compile GENERIC arm kernel?(if that's true,where could I download those specific sources?) I fetch source from here fetch http://ftp.freebsd.org/pub/FreeBSD/releases/i386/11.1-RELEASE/ make TARGET=arm TARGET_ARCH=armv6 SRCCONF=/dev/null __MAKE_CONF=/dev/null buildworld <---ok make TARGET=arm TARGET_ARCH=armv6 SRCCONF=/dev/null __MAKE_CONF=/dev/null KERNCONF=ALLWINNER buildkernel <--ok but make TARGET=arm TARGET_ARCH=armv6 SRCCONF=/dev/null __MAKE_CONF=/dev/null KERNCONF=GENERIC buildkernel make[1]: "/opt/11stable/usr/src/Makefile.inc1" line 158: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler. ERROR: Missing kernel configuration file(s) (GENERIC). *** Error code 1 Stop. make[1]: stopped in /opt/11stable/usr/src *** Error code 1 Stop. make: stopped in /opt/11stable/usr/src my compile environment uname -v FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 04:10:47 UTC 2017 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC Unto thanks help 2017-09-14 19:43 GMT+08:00 Emmanuel Vadot : > On Thu, 14 Sep 2017 14:45:28 +0800 > ?? wrote: > > > Date: Sun, 25 Jun 2017 13:21:06 +0200 > > From: Emmanuel Vadot > > To: Johnny Sorocil > > Cc: freebsd-arm@freebsd.org > > > > > Steps to reproduce: > > > rm -rf /usr/obj > > > make -j4 TARGET_ARCH=armv6 SRCCONF=/dev/null __MAKE_CONF=/dev/null > > > buildworld > > > make -j4 TARGET_ARCH=armv6 SRCCONF=/dev/null __MAKE_CONF=/dev/null > > > KERNCONF=ALLWINNER buildkernel > > > make -j4 TARGET_ARCH=armv6 SRCCONF=/dev/null __MAKE_CONF=/dev/null > > > KERNCONF=ALLWINNER DESTDIR=/mnt/sd2/ installkernel > > > make -j4 TARGET_ARCH=armv6 SRCCONF=/dev/null __MAKE_CONF=/dev/null > > > KERNCONF=ALLWINNER DESTDIR=/mnt/sd2/ installworld > > > > You should use the GENERIC kernel, I'll remove ALLWINNER as it's not > > needed anymore. > > > > ------------------------------------------------------------ > --------------------- > > But I use GENERIC kernel config get errors below > > > > #make TARGET_ARCH=armv6 SRCCONF=/dev/null __MAKE_CONF=/dev/null > > KERNCONF=GENERIC buildkernel > > > > make[1]: "/usr/src/Makefile.inc1" line 158: SYSTEM_COMPILER: Determined > > that CC=cc matches the source tree. Not bootstrapping a cross-compiler. > > ERROR: Missing kernel configuration file(s) (GENERIC). > > *** Error code 1 > > > > Stop. > > make[1]: stopped in /usr/src > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/src > > > > Thanks help. > > Hello, > > You need to set TARGET=arm too. > The real target for armv6 is arm.armv6. > > Cheers, > > -- > Emmanuel Vadot > From owner-freebsd-arm@freebsd.org Wed Sep 20 08:00:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B015CE013B7 for ; Wed, 20 Sep 2017 08:00:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E3D816CC for ; Wed, 20 Sep 2017 08:00:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20599 invoked from network); 20 Sep 2017 08:00:04 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 20 Sep 2017 08:00:04 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Wed, 20 Sep 2017 04:00:04 -0400 (EDT) Received: (qmail 8254 invoked from network); 20 Sep 2017 08:00:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Sep 2017 08:00:03 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 3DB60EC7925; Wed, 20 Sep 2017 01:00:03 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: how to build GENERIC kernel for orange pi Date: Wed, 20 Sep 2017 01:00:02 -0700 References: <20170914134321.9873e02f3d9937e0a6fe4b46@bidouilliste.com> To: =?utf-8?B?6Zi/6YeR?= , "freebsd-arm@freebsd.org" In-Reply-To: Message-Id: <945AE03C-69A9-4ABD-98EB-78CF3A599D63@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 08:00:06 -0000 On 2017-Sep-20, at 12:32 AM, =E9=98=BF=E9=87=91 = wrote: > Hi everybody, >=20 > According to https://www.bsdcan.org/2017/schedule/events/833.en.html, > seem need a specific source to compile GENERIC arm kernel?(if that's > true,where could I download those specific sources?) > I fetch source from here > fetch http://ftp.freebsd.org/pub/FreeBSD/releases/i386/11.1-RELEASE/ >=20 > make TARGET=3Darm TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null = __MAKE_CONF=3D/dev/null > buildworld <---ok >=20 > make TARGET=3Darm TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null = __MAKE_CONF=3D/dev/null > KERNCONF=3DALLWINNER buildkernel <--ok >=20 > but > make TARGET=3Darm TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null = __MAKE_CONF=3D/dev/null > KERNCONF=3DGENERIC buildkernel > make[1]: "/opt/11stable/usr/src/Makefile.inc1" line 158: = SYSTEM_COMPILER: > Determined that CC=3Dcc matches the source tree. Not bootstrapping a > cross-compiler. > ERROR: Missing kernel configuration file(s) (GENERIC). > *** Error code 1 >=20 > Stop. > make[1]: stopped in /opt/11stable/usr/src > *** Error code 1 >=20 > Stop. > make: stopped in /opt/11stable/usr/src https://svnweb.freebsd.org/base/release/11.1.0/sys/arm/conf/ does not have a GENERIC configuration file. Nor does: https://svnweb.freebsd.org/base/stable/11/sys/arm/conf/ GENERIC for TARGET_ARCH=3Darmv6 is newer and is only in/for: https://svnweb.freebsd.org/base/head/ so far. I do not know if it will ever be merged back to stable/11 or not. > my compile environment > uname -v > FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 04:10:47 UTC 2017 > root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC >=20 > Unto >=20 > thanks help >=20 > 2017-09-14 19:43 GMT+08:00 Emmanuel Vadot : >=20 >> On Thu, 14 Sep 2017 14:45:28 +0800 >> ?? wrote: >>=20 >>> Date: Sun, 25 Jun 2017 13:21:06 +0200 >>> From: Emmanuel Vadot >>> To: Johnny Sorocil >>> Cc: freebsd-arm@freebsd.org >>>=20 >>>> Steps to reproduce: >>>> rm -rf /usr/obj >>>> make -j4 TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null = __MAKE_CONF=3D/dev/null >>>> buildworld >>>> make -j4 TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null = __MAKE_CONF=3D/dev/null >>>> KERNCONF=3DALLWINNER buildkernel >>>> make -j4 TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null = __MAKE_CONF=3D/dev/null >>>> KERNCONF=3DALLWINNER DESTDIR=3D/mnt/sd2/ installkernel >>>> make -j4 TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null = __MAKE_CONF=3D/dev/null >>>> KERNCONF=3DALLWINNER DESTDIR=3D/mnt/sd2/ installworld >>>=20 >>> You should use the GENERIC kernel, I'll remove ALLWINNER as it's not >>> needed anymore. I think that the above reply was implicitly referencing head (12) only for GENERIC, not even stable/11 . So source code based on: https://svnweb.freebsd.org/base/head/ >>> ------------------------------------------------------------ >> --------------------- >>> But I use GENERIC kernel config get errors below >>>=20 >>> #make TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null __MAKE_CONF=3D/dev/null >>> KERNCONF=3DGENERIC buildkernel >>>=20 >>> make[1]: "/usr/src/Makefile.inc1" line 158: SYSTEM_COMPILER: = Determined >>> that CC=3Dcc matches the source tree. Not bootstrapping a = cross-compiler. >>> ERROR: Missing kernel configuration file(s) (GENERIC). >>> *** Error code 1 >>>=20 >>> Stop. >>> make[1]: stopped in /usr/src >>> *** Error code 1 >>>=20 >>> Stop. >>> make: stopped in /usr/src >>>=20 >>> Thanks help. >>=20 >> Hello, >>=20 >> You need to set TARGET=3Darm too. >> The real target for armv6 is arm.armv6. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Sep 20 10:45:52 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB843E08020 for ; Wed, 20 Sep 2017 10:45:52 +0000 (UTC) (envelope-from chris@theory14.net) Received: from bacon.theory14.net (bacon.theory14.net [45.55.200.27]) by mx1.freebsd.org (Postfix) with ESMTP id C826B66200 for ; Wed, 20 Sep 2017 10:45:52 +0000 (UTC) (envelope-from chris@theory14.net) Received: from remote.theory14.net (remote.theory14.net [173.79.116.36]) by bacon.theory14.net (Postfix) with ESMTPSA id 3EAC2125ECA; Wed, 20 Sep 2017 06:45:46 -0400 (EDT) Received: from anubis.int.theory14.net (anubis.int.theory14.net [192.168.10.50]) by remote.theory14.net (Postfix) with ESMTPS id F006C6815; Wed, 20 Sep 2017 06:45:45 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Unexpected Results from nuttcp testing wifi on arm From: Chris Gordon In-Reply-To: Date: Wed, 20 Sep 2017 06:45:45 -0400 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <7BCF4E27-E82F-4192-9660-E9F822C6E5A7@theory14.net> References: To: Russell Haley X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 10:45:53 -0000 Not that it=E2=80=99s a good control experiment, but I found a CLI = version of the internet speed tests = (https://github.com/sivel/speedtest-cli)*. It generated similar results = as to using nuttcp against a desktop (wired) on my network indicating = that the BBB was the limiting device. Chris * Requires python and a couple of other packages to build/install. > On Sep 20, 2017, at 2:07 AM, Russell Haley = wrote: >=20 > Hi, >=20 > So I am consistently getting very low throughput when testing with > nuttcp if I use my arm board as the client. If the desktop is the > client, I am averaging ~8 Mbps. When my arm board is the client, I get > an average of just over 1 Mbps. This doesn't seem right to me. Any > input or confirmation that this is incorrect would be grand. My > assumption is I have done something wrong. :-/ >=20 > Russ >=20 > On Sat, Sep 16, 2017 at 11:18 PM, Russell Haley = wrote: >> Hi, >>=20 >> Well I WAS going to bed and then I looked at the results of my = testing >> for the BBB/wifi stuff. This is NOT on a BBB and I have a different >> wifi adapter so I started a new post. >>=20 >> When testing wifi on my imx6 (hummingboard) I get drastically >> different results depending on which side is the client or the = server. >>=20 >> Host =3D amd64 TrueOS wired 100Mbps >> Target =3D imx6 FBSD 12 wifi (MAC/BBP RT3572 ) >>=20 >>=20 >> amd64 (wired) client -> imx6 Server >> russellh@prescott:~% nuttcp -n 1000 -v -i1 192.168.2.62 > = /tmp/prescott1.out >> http://termbin.com/7o1w >> #Summary: >> nuttcp-t: 62.5000 MB in 60.77 real seconds =3D 1053.13 KB/sec =3D = 8.6273 Mbps >>=20 >> ----------------------------------------------------------- >>=20 >> imx6 client -> amd64 (wired) Server >> root@imx6:~ # nuttcp -i 1 -v -n 1000 prescott > /tmp/out.txt >>=20 >> http://termbin.com/8vvh >> #Summary: >> nuttcp-t: 9.0000 MB in 108.96 real seconds =3D 84.58 KB/sec =3D = 0.6929 Mbps >>=20 >> Is this abnormal? (Please say yes!) >>=20 >> Russ (more setup details below) >>=20 >>=20 >> IMX6 test setup: >>=20 >> root@imx6:~ # uname -a >> FreeBSD imx6 12.0-CURRENT FreeBSD 12.0-CURRENT #13 r321601M: Thu Sep >> 14 20:43:21 PDT 2017 >> = russellh@prescott.highfell.local:/usr/home/russellh/FreeBSD/rh-armv6/obj/a= rm.armv6/usr/home/russellh/FreeBSD/rh-armv6/src/sys/IMX6 >> arm >>=20 >> root@imx6:~ # dmesg | grep run0 >> run0 on uhub2 >> run0: <1.0> on usbus1 >> run0: MAC/BBP RT3572 (rev 0x0223), RF RT3052 (MIMO 2T2R), address >> 60:a4:4c:ec:c9:a5 >> run0: firmware RT3071 ver. 0.33 loaded >>=20 >> #root@imx6:~ # ifconfig wlan0 >> wlan0: flags=3D8843 metric 0 = mtu 1500 >> ether 60:a4:4c:ec:c9:a5 >> hwaddr 60:a4:4c:ec:c9:a5 >> inet 192.168.2.62 netmask 0xffffff00 broadcast 192.168.2.255 >> groups: wlan >> ssid Haleys_DownStairs channel 8 (2447 MHz 11g) bssid = ac:9e:17:67:85:90 >> regdomain FCC country US authmode WPA2/802.11i privacy ON >> deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid = 60 >> protmode CTS wme roaming MANUAL >> media: IEEE 802.11 Wireless Ethernet DS/1Mbps mode 11g >> status: associated >> nd6 options=3D29 >>=20 >>=20 >> #amd64 test setup: >> russellh@prescott:~% uname -a >> FreeBSD prescott.highfell.local 12.0-CURRENT FreeBSD 12.0-CURRENT #66 >> ac2f0aa3b(trueos-stable)-dirty: Wed Jun 21 01:09:23 UTC 2017 >> root@gauntlet:/usr/obj/usr/src/sys/GENERIC amd64 >>=20 >> russellh@prescott:~% ifconfig re0 >> re0: flags=3D8843 metric 0 = mtu >> 1500 >> = options=3D8209b >> ether 0c:54:a5:18:c1:5b >> hwaddr 0c:54:a5:18:c1:5b >> inet6 fe80::e54:a5ff:fe18:c15b%re0 prefixlen 64 scopeid 0x1 >> inet 192.168.2.47 netmask 0xffffff00 broadcast 192.168.2.255 >> nd6 options=3D23 >> media: Ethernet autoselect (100baseTX ) >> status: active >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: Russell Haley >> Date: Sat, Sep 16, 2017 at 10:43 PM >> Subject: Re: Beaglebone Black + FreeBSD + USB WiFi =3D WAP? >> To: Chris Gordon >>=20 >>=20 >> On Tue, Sep 12, 2017 at 7:00 PM, Chris Gordon = wrote: >>>=20 >>>> On Sep 6, 2017, at 8:13 PM, Russell Haley = wrote: >>>>=20 >>>> Argh! I was just in Maryland and we flew home from Dulles!!! I made >>>> the client push the date forward to last week so I could be home = for >>>> Labour Day. >>>>=20 >>>> Have fun! (sob, sob, sob). ;) >>>=20 >>> Sorry you missed it. I agree that timing wasn=E2=80=99t great with = a holiday weekend (for the US at least) on one side and EuroBSDcon very = soon afterward, but constraints on the availability of the hotel drove = the exact date. Maybe we can see you in 2019 (we do the conference = every other year, opposite MeetBSD). >>>=20 >>>>>> I used nuttcp for testing the wired connection, so I would plan = to use that for the Wifi. >>>>=20 >>>> nuttcp. Got it, I'll start playing with it. >>>=20 >>> For the testing described in my original email and the data below, I = used the most basic options from = https://fasterdata.es.net/performance-testing/network-troubleshooting-tool= s/nuttcp/. Specifically: >>>=20 >>> Server: >>> nuttcp -S >>>=20 >>> Client: >>> nuttcp -i1 server_hostname >>> and >>> nuttcp -i1 -r server_hostname >>>=20 >> nuttcp client only runs for a maybe 10 requests (it varies) and then = stops? >>=20 >> root@imx6:~ # nuttcp -i1 -r prescott >> 0.9375 MB / 1.01 sec =3D 7.8054 Mbps >> 1.0000 MB / 0.99 sec =3D 8.4466 Mbps >> 0.9375 MB / 1.00 sec =3D 7.8644 Mbps >> 0.9375 MB / 1.00 sec =3D 7.8643 Mbps >> 0.9375 MB / 1.05 sec =3D 7.4824 Mbps >> 0.9375 MB / 0.95 sec =3D 8.2873 Mbps >> 0.9375 MB / 1.00 sec =3D 7.8643 Mbps >> 1.0625 MB / 1.00 sec =3D 8.9129 Mbps >> 0.9375 MB / 1.00 sec =3D 7.8640 Mbps >> 0.8750 MB / 1.00 sec =3D 7.3403 Mbps >>=20 >> 9.6159 MB / 10.19 sec =3D 7.9151 Mbps 0 %TX 2 %RX 0 = host-retrans >> 2.19 msRTT >>=20 >> This is true with both my host (amd64 TrueOS/FBSD 12-Current) and my >> humingboard (imx6 12-current). I tried to force it with -n 1000 and >> got maybe 20 requests. Verbose didn't tell me anything about why it >> stopped. >>=20 >> I also can't connect to wpa_cli? Error: >>=20 >> % wpa_cli >> wpa_cli v2.5 >> Copyright (c) 2004-2015, Jouni Malinen and contributors >>=20 >> This software may be distributed under the terms of the BSD >> license. >> See README for more details. >>=20 >>=20 >>=20 >> Interactive mode >>=20 >> Could not connect to wpa_supplicant: (nil) - re-trying >> ^c >>=20 >> The interweb says on Linux I need to adjust my wpa_supplicant.conf so >> I will try that. >>=20 >> I'm having trouble sifting all the emails so I apologise if you've >> already answered this. Have you done a tcpdump capture of the system >> and checked if there is anything telling in the transmissions? If I >> remember correctly you can roll the file output to make it = digestible. >> I've used sshfs once on Linux to transfer to a host computer that had >> more storage (perhaps over serial would reduce test-effect on the >> unit?), but sd cards are nice and big now. >>=20 >> Night, >>=20 >> Russ >>=20 >>=20 >>>>>> - Can you run the bbb as a standard device (not an access point) = and >>>>>> test the performance of the wlan0 interface using the method of >>>>>> measurement pointed above? I will do the same at some point with = my >>>>>> wi-fi dongle. >>>>>=20 >>>>> Yes, that should be easy to do, but will be next week before I = have a chance. >>>=20 >>> I did the above -- setup the BBB as a simple WiFi client to my = existing (ancient) access point. I ran nuttcp between the BBB and my = desktop (wired network, access point connected to same wired network). = Both the BBBB and desktop were run as server and client for nuttcp. = Many runs of the various combinations were run. I saw the following: >>> - In general between 10 and 20 Mbps, typically on the lower side. = This is consistent for what I see for other devices going to my access = point (again, it=E2=80=99s an old access point, circa 2008, so I don=E2=80= =99t expect too much from it) >>> - I did have one period of slow traffic, 1 Mbps and lower. After a = few runs of this, I did a =E2=80=9Cservice netif restart=E2=80=9D, dealt = with pets for a couple of minutes and when I returned performance was = back. >>> - I just hit another period of slow traffic, but this is around 2.5 = Mbps instead of the really bad < 1 Mbps. Instead of resetting the = network, I=E2=80=99m going to let the BBB sit until morning and test = again then. I did test my iPad with a speed test app and it=E2=80=99s = getting a little more than 10 Mbps to the internet through the same = access point that the BBB is using. >>>=20 >>> I=E2=80=99ll follow up with what I see in the morning. My theories = at this time (neither very good) are: >>>=20 >>> - There is a lot of wifi congestion around me and when others are = heavily using their wifi, I suffer. This is exacerbated by something = about the usb wifi NIC I have in the BBB. This doesn=E2=80=99t impact = the iPad or other devices due to differences in antennae or some other = aspect of their devices. This idea doesn=E2=80=99t quite fit with = everything, but a guess. >>> - There is something in kernel or wireless stack that degrades over = time/amount of traffic passed that ends up limiting performance. >>>=20 >>> Thanks, >>> Chris >>>=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Sep 20 15:59:44 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB455E14C4E for ; Wed, 20 Sep 2017 15:59:44 +0000 (UTC) (envelope-from carlj@peak.org) Received: from filter03.peak.org (filter03.peak.org [207.55.16.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82DAE70363 for ; Wed, 20 Sep 2017 15:59:44 +0000 (UTC) (envelope-from carlj@peak.org) Received: from zmail-mta02.peak.org ([207.55.16.112]) by filter03.peak.org ({a3d4bcbc-467e-4baf-8e5e-c89ccb4fcca2}) via TCP (outbound) with ESMTPS id 20170920155608675_0000 for ; Wed, 20 Sep 2017 08:56:08 -0700 X-RC-FROM: X-RC-RCPT: Received: from zmail-mta02.peak.org (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTPS id 8A7874CD30 for ; Wed, 20 Sep 2017 08:56:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTP id 712974CE79 for ; Wed, 20 Sep 2017 08:56:07 -0700 (PDT) Received: from zmail-mta02.peak.org ([127.0.0.1]) by localhost (zmail-mta02.peak.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8f3p7UMhZUcS for ; Wed, 20 Sep 2017 08:56:07 -0700 (PDT) Received: from mailproxy-lb-07.peak.org (mailproxy-lb-07.peak.org [207.55.17.97]) by zmail-mta02.peak.org (Postfix) with ESMTP id 272A14CDA1 for ; Wed, 20 Sep 2017 08:56:07 -0700 (PDT) Received: from carlj by elm.localnet with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1duhM5-000JMA-O4 for freebsd-arm@freebsd.org; Wed, 20 Sep 2017 08:56:05 -0700 From: Carl Johnson To: freebsd-arm@freebsd.org Subject: Re: Unexpected Results from nuttcp testing wifi on arm References: X-Clacks-Overhead: GNU Terry Pratchett Date: Wed, 20 Sep 2017 08:56:05 -0700 In-Reply-To: (Russell Haley's message of "Tue, 19 Sep 2017 23:07:01 -0700") Message-ID: <86tvzxs6sq.fsf@elm.localnet> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-MAG-OUTBOUND: peakinternet.redcondor.net@207.55.16/22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 15:59:44 -0000 Russell Haley writes: > Hi, > > So I am consistently getting very low throughput when testing with > nuttcp if I use my arm board as the client. If the desktop is the > client, I am averaging ~8 Mbps. When my arm board is the client, I get > an average of just over 1 Mbps. This doesn't seem right to me. Any > input or confirmation that this is incorrect would be grand. My > assumption is I have done something wrong. :-/ > > Russ I find that some USB adapter have asymmetric speeds, similar to what you are seeing. I use iperf3 and get relatively symmetric speeds with a RTL8188EU, but not with a RTL8188CUS. With the RTL8188CUS I see about 20Mb/sec send and 1Mb/sec receive. The RTL8188EU gets about 19Mb/sec send and about 21Mb/sec receive. I hope this helps a little, but I don't know anything more than my observations. -- Carl Johnson carlj@peak.org From owner-freebsd-arm@freebsd.org Thu Sep 21 02:25:50 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13AC2E0AD9C for ; Thu, 21 Sep 2017 02:25:50 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CC23763E64 for ; Thu, 21 Sep 2017 02:25:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v8L1uLl2055187 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Sep 2017 18:56:22 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v8L1uLcQ055186; Wed, 20 Sep 2017 18:56:21 -0700 (PDT) (envelope-from fbsd) Date: Wed, 20 Sep 2017 18:56:21 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: pmap_fault: PT2MAP abort on rpi2 while building world Message-ID: <20170921015621.GA55155@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 02:25:50 -0000 Several times now buildworld attempts have crashed with pmap_fault: PT2MAP abort. It started several weeks ago and has been happening intermittently ever since. So far it's only occurred during buildworld, not other compilations such as firefox (which still fails from porting issues). I couldn't find any recent posts on this error, is it worth a bug report? The information I could gather from the latest crash is at http://www.zefox.net/~fbsd/rpi2/crashes/crash_9_20_17/ Thanks for reading, and any guidance! bob prohaska From owner-freebsd-arm@freebsd.org Thu Sep 21 06:07:10 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F3D7E165D4 for ; Thu, 21 Sep 2017 06:07:10 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4C906B150 for ; Thu, 21 Sep 2017 06:07:09 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id 80so4733225lfy.4 for ; Wed, 20 Sep 2017 23:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NQzSmiHrTOaU+HPjjGJvbLpP74o5oF/l4NaxtmZr6Bg=; b=HzAUJ8UrzQ//uc5tdWmbAP8hxcWOuHUkURQw+wjJMMEhOcaImIAGBExEXNlNEbDRAI NN+yhdrjXvFn2xJELkyBZyPD5wiqHEt8cMNicehk+dI2PwBXpYIw2dPfmoXLQvLouqHd PuOfb8jvyeCnIlfUQtmMg6FKTKl07gg+LZGCfuY6atoWK4a26oNH+qp8wJLW5fJVS1Cd Y4oDoBtffW09n7VdXVrANouWs8uc9E64F0xetCCiQp8aVtbxoM6PUhr880rJF49fsbpr OuTF2imxjFFF9VX3d8UrOiegj65P+VCQsHMVmZ1eDgv1jyF8PvXdM67Vyc8EIQQJEHnX 3esQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NQzSmiHrTOaU+HPjjGJvbLpP74o5oF/l4NaxtmZr6Bg=; b=ZpbCgbEs2KZOJNUaRFOEN0WuqraaKWiDLj8IvLiUqcE8yrilyRR6DlbC/7NP7OfHMS esLy1gpJuh5zOFg+Q9or+WesaDGXTnzxVW0Ajr8WLncYHqndjxqVcqRt5EPYKPur9qmI cq8+pl7G+NUn+ya4DpCyv3sBACHWOh0AOYqZZsEvwvSMCCo/epEFZSKdcqTkPmD4OOUM jLhdourgVO8/ZJ7qFGrY41COA8TAGSo/cB+gwvRs/BxlnzpMPAQK0uJ4iNPo8Oo1kBBB qV7SoYrR1CQL/93uj7VrfVgAdVA3UFhBFOq9JBkn72H0V0ZBzXGt0kL2IXYfsoeqmB3g pBbA== X-Gm-Message-State: AHPjjUg+aArJIkLjrwyqcxWu2LQO1rYLRKt1OGqT6fWRG1WE0SGKwKH2 rVLY1Fta3Ou/8rO+pMEd+nNhX6K86dl5wE9qjy0= X-Google-Smtp-Source: AOwi7QDplztBtMhimQ1de9MbAB4PFg8siKgcvh+nS/2wDsES0Il6QIIESsiHuVCEr/pZFk2z+UtM1IaZWsKID1jQ/48= X-Received: by 10.46.70.10 with SMTP id t10mr454847lja.30.1505974027733; Wed, 20 Sep 2017 23:07:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Wed, 20 Sep 2017 23:07:06 -0700 (PDT) In-Reply-To: <86tvzxs6sq.fsf@elm.localnet> References: <86tvzxs6sq.fsf@elm.localnet> From: Russell Haley Date: Wed, 20 Sep 2017 23:07:06 -0700 Message-ID: Subject: Re: Unexpected Results from nuttcp testing wifi on arm To: Carl Johnson Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 06:07:10 -0000 On Wed, Sep 20, 2017 at 8:56 AM, Carl Johnson wrote: > Russell Haley writes: > >> Hi, >> >> So I am consistently getting very low throughput when testing with >> nuttcp if I use my arm board as the client. If the desktop is the >> client, I am averaging ~8 Mbps. When my arm board is the client, I get >> an average of just over 1 Mbps. This doesn't seem right to me. Any >> input or confirmation that this is incorrect would be grand. My >> assumption is I have done something wrong. :-/ >> >> Russ > > I find that some USB adapter have asymmetric speeds, similar to what you > are seeing. I use iperf3 and get relatively symmetric speeds with a > RTL8188EU, but not with a RTL8188CUS. With the RTL8188CUS I see about > 20Mb/sec send and 1Mb/sec receive. The RTL8188EU gets about 19Mb/sec > send and about 21Mb/sec receive. I hope this helps a little, but I > don't know anything more than my observations. Very helpful in validating that I haven't done something drastically wrong. Thank you. Russ > -- > Carl Johnson carlj@peak.org > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Thu Sep 21 06:23:10 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 137DBE1712D for ; Thu, 21 Sep 2017 06:23:10 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A0F36B91E for ; Thu, 21 Sep 2017 06:23:08 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 279bebbd; Thu, 21 Sep 2017 08:23:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=MFs99ZYDxrPgyQHrLAVzX86+7Kw=; b=m34CoiBFVgHXI2U1+CpKFO8IV7Ze FXRgwHVrWhoDMcQoQD5C+whsRwGt364kBTgRrhomV5BMyILj1CAJqAIdszWx/bNu xWqX92R08BwprXC/HO0icHXDPM+asiJ2WyE1zOneO20HDws/V/v70HBme6A+JlRp U6A/tw3P902+6MM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=L9uD/FmnPsWNaeWD0jwUxA9z/HlkRNjWf1Lxw6VVBVJWVWa5/Y5EjvYV EYK4NesHfJkb1HNEEfQGxYq5j6vsTL9CfV/goGcb4h7iU4gFrbJtaEcc48VapHSD NnYjJbQYzSKUCsK24CTIM0MsitaCYrIDT4YpdRLhKvkQTe23Cys= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id dc9405aa TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 21 Sep 2017 08:23:00 +0200 (CEST) Date: Thu, 21 Sep 2017 08:22:59 +0200 From: Emmanuel Vadot To: Michael Hrabanek Cc: freebsd-arm@freebsd.org Subject: Re: Allwinner H3 (NanoPi Neo): Getting PORTL (on /dev/gpioc1) to work Message-Id: <20170921082259.aa46e554e653ce7bf2d403b2@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 06:23:10 -0000 On Tue, 19 Sep 2017 09:45:22 +0200 Michael Hrabanek wrote: > Hi everybody, > I'm running 12.0-CURRENT (rev 323710) using GENERIC kernel on NanoPi Neo > (allwinner H3). I can use and control all gpio pins on /dev/gpioc0 without > any issue, but if I try to configure any pin on /dev/gpioc1 (there are only > PORTL pins there), nothing happens (pin configuration stays the same, > gpioctl returns 0 and no error in log). > > root@nanopi-neo:~ # gpioctl -f /dev/gpioc1 -lv > pin 00: 0 PL0, caps: > pin 01: 0 PL1, caps: > pin 02: 0 PL2<>, caps: > pin 03: 0 PL3<>, caps: > pin 04: 0 PL4<>, caps: > pin 05: 0 PL5<>, caps: > pin 06: 0 PL6<>, caps: > pin 07: 0 PL7<>, caps: > pin 08: 0 PL8<>, caps: > pin 09: 0 PL9<>, caps: > pin 10: 0 PL10<>, caps: > pin 11: 0 PL11<>, caps: > > root@nanopi-neo:~ # gpioctl -f /dev/gpioc1 -c 10 OUT > > root@nanopi-neo:~ # gpioctl -f /dev/gpioc1 -lv > <...> > pin 10: 0 PL10<>, caps: > pin 11: 0 PL11<>, caps: > > Did anyone managed to get pins on PORTL working? (btw there are two LEDs on > nanopi neo, the blue one on PA10, which I can control normally and the > green (pwr) one, wired to PL10, which only slightly dims (ie. pin is not > configured as output)). > Any idea what's wrong? Is there an issue with FDT config? (I'm using > default one from src nanopi-neo.dtb) Or some bug in kernel? I'm not afraid > of some kernel hacking, but I'd welcome some pointers where to look first. > Any suggestions would be greatly appreciated, > Michael Hello, Thanks for reporting, I totally forgot that I needed to do a r_ccu driver for H3. The PORTL on H3 lives on another gpio controller, for which it's clock lives in another clock controller and we miss the driver for the latest. It also raise a problem on our gpio driver as it shouldn't attach and create the node while the clocks are missing. I'll invastigate after EuroBSDCon. Cheers, -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Sep 21 06:26:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3438E172B5 for ; Thu, 21 Sep 2017 06:26:11 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A9206BA06; Thu, 21 Sep 2017 06:26:10 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 5b8d7571; Thu, 21 Sep 2017 08:26:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=DwGI70uo09SajNBt9h25Oz7yDTc=; b=eBt6gBL+yCzI5ioqlyr8erP1+xtJ G3iij6J0VK27/yeHydPf/dSjgAX502nCUOJQVCxibmhAWqQzPE+tPHf1KgVUd/BM EJn/Z1IZtdO1WfMAvcCA9f+9ra7zneAxRwElH8ITWMpveF9ab/4cxtY8L7ERX8/k 4B9cqU1eyRVhFGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=lCzL3fXI7ixTCfWIzYwpC+pVYQXa+Ltjv3kqPxWMQz/SvQLPD1rmq25U wDHgqCUW4u1qhx3a6Z+yzbi5R0rk3+M4P0nTlEWzNdUWFWqCQJ7if5AEwmw9eOA4 ipXMULtpiEbWa6zZgXrQUUyZ07V93ActhZ9AhT+5ojBRwpjaabQ= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 33bcd313 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 21 Sep 2017 08:26:08 +0200 (CEST) Date: Thu, 21 Sep 2017 08:26:08 +0200 From: Emmanuel Vadot To: Mark Millard Cc: Emmanuel Vadot , freebsd-arm Subject: Re: allwinner question reformulalted: sc->phy_ctrl vs. sc->pmu[phyno], which should be used with PMU_UNK_H3 and PMU_UNK_H3_CLR? (sc->phy_ctrl actually used currently) Message-Id: <20170921082608.5e892da463226e8a80c032a8@bidouilliste.com> In-Reply-To: <3EFEF9A2-774E-4321-ABF0-49C1CD52ECFB@dsl-only.net> References: <5830ABC8-6544-4588-BDB6-483C2D1B3D3E@dsl-only.net> <3EFEF9A2-774E-4321-ABF0-49C1CD52ECFB@dsl-only.net> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 06:26:11 -0000 On Tue, 19 Sep 2017 10:51:46 -0700 Mark Millard wrote: > The modern, updated sys/arm/allwinner/aw_usbphy.c code uses > PMU_UNK_H3 and PMU_UNK_H3_CLR with sc->phy_ctrl : > > if (sc->phy_conf->pmu_unk1 == true) > CLR4(sc->phy_ctrl, PMU_UNK_H3, PMU_UNK_H3_CLR); This is a mistake, it should write using sc->pmu[phyno] as base, I'll correct that soon. > but uses sc->pmu[phyno] for PMU_IRQ_ENABLE and: > > PMU_ULPI_BYPASS | PMU_AHB_INCR8 | PMU_AHB_INCR4 | PMU_AHB_INCRX_ALIGN > > in: > SET4(sc->pmu[phyno], PMU_IRQ_ENABLE, PMU_ULPI_BYPASS | > PMU_AHB_INCR8 | PMU_AHB_INCR4 | PMU_AHB_INCRX_ALIGN); > > Having PMU_ not used with sc->pmu[phyno] looks a little odd. > > > For reference: the older code used: > > if (sc->phy_type == AWUSBPHY_TYPE_A64) { > CLR4(sc, phyno, PMU_UNK_H3, PMU_UNK_H3_CLR); > > and: > > if (phyno > 0) { > /* Enable passby */ > SET4(sc, phyno, PMU_IRQ_ENABLE, PMU_ULPI_BYPASS | > PMU_AHB_INCR8 | PMU_AHB_INCR4 | PMU_AHB_INCRX_ALIGN); > } > > > where: that involved use of: > > (sc)->res[(phyno)] > > via: > > #define RD4(sc, i, o) bus_read_4((sc)->res[(i)], (o)) > #define WR4(sc, i, o, v) bus_write_4((sc)->res[(i)], (o), (v)) > #define CLR4(sc, i, o, m) WR4(sc, i, o, RD4(sc, i, o) & ~(m)) > #define SET4(sc, i, o, m) WR4(sc, i, o, RD4(sc, i, o) | (m)) > > > === > Mark Millard > markmi at dsl-only.net > > On 2017-Sep-18, at 1:42 PM, Mark Millard wrote: > > > On 2017-Sep-18, at 1:30 PM, Mark Millard wrote: > > > It probably just my ignorance of the code's intent > > but for A64 it used to be that phyno ==1 had code > > that did CLR4 for phyno==0 (hard coded): > > > > if (sc->phy_type == AWUSBPHY_TYPE_A64) { > > CLR4(sc, phyno, PMU_UNK_H3, PMU_UNK_H3_CLR); > > > > /* EHCI0 and OTG share a PHY */ > > if (phyno == 0) > > SET4(sc, 0, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); > > else if (phyno == 1) > > CLR4(sc, 0, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); > > } > > > > So: that last CLR4 manipulated phyno==0 as far as I can tell, > > no matter what the passed-in phyno was. > > > > In the new code there seems to be no hook for phyno==1 > > to manipulate phyno==0 similarly: > > > > if (sc->phy_conf->phy0_route == true) { > > if (phyno == 0) > > SET4(sc->phy_ctrl, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); > > else > > CLR4(sc->phy_ctrl, OTG_PHY_CFG, OTG_PHY_ROUTE_OTG); > > } > > > > That CLR4 seems to be manipulating phyno==1 instead and > > seems to have no means of doing otherwise. > > > > Was the old code wrong? > > May be I asked the reverse of the right question: > that first CLR 4 in the old code varied by phyno but > now always uses phy_ctrl: > > if (sc->phy_conf->pmu_unk1 == true) > CLR4(sc->phy_ctrl, PMU_UNK_H3, PMU_UNK_H3_CLR); > > > Overall one part or the other seems to be a mismatch with the > old code for A64. > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Sep 21 10:46:34 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6EECAE23C09 for ; Thu, 21 Sep 2017 10:46:34 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 017BF73E6D for ; Thu, 21 Sep 2017 10:46:34 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by mail-wr0-x230.google.com with SMTP id z39so4220677wrb.8 for ; Thu, 21 Sep 2017 03:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AEaE3PVEOR/7nTKq2bG52aNptoT3DYY3WI/aKhVyDtQ=; b=mUPSE/OCOzFaq74LGmaiAtiUzc+jSkP2YbS6PQ9ohGr/t1NTt7wXivuZtq5Un1b9A3 MFFSfrkAoG/nCD4FvWbJWHFwWdWyhigycVgE+9BZD9/2k770UpBd2xaEM5W7fT4jxCfB AQqqy1cwev15hh77xnsk5ltAeRKjbZtxUSp3D/wrwjpUxgakK6U0ON3DTopcheoEpGuH z5xNsaFcU4F6GQ1t2XydJqMsDXaj9sU0kkKClgX8QkMBz4CPSlMrQtKi/dGiTVfe4r15 DRMlTMep53RIB5zWAkNVGoH9mieZTMBdk4WlfwpNyfg5igAWjw2Iyt3d4v8etKj3v0Wh 89mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AEaE3PVEOR/7nTKq2bG52aNptoT3DYY3WI/aKhVyDtQ=; b=Ku3dGw7+UCPX+YxXYAKVdyO0b7OMX0aa7IyfzJ66aWz0lYnAE1fODMT1P/IL/6RRtP c/kv3LDH1mhGAXecrJKPYFVESBg6r9ggyHMmi17Pvq2TASpsuhma7gyoHEm7yw/qhsaM 6AkqFK4YswMUdScGxPCxNfH3UD9xCfYyEH1hMBxqyZbkt6IEQ7T2NrgiGH2TaGPCFvEX jBQlFDqNMHRL5gAXyjNlZrHx/vnCUFix4ZUzHm2csEFy0msaaOkClIgf8YJ6KvTCBQML NfORBRkbIMMO6J9n9VSRNAZLx69Ld77Hf0yGurgVpcrH26yohufrWb/h+ywo/etOVale RkIQ== X-Gm-Message-State: AHPjjUiCZNha7rLybixkbbvErgRsrCgM7eoazs72VmjCUrHv4ich/uP+ qzFpAqz5UuYiwbirWkKT28ThOWujkqshhmunuDusqg== X-Google-Smtp-Source: AOwi7QDJ2uZ0D87nvBi7pwDGwolZ9Mcfo88WL6ywLzqkwUsTg59BUpyG917lSdyvXkoktGB4v2qVGIvFZIupgyot3qg= X-Received: by 10.223.152.117 with SMTP id v108mr1597244wrb.76.1505990792105; Thu, 21 Sep 2017 03:46:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.195.3 with HTTP; Thu, 21 Sep 2017 03:46:31 -0700 (PDT) In-Reply-To: <20170921015621.GA55155@www.zefox.net> References: <20170921015621.GA55155@www.zefox.net> From: Svatopluk Kraus Date: Thu, 21 Sep 2017 12:46:31 +0200 Message-ID: Subject: Re: pmap_fault: PT2MAP abort on rpi2 while building world To: bob prohaska Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 10:46:34 -0000 (1) Well, for beginning, you could add more info to panic message. This pmap_fault() is in pmap-v6.c file. The line before that panic is the following: 6371 CTR4(KTR_PMAP, "%s: pmap %#x PT2MAP %#x far %#x", 6372 __func__, pmap, PT2MAP, far); 6373 panic("%s: PT2MAP abort", __func__); The easiest way is to add the same things like in CTR4. (2) According to console dump, there is an exception from userland which leads to second exception in pmap_fault(). It would be interesting to know at what place it generates the second exception, which IMO should never happen in pmap_fault(). Svata On Thu, Sep 21, 2017 at 3:56 AM, bob prohaska wrote: > Several times now buildworld attempts have crashed with > pmap_fault: PT2MAP abort. > > It started several weeks ago and has been happening intermittently > ever since. So far it's only occurred during buildworld, not other > compilations such as firefox (which still fails from porting issues). > > I couldn't find any recent posts on this error, is it worth a bug > report? > > The information I could gather from the latest crash is at > http://www.zefox.net/~fbsd/rpi2/crashes/crash_9_20_17/ > > Thanks for reading, and any guidance! > > bob prohaska > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Thu Sep 21 22:25:43 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 210B8E26B12 for ; Thu, 21 Sep 2017 22:25:43 +0000 (UTC) (envelope-from freebsd@theory14.net) Received: from bacon.theory14.net (bacon.theory14.net [45.55.200.27]) by mx1.freebsd.org (Postfix) with ESMTP id 001856D728 for ; Thu, 21 Sep 2017 22:25:42 +0000 (UTC) (envelope-from freebsd@theory14.net) Received: from remote.theory14.net (remote.theory14.net [173.79.116.36]) by bacon.theory14.net (Postfix) with ESMTPSA id 38614125F10; Thu, 21 Sep 2017 18:25:36 -0400 (EDT) Received: from anubis.int.theory14.net (anubis.int.theory14.net [192.168.10.50]) by remote.theory14.net (Postfix) with ESMTPS id EB28C6978; Thu, 21 Sep 2017 18:25:35 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Unexpected Results from nuttcp testing wifi on arm From: Chris Gordon In-Reply-To: <86tvzxs6sq.fsf@elm.localnet> Date: Thu, 21 Sep 2017 18:25:35 -0400 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0F498509-3B46-40F1-B638-2E17D0B5B865@theory14.net> References: <86tvzxs6sq.fsf@elm.localnet> To: Carl Johnson X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 22:25:43 -0000 On Sep 20, 2017, at 11:56 AM, Carl Johnson wrote: >=20 > Russell Haley writes: >=20 > I find that some USB adapter have asymmetric speeds, similar to what = you > are seeing. I use iperf3 and get relatively symmetric speeds with a > RTL8188EU, but not with a RTL8188CUS. With the RTL8188CUS I see about > 20Mb/sec send and 1Mb/sec receive. The RTL8188EU gets about 19Mb/sec > send and about 21Mb/sec receive. I hope this helps a little, but I > don't know anything more than my observations. Thank you for that info. I=E2=80=99ve been dealing with the RTL8188CUS = and am seeing similar performance in the best case. This finally = isolates the =E2=80=9Cproblem=E2=80=9D down to the NIC itself. Thanks, Chris= From owner-freebsd-arm@freebsd.org Fri Sep 22 03:06:15 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4525E0D808 for ; Fri, 22 Sep 2017 03:06:15 +0000 (UTC) (envelope-from shigeru@os-hackers.jp) Received: from mailssl03.asahi-net.or.jp (mailssl03.asahi-net.or.jp [202.224.55.62]) by mx1.freebsd.org (Postfix) with ESMTP id B801876B78 for ; Fri, 22 Sep 2017 03:06:15 +0000 (UTC) (envelope-from shigeru@os-hackers.jp) Received: from localhost (w142149.ppp.asahi-net.or.jp [121.1.142.149]) (Authenticated sender: WJ8S-YMMT) by mailssl03.asahi-net.or.jp (Postfix) with ESMTPSA id 8189A40083 for ; Fri, 22 Sep 2017 11:58:28 +0900 (JST) Date: Fri, 22 Sep 2017 20:59:41 +0900 (JST) Message-Id: <20170922.205941.1509653942908658214.shigeru@os-hackers.jp> To: freebsd-arm@freebsd.org Subject: clock problem at PINE64 From: YAMAMOTO Shigeru X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 03:06:16 -0000 Hi, all, Now I test 'make buildworld' on PINE64. It is not success following error, ---------------------------------------------------------------------------- --- Transforms/ObjCARC/ObjCARCAPElim.o --- : jemalloc_arena.c:824: Failed assertion: "nstime_compare(&decay->epoch, &time) <= 0" c++: error: unable to execute command: Abort trap c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) Target: aarch64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/ObjCARCAPElim-2ca7c8.cpp c++: note: diagnostic msg: /tmp/ObjCARCAPElim-2ca7c8.sh c++: note: diagnostic msg: ******************** *** [Transforms/ObjCARC/ObjCARCAPElim.o] Error code 254 make[4]: stopped in /usr/src/lib/clang/libllvm 1 error make[4]: stopped in /usr/src/lib/clang/libllvm *** [all_subdir_lib/clang/libllvm] Error code 2 make[3]: stopped in /usr/src/lib/clang 1 error make[3]: stopped in /usr/src/lib/clang *** [cross-tools] Error code 2 make[2]: stopped in /usr/src 1 error make[2]: stopped in /usr/src *** [_cross-tools] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src ---------------------------------------------------------------------------- It is caused by clock syncronization error. I use ntpd, but I cannot syncronize PINE64 clock. PINE64 clock shifts a few minutes. There is no problem at RaspberryPi 3 (arm64). Does anyone know same problem? Thanks, --- YAMAMOTO Shigeru From owner-freebsd-arm@freebsd.org Fri Sep 22 03:21:17 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35E44E0E33B for ; Fri, 22 Sep 2017 03:21:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-74.reflexion.net [208.70.210.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7DEF7709A for ; Fri, 22 Sep 2017 03:21:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12094 invoked from network); 22 Sep 2017 03:21:14 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 22 Sep 2017 03:21:14 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 21 Sep 2017 23:21:14 -0400 (EDT) Received: (qmail 27368 invoked from network); 22 Sep 2017 03:21:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 22 Sep 2017 03:21:14 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 0486EEC8257; Thu, 21 Sep 2017 20:21:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: clock problem at PINE64 From: Mark Millard In-Reply-To: <20170922.205941.1509653942908658214.shigeru@os-hackers.jp> Date: Thu, 21 Sep 2017 20:21:13 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <59BB30B6-972A-433C-8997-8A3744B5A049@dsl-only.net> References: <20170922.205941.1509653942908658214.shigeru@os-hackers.jp> To: YAMAMOTO Shigeru X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 03:21:17 -0000 On 2017-Sep-22, at 4:59 AM, YAMAMOTO Shigeru = wrote: > Hi, all, >=20 > Now I test 'make buildworld' on PINE64. >=20 > It is not success following error, >=20 > = --------------------------------------------------------------------------= -- > --- Transforms/ObjCARC/ObjCARCAPElim.o --- > : jemalloc_arena.c:824: Failed assertion: = "nstime_compare(&decay->epoch, &time) <=3D 0" > c++: error: unable to execute command: Abort trap > c++: error: clang frontend command failed due to signal (use -v to see = invocation) > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on = LLVM 5.0.0svn) > Target: aarch64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > c++: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ and include the crash backtrace, = preprocessed source, and associated run script. > c++: note: diagnostic msg:=20 > ******************** >=20 > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > c++: note: diagnostic msg: /tmp/ObjCARCAPElim-2ca7c8.cpp > c++: note: diagnostic msg: /tmp/ObjCARCAPElim-2ca7c8.sh > c++: note: diagnostic msg:=20 >=20 > ******************** > *** [Transforms/ObjCARC/ObjCARCAPElim.o] Error code 254 >=20 > make[4]: stopped in /usr/src/lib/clang/libllvm > 1 error >=20 > make[4]: stopped in /usr/src/lib/clang/libllvm > *** [all_subdir_lib/clang/libllvm] Error code 2 >=20 > make[3]: stopped in /usr/src/lib/clang > 1 error >=20 > make[3]: stopped in /usr/src/lib/clang > *** [cross-tools] Error code 2 >=20 > make[2]: stopped in /usr/src > 1 error >=20 > make[2]: stopped in /usr/src > *** [_cross-tools] Error code 2 >=20 > make[1]: stopped in /usr/src > 1 error >=20 > make[1]: stopped in /usr/src > *** [buildworld] Error code 2 >=20 > make: stopped in /usr/src > 1 error >=20 > make: stopped in /usr/src > = --------------------------------------------------------------------------= -- >=20 > It is caused by clock syncronization error. > I use ntpd, but I cannot syncronize PINE64 clock. > PINE64 clock shifts a few minutes. > There is no problem at RaspberryPi 3 (arm64). >=20 > Does anyone know same problem? It would help folks help you if you reported what version of the system is running on the Pine64. For example: on the one I have access to it currently has: # uname -apKU FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r323676M arm64 = aarch64 1200044 1200044 (Note: It has been a long time since I've done a buildworld or buildkernel on it. I'm not likely to until ECHI USB is again working and can be the place for the root file system. Mostly I do cross builds from amd64 these days, even for ports.) One thought is that having ntpd running might force time to jump backwards periodically. Stopping ntpd before the build and letting the clock progress on its own until the build is done might keep the time well ordered. (I'm only guessing that the time jemalloc_arena.c is checking is tied to the time that ntpd adjusts.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Sep 22 04:56:29 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6AB80E153DE for ; Fri, 22 Sep 2017 04:56:29 +0000 (UTC) (envelope-from shigeru@os-hackers.jp) Received: from mailssl04.asahi-net.or.jp (mailssl04.asahi-net.or.jp [202.224.55.63]) by mx1.freebsd.org (Postfix) with ESMTP id 464BD7D8F8 for ; Fri, 22 Sep 2017 04:56:28 +0000 (UTC) (envelope-from shigeru@os-hackers.jp) Received: from localhost (w142149.ppp.asahi-net.or.jp [121.1.142.149]) (Authenticated sender: WJ8S-YMMT) by mailssl04.asahi-net.or.jp (Postfix) with ESMTPSA id 68B7B40082; Fri, 22 Sep 2017 13:56:20 +0900 (JST) Date: Fri, 22 Sep 2017 22:57:34 +0900 (JST) Message-Id: <20170922.225734.376492527325469196.shigeru@os-hackers.jp> To: markmi@dsl-only.net Cc: freebsd-arm@freebsd.org Subject: Re: clock problem at PINE64 From: YAMAMOTO Shigeru In-Reply-To: <59BB30B6-972A-433C-8997-8A3744B5A049@dsl-only.net> References: <20170922.205941.1509653942908658214.shigeru@os-hackers.jp> <59BB30B6-972A-433C-8997-8A3744B5A049@dsl-only.net> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 04:56:29 -0000 >>>>> "Mark" == Mark Millard writes: >> It is caused by clock syncronization error. I use ntpd, but I cannot >> syncronize PINE64 clock. PINE64 clock shifts a few minutes. There is no >> problem at RaspberryPi 3 (arm64). >> >> Does anyone know same problem? Mark> It would help folks help you if you reported what version of the Mark> system is running on the Pine64. For example: on the one I have access Mark> to it currently has: Mark> # uname -apKU FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT Mark> r323676M arm64 aarch64 1200044 1200044 Version of My Pine64 is, $ uname -apKU FreeBSD pine64-vimage 12.0-CURRENT FreeBSD 12.0-CURRENT #0 8bd9e89d414(shigeru_work): Wed Sep 20 20:30:57 JST 2017 root@pine64-vimage:/usr/obj/usr/src/sys/PINE64-VIMAGE arm64 aarch64 1200045 1200044 My Pine64 system is installed self buildworld/buidlkernel images. - source code - https://github.com/bsd-hacker/freebsd/tree/shigeru_work - kernel configuration - https://github.com/bsd-hacker/freebsd/blob/shigeru_work/sys/arm64/conf/PINE64-VIMAGE - /usr/src, /usr/obj, /tmp, swap - mount a file system on ZFS on iSCSI disk - add iSCSI disk partition to swap $ zfs list NAME USED AVAIL REFER MOUNTPOINT izpine64-00 5.82G 55.7G 23K /izpine64-00 izpine64-00/jail 47K 55.7G 23K /jail izpine64-00/jail/jail-00 24K 55.7G 24K /jail/jail-00 izpine64-00/tmp 229M 55.7G 229M /tmp izpine64-00/usr 5.58G 55.7G 23K /izpine64-00/usr izpine64-00/usr/local 256M 55.7G 256M /usr/local izpine64-00/usr/obj 579M 55.7G 579M /usr/obj izpine64-00/usr/ports 1.79G 55.7G 1.79G /usr/ports izpine64-00/usr/src 2.97G 55.7G 2.97G /usr/src $ sudo iscsictl -L Target name Target portal State iqn.1994-11.com.netgear:readynas21400:f0d6cd86:pine64-00 192.168.1.210 Connected: da0 Thanks, --- YAMAMOTO Shigeru From owner-freebsd-arm@freebsd.org Fri Sep 22 06:54:48 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 395A9E19E40 for ; Fri, 22 Sep 2017 06:54:48 +0000 (UTC) (envelope-from sanpei.ml@gmail.com) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 080DC80F29 for ; Fri, 22 Sep 2017 06:54:48 +0000 (UTC) (envelope-from sanpei.ml@gmail.com) Received: by mail-pg0-x22a.google.com with SMTP id k193so149398pgc.8 for ; Thu, 21 Sep 2017 23:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=3dcXChjkPgl4wbnxRftrvvw8GWp49JM8Dz15Wv+Wl9Y=; b=Z5r9s3rPSUhD1imKHsAnbFICAZwXKr6lT99Ww8D7Ixjx0yVE4H8WaT1d4DC4anYn+n Y/URYPnDswYmM1xvl2W1FsCDnFSW2bhjrFdOl2d9DPeaIuEKEkSaEvKzRPmNdAaszKR7 JcTHaOKdpiWdYOcKAt3kdmX0p5SqJE2j9fdI5r3bU0Uca+whL3wQeeiZcXLoQYRiyk4Z yb6BDtFIPQf6B89qKrmw5GwSZzG62gcQMvfgYzTY857XBOVPyqZjivmrUxboXJ5nCXgf 0SshOclnN3Ej6CFv1+G8/Mw6oTAqZnRh31RqUrxnujwq6ca0407kUAt6u8oC3IqXTHe+ hgYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=3dcXChjkPgl4wbnxRftrvvw8GWp49JM8Dz15Wv+Wl9Y=; b=O49NavZdwX3KpQBy7YpEM6EPqEp2+NqtTl8MjHKnQ29RaOztZOU4MtE9B2zVa9r54Z lvnZ+8HXrL2Mdakno1VeySrPIAcIfjz8Foif6i+2IuBN5J/q689PqQcxjop4/N8uOEFR Us/v8QivQdyQH29CCTEBVk8pqoRAyNotAG2ME5PAP+4goULin/2kmcbQYE9gWsYVxMbR SWLjdMRpBIy4ynSdiCwZBCUcvUeAJ7r+qqBQhkKZHHBYJP0hfJ80/yGvLENa0ynPPLa6 G/mdOdFfKJWDJFA//nQkE3xcbwFGPYozVRGiFNbCTRChsxEdj5rYiDDdO/jEY9smN5e3 g0BA== X-Gm-Message-State: AHPjjUir+gaVlCnHlg8f3YY6DoKp12+Uqqy7DxYwBVbiwbeDx21kNt2n rksxZrtFnWqFhsNvB3CWGee/sec9/7p3uHBwIXU= X-Google-Smtp-Source: AOwi7QC2nWINT0z6dH88vFcQg6GLSUYzerx8qt+EDojTS5uVpLCR08/mD4r4JUQ8jDX8r2zLOvCm6RHcJmP/Rcl2M5A= X-Received: by 10.98.194.148 with SMTP id w20mr8396806pfk.299.1506063287354; Thu, 21 Sep 2017 23:54:47 -0700 (PDT) MIME-Version: 1.0 References: <26c67e40-8b90-57f1-de32-e60d1cffe1b9@passap.ru> <6706b32d-4278-d82c-92e6-069121cf48a2@passap.ru> In-Reply-To: <6706b32d-4278-d82c-92e6-069121cf48a2@passap.ru> From: Yoshiro MIHIRA Date: Fri, 22 Sep 2017 06:54:36 +0000 Message-ID: Subject: Re: boot.ini file for Odroid-C1 on FreeBSD wiki page To: Boris Samorodov , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 06:54:48 -0000 Hi Boris-san - boot without Serial Console. I tested Odroid-C1 without Serial Console. It can start it without serial console. Unfortunately I don't know why Boris's enviroment is not. Tested kernel FreeBSD 12.0-CURRENT #1 r321382M U-boot:U-boot-00000-ge7d4447-dirty(odroidc@odroidc-v2011.03) (Jan 27 2015 - 01:36:55) http://archlinuxarm.org/developers/downloads Yoshiro MIHIRA 2017=E5=B9=B48=E6=9C=8816=E6=97=A5(=E6=B0=B4) 2:59 Boris Samorodov : > 15.08.2017 12:57, Yoshiro MIHIRA =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > Hi. > > > > Currently I could not test something with ODROID-C1(because I use it as > my > > parent's home VPN router). > > > > 1. add boot.ini and fix gpart block size > > > > I updated wiki page > > > https://wiki.freebsd.org/action/diff/FreeBSD/arm/Odroid-C1?action=3Ddiff&= rev1=3D9&rev2=3D10 > > Great, thanks! > > > 2. growfs > > > > I think growfs command is for freebsd partition(mmcsd0s2). So growfs > > /dev/mmcsd0s2? > > Ah, yes, sure. > > > 3. serial console is need to boot or not? > > That was just a quesion. I wanted to get a headless machine but > didn't manage to boot Ocdoid-C1 without serial console. > > > Next September I will try to boot ODROID-C1 without serial console cabl= e, > > if I have a time. > > That would be interesting. > > Thank you. > > > 2017=E5=B9=B48=E6=9C=887=E6=97=A5(=E6=9C=88) 6:19 Boris Samorodov : > > >> 04.08.2017 09:15, Yoshiro MIHIRA =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> > >>> I will add boot.ini information to FreeBSD wiki page(1), if no one > reply > >> my > >>> email until 10/Aug. > >> > >> That will be great. > >> > >> I have some more questions/fixes to "Steps to prepare SD card". > >> > >> 1. There are two commands: > >> --- > >> gpart add -t fat16 -b 1134 -s 64M mmcsd0 > >> gpart add -t freebsd -b 132174 mmcsd0 > >> --- > >> > >> I doubt the second command is precise. 64M is 131072 blocks, > >> 131072 + 1134 =3D 132206. > >> > >> If I use those commands I get the error after the second one: > >> --- > >> gpart: autofill: No space left on device > >> --- > >> > >> The value 132206 has a success. So the second command should be: > >> --- > >> gpart add -t freebsd -b 132206 mmcsd0 > >> --- > >> > >> 2. Since we prepare the final disk, I'd add a growfs command at the > >> end of those steps: > >> --- > >> growfs /dev/mmcsd0 > >> --- > >> > >> HTH & WBR > >> -- > >> bsam > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > > From owner-freebsd-arm@freebsd.org Fri Sep 22 08:56:32 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF7C1E1F6D1 for ; Fri, 22 Sep 2017 08:56:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7AE72017 for ; Fri, 22 Sep 2017 08:56:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v8M8uWAO004998 for ; Fri, 22 Sep 2017 08:56:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 222511] RPI3 will not boot 2017-09-20 aarch64 FreeBSD 12.0-CURRENT image Date: Fri, 22 Sep 2017 08:56:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tarjei@online.no X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 08:56:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222511 Bug ID: 222511 Summary: RPI3 will not boot 2017-09-20 aarch64 FreeBSD 12.0-CURRENT image Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: tarjei@online.no This concerns the FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20170919-r323729.img.xz I have tried to get it to work multiple times with two virgin 32GB SanDisk Ultra memory cards. I have verified that one of the memory cards works with the 22-08-2017 snap= shot after failing the newest. I have checked that I can view the MSDOS partition on windows. And the config.txt file is readable. The text the boot writes to the screen last for so short time it is not rea= lly readable. Image writing program : Etcher v 1.1.2 (the latest) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Sep 22 10:23:28 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 851AEE22AF2 for ; Fri, 22 Sep 2017 10:23:28 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 20FFE64E19 for ; Fri, 22 Sep 2017 10:23:27 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3xz8hD0qPgzrQK Received: from restart.be (unknown [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3xz8hD0qPgzrQK for ; Fri, 22 Sep 2017 12:23:23 +0200 (CEST) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id v8MANL1a013648 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 22 Sep 2017 12:23:23 +0200 (CEST) (envelope-from hlh@restart.be) From: Henri Hennebert Subject: Re: clock problem at PINE64 To: freebsd-arm@freebsd.org References: <20170922.205941.1509653942908658214.shigeru@os-hackers.jp> Message-ID: Date: Fri, 22 Sep 2017 12:23:21 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170922.205941.1509653942908658214.shigeru@os-hackers.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 10:23:28 -0000 I'm running FreeBSD norquay.restart.bel 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320599M: Sat Jul 8 18:24:19 CEST 2017 root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY arm64 and with: lrwxr-xr-x 1 root wheel 12 Jun 7 17:58 /etc/malloc.conf -> tcache:false I encounter no problem to build world and kernel. Henri PS I'm running with root on a zpool: Filesystem Size Used Avail Capacity Mounted on rpool/ROOT/default 292G 1.3G 291G 0% / devfs 1.0K 1.0K 0B 100% /dev fdescfs 1.0K 1.0K 0B 100% /dev/fd rpool/home 297G 6.0G 291G 2% /home rpool/tmp 291G 1.5M 291G 0% /tmp rpool/usr/local 295G 3.4G 291G 1% /usr/local rpool/usr/obj 300G 8.5G 291G 3% /usr/obj rpool/usr/ports 292G 1.4G 291G 0% /usr/ports rpool/usr/ports/distfiles 292G 839M 291G 0% /usr/ports/distfiles rpool/usr/src 293G 1.4G 291G 0% /usr/src rpool/var/audit 291G 1.3M 291G 0% /var/audit rpool/var/db 291G 216M 291G 0% /var/db rpool/var/imap 291G 25M 291G 0% /var/imap rpool/var/log 291G 44M 291G 0% /var/log rpool/var/spool 305G 14G 291G 4% /var/spool rpool/ftp 291G 92K 291G 0% /var/spool/ftp rpool/var/spool/imap 292G 974M 291G 0% /var/spool/imap rpool/var/spool/postgres 291G 324M 291G 0% /var/spool/postgres rpool/squid 292G 671M 291G 0% /var/spool/squid rpool/svn-FreeBSD 317G 26G 291G 8% /var/spool/svn-FreeBSD rpool/var/tmp 291G 88K 291G 0% /var/tmp devfs 1.0K 1.0K 0B 100% /usr/local/var/named/dev devfs 1.0K 1.0K 0B 100% /var/db/dhcpd/dev On 09/22/2017 13:59, YAMAMOTO Shigeru wrote: > > Hi, all, > > Now I test 'make buildworld' on PINE64. > > It is not success following error, > > ---------------------------------------------------------------------------- > --- Transforms/ObjCARC/ObjCARCAPElim.o --- > : jemalloc_arena.c:824: Failed assertion: "nstime_compare(&decay->epoch, &time) <= 0" > c++: error: unable to execute command: Abort trap > c++: error: clang frontend command failed due to signal (use -v to see invocation) > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) > Target: aarch64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. > c++: note: diagnostic msg: > ******************** > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > c++: note: diagnostic msg: /tmp/ObjCARCAPElim-2ca7c8.cpp > c++: note: diagnostic msg: /tmp/ObjCARCAPElim-2ca7c8.sh > c++: note: diagnostic msg: > > ******************** > *** [Transforms/ObjCARC/ObjCARCAPElim.o] Error code 254 > > make[4]: stopped in /usr/src/lib/clang/libllvm > 1 error > > make[4]: stopped in /usr/src/lib/clang/libllvm > *** [all_subdir_lib/clang/libllvm] Error code 2 > > make[3]: stopped in /usr/src/lib/clang > 1 error > > make[3]: stopped in /usr/src/lib/clang > *** [cross-tools] Error code 2 > > make[2]: stopped in /usr/src > 1 error > > make[2]: stopped in /usr/src > *** [_cross-tools] Error code 2 > > make[1]: stopped in /usr/src > 1 error > > make[1]: stopped in /usr/src > *** [buildworld] Error code 2 > > make: stopped in /usr/src > 1 error > > make: stopped in /usr/src > ---------------------------------------------------------------------------- > > It is caused by clock syncronization error. > I use ntpd, but I cannot syncronize PINE64 clock. > PINE64 clock shifts a few minutes. > There is no problem at RaspberryPi 3 (arm64). > > Does anyone know same problem? > > Thanks, > --- > YAMAMOTO Shigeru > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Fri Sep 22 16:57:34 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50BB2E05192 for ; Fri, 22 Sep 2017 16:57:34 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 299E873C1D for ; Fri, 22 Sep 2017 16:57:33 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 1ca4a073-9fb7-11e7-a937-4f970e858fdb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 1ca4a073-9fb7-11e7-a937-4f970e858fdb; Fri, 22 Sep 2017 16:57:27 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8MGvOuP018344; Fri, 22 Sep 2017 10:57:24 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506099444.73082.81.camel@freebsd.org> Subject: Re: clock problem at PINE64 From: Ian Lepore To: Mark Millard , YAMAMOTO Shigeru Cc: freebsd-arm@freebsd.org Date: Fri, 22 Sep 2017 10:57:24 -0600 In-Reply-To: <59BB30B6-972A-433C-8997-8A3744B5A049@dsl-only.net> References: <20170922.205941.1509653942908658214.shigeru@os-hackers.jp> <59BB30B6-972A-433C-8997-8A3744B5A049@dsl-only.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 16:57:34 -0000 On Thu, 2017-09-21 at 20:21 -0700, Mark Millard wrote: > On 2017-Sep-22, at 4:59 AM, YAMAMOTO Shigeru > wrote: > > > > > Hi, all, > > > > Now I test 'make buildworld' on PINE64. > > > > It is not success following error, > > > > ----------------------------------------------------------------- > > ----------- > > --- Transforms/ObjCARC/ObjCARCAPElim.o --- > > : jemalloc_arena.c:824: Failed assertion: > > "nstime_compare(&decay->epoch, &time) <= 0" > > c++: error: unable to execute command: Abort trap > > c++: error: clang frontend command failed due to signal (use -v to > > see invocation) > > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based > > on LLVM 5.0.0svn) > > Target: aarch64-unknown-freebsd12.0 > > Thread model: posix > > InstalledDir: /usr/bin > > c++: note: diagnostic msg: PLEASE submit a bug report to https://bu > > gs.freebsd.org/submit/ and include the crash backtrace, > > preprocessed source, and associated run script. > > c++: note: diagnostic msg:  > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > c++: note: diagnostic msg: /tmp/ObjCARCAPElim-2ca7c8.cpp > > c++: note: diagnostic msg: /tmp/ObjCARCAPElim-2ca7c8.sh > > c++: note: diagnostic msg:  > > > > ******************** > > *** [Transforms/ObjCARC/ObjCARCAPElim.o] Error code 254 > > > > make[4]: stopped in /usr/src/lib/clang/libllvm > > 1 error > > > > make[4]: stopped in /usr/src/lib/clang/libllvm > > *** [all_subdir_lib/clang/libllvm] Error code 2 > > > > make[3]: stopped in /usr/src/lib/clang > > 1 error > > > > make[3]: stopped in /usr/src/lib/clang > > *** [cross-tools] Error code 2 > > > > make[2]: stopped in /usr/src > > 1 error > > > > make[2]: stopped in /usr/src > > *** [_cross-tools] Error code 2 > > > > make[1]: stopped in /usr/src > > 1 error > > > > make[1]: stopped in /usr/src > > *** [buildworld] Error code 2 > > > > make: stopped in /usr/src > > 1 error > > > > make: stopped in /usr/src > > ----------------------------------------------------------------- > > ----------- > > > > It is caused by clock syncronization error. > > I use ntpd, but I cannot syncronize PINE64 clock. > > PINE64 clock shifts a few minutes. > > There is no problem at RaspberryPi 3 (arm64). > > > > Does anyone know same problem? > It would help folks help you if you reported > what version of the system is running on the > Pine64. For example: on the one I have access > to it currently has: > > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT  r323676M  arm64 > aarch64 1200044 1200044 > > (Note: It has been a long time since I've done a > buildworld or buildkernel on it. I'm not likely > to until ECHI USB is again working and can be the > place for the root file system. Mostly I do cross > builds from amd64 these days, even for ports.) > > > One thought is that having ntpd running might force > time to jump backwards periodically. Stopping ntpd > before the build and letting the clock progress on > its own until the build is done might keep the > time well ordered. (I'm only guessing that the > time jemalloc_arena.c is checking is tied to the > time that ntpd adjusts.) ntpd will not make the clock jump backwards at any time other than once, when it first starts, and even then only if you give an option that allows it to do so. -- Ian From owner-freebsd-arm@freebsd.org Fri Sep 22 17:05:33 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 372EAE0575C for ; Fri, 22 Sep 2017 17:05:33 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BE1E74012 for ; Fri, 22 Sep 2017 17:05:32 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 0c732d62-9fb8-11e7-b50b-53dc5ecda239 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 0c732d62-9fb8-11e7-b50b-53dc5ecda239; Fri, 22 Sep 2017 17:04:09 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8MH4M95018366; Fri, 22 Sep 2017 11:04:23 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506099862.73082.84.camel@freebsd.org> Subject: Re: clock problem at PINE64 From: Ian Lepore To: YAMAMOTO Shigeru , freebsd-arm@freebsd.org Date: Fri, 22 Sep 2017 11:04:22 -0600 In-Reply-To: <20170922.205941.1509653942908658214.shigeru@os-hackers.jp> References: <20170922.205941.1509653942908658214.shigeru@os-hackers.jp> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 17:05:33 -0000 On Fri, 2017-09-22 at 20:59 +0900, YAMAMOTO Shigeru wrote: > Hi, all, > > Now I test 'make buildworld' on PINE64. > > It is not success following error, > > ------------------------------------------------------------------- > --------- > --- Transforms/ObjCARC/ObjCARCAPElim.o --- > : jemalloc_arena.c:824: Failed assertion: > "nstime_compare(&decay->epoch, &time) <= 0" > c++: error: unable to execute command: Abort trap > c++: error: clang frontend command failed due to signal (use -v to > see invocation) > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on > LLVM 5.0.0svn) > Target: aarch64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs > .freebsd.org/submit/ and include the crash backtrace, preprocessed > source, and associated run script. > c++: note: diagnostic msg:  > ******************** > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > c++: note: diagnostic msg: /tmp/ObjCARCAPElim-2ca7c8.cpp > c++: note: diagnostic msg: /tmp/ObjCARCAPElim-2ca7c8.sh > c++: note: diagnostic msg:  > > ******************** > *** [Transforms/ObjCARC/ObjCARCAPElim.o] Error code 254 > [...] > ------------------------------------------------------------------- > --------- > > It is caused by clock syncronization error. > I use ntpd, but I cannot syncronize PINE64 clock. > PINE64 clock shifts a few minutes. > There is no problem at RaspberryPi 3 (arm64). > > Does anyone know same problem? > > Thanks, > --- > YAMAMOTO Shigeru If ntpd cannot keep the clock synchronized, there is something wrong with the timecounter driver.  I don't have a pine64 to experiment with.  Could you show the output of "sysctl kern.timecounter" and the output of "ntptime" while ntpd is running and failing to keep the system on- time. -- Ian From owner-freebsd-arm@freebsd.org Fri Sep 22 21:44:58 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0A25E0FEAF for ; Fri, 22 Sep 2017 21:44:58 +0000 (UTC) (envelope-from sanpei.ml@gmail.com) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF5468004E for ; Fri, 22 Sep 2017 21:44:58 +0000 (UTC) (envelope-from sanpei.ml@gmail.com) Received: by mail-pf0-x242.google.com with SMTP id g65so960748pfe.1 for ; Fri, 22 Sep 2017 14:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Odxo7wDCQ3vyJ/diT+kciTRHLIgSAAz50mLtBCRPwRE=; b=LK/YMwJX3TNZTTkX5N0hmkC6nxMbHwG9hAXKkQdjE4rwIY3zs/NviqpGaMNjBvU/Lq xEcINCq/0IyDeNGh+RsxyJLIU2Fdr10qWV9qfkCdJ21Z0KE4AgXw39nIxpwcoDHl1r1B J80lTwEcHt1iE0q9z3GMD547V4DCmU7rnouw/6GUMupp+Auq3wO3xnugY/uBI9vqXlYj LKW7gQEHlzi9XDRtzFD2A+UXiXjetK0rsAlxq4vtpQZJgvIr+q8UQ7K9cuZULMp2UhKY dn28r9vwLBjfEzQKq9wL2B5R0b1FGIs+76ksVtbwv7PSZynr8tAJ0f2K5toMh7sBZbqQ 53NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Odxo7wDCQ3vyJ/diT+kciTRHLIgSAAz50mLtBCRPwRE=; b=uZWPGXt3M+rwCnXmM3TdnttequI+6Hw5GJhLyrNT8ukhEjW09S8xRpy1TaE8NBH3tU QaL9FeyYaR0CgRTVLZ/CB/xDyTc72vFkHMtUNCFMoLTtO3Rm/HJuiJAh6YQF8X/PVbjW tSIOsVbrf/2ENoip2lGg2rVbVSSYNXyh0njqZ+baZPLsFz0HPLqdB4LFIAdGLu/yaB7N JQPkHmDm0J9SfeHio+FjOpOgBaG6rrLjt9LClLsmCpjfmZXwRRHw2/VsKYnIRocb+3uN BweID/4GVsHLLKLQ8K04wRxtAza/7Uuz6R3M8K4PvCl/Qk7mK/FrmuugLwDQdzETcFwe 90gw== X-Gm-Message-State: AHPjjUh7JOSEC2ZB8raCxinMSnRVdhJTGex3vUGGdeCw4Wr64iq6E/x8 UqK+xVMJmE2H0yK/ekNSVxbK7DTerPpd0uC6XqE= X-Google-Smtp-Source: AOwi7QA4UKZx6+IR3d9oBAgrTtGsXXF7JTrcH1+boK+rt907wfyQbhWn18zCXCyXosTT0sE3AUaY/YT8jFH4VJQ2rpI= X-Received: by 10.84.233.68 with SMTP id k4mr405657plt.416.1506116698182; Fri, 22 Sep 2017 14:44:58 -0700 (PDT) MIME-Version: 1.0 References: <20170922.205941.1509653942908658214.shigeru@os-hackers.jp> <59BB30B6-972A-433C-8997-8A3744B5A049@dsl-only.net> <20170922.225734.376492527325469196.shigeru@os-hackers.jp> In-Reply-To: <20170922.225734.376492527325469196.shigeru@os-hackers.jp> From: Yoshiro MIHIRA Date: Fri, 22 Sep 2017 21:44:47 +0000 Message-ID: Subject: Re: clock problem at PINE64 To: YAMAMOTO Shigeru , markmi@dsl-only.net Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 21:44:59 -0000 Hi, All. Currently I'm testing Shigeru-san's kernel and image. In 12 hours test, system time was syncronized OK by ntpd(only boot up and idle status). Shigeru-san, your Pine64 could not syncronize to NTP server without buildworld? Now I started to buildworld on Pine64. 2017=E5=B9=B49=E6=9C=8822=E6=97=A5(=E9=87=91) 13:56 YAMAMOTO Shigeru : > > >>>>> "Mark" =3D=3D Mark Millard writes: > >> It is caused by clock syncronization error. I use ntpd, but I cannot > >> syncronize PINE64 clock. PINE64 clock shifts a few minutes. There is > no > >> problem at RaspberryPi 3 (arm64). > >> > >> Does anyone know same problem? > Mark> It would help folks help you if you reported what version of the > Mark> system is running on the Pine64. For example: on the one I have > access > Mark> to it currently has: > Mark> # uname -apKU FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT > Mark> r323676M arm64 aarch64 1200044 1200044 > > Version of My Pine64 is, > > $ uname -apKU > FreeBSD pine64-vimage 12.0-CURRENT FreeBSD 12.0-CURRENT #0 > 8bd9e89d414(shigeru_work): Wed Sep 20 20:30:57 JST 2017 root@pine64-vimag= e:/usr/obj/usr/src/sys/PINE64-VIMAGE > arm64 aarch64 1200045 1200044 > > My Pine64 system is installed self buildworld/buidlkernel images. > > - source code > - https://github.com/bsd-hacker/freebsd/tree/shigeru_work > - kernel configuration > - > https://github.com/bsd-hacker/freebsd/blob/shigeru_work/sys/arm64/conf/PI= NE64-VIMAGE > - /usr/src, /usr/obj, /tmp, swap > - mount a file system on ZFS on iSCSI disk > - add iSCSI disk partition to swap > > $ zfs list > NAME USED AVAIL REFER MOUNTPOINT > izpine64-00 5.82G 55.7G 23K /izpine64-00 > izpine64-00/jail 47K 55.7G 23K /jail > izpine64-00/jail/jail-00 24K 55.7G 24K /jail/jail-00 > izpine64-00/tmp 229M 55.7G 229M /tmp > izpine64-00/usr 5.58G 55.7G 23K /izpine64-00/usr > izpine64-00/usr/local 256M 55.7G 256M /usr/local > izpine64-00/usr/obj 579M 55.7G 579M /usr/obj > izpine64-00/usr/ports 1.79G 55.7G 1.79G /usr/ports > izpine64-00/usr/src 2.97G 55.7G 2.97G /usr/src > > $ sudo iscsictl -L > Target name Target portal State > iqn.1994-11.com.netgear:readynas21400:f0d6cd86:pine64-00 192.168.1.210 > Connected: da0 > > > Thanks, > --- > YAMAMOTO Shigeru > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Fri Sep 22 21:59:16 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03682E1076B for ; Fri, 22 Sep 2017 21:59:16 +0000 (UTC) (envelope-from sanpei.ml@gmail.com) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB3FB807BC; Fri, 22 Sep 2017 21:59:15 +0000 (UTC) (envelope-from sanpei.ml@gmail.com) Received: by mail-pg0-x234.google.com with SMTP id p5so1251930pgn.7; Fri, 22 Sep 2017 14:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=9tiH2XYaJ1BbJ9ON/oSrtvKOwGRw+bMwFzy8g3RTvns=; b=obS19RKQAJebI729SQx4nISiLrrI2wa4ehamp5IB0qwUd9csIckOXNlV2FJkqF0tvd DWXwRkfmpvWVXsmICTNfdHwzMgWySjr2zDc2SZvGbqNMbLXAR3SLr3GWZI4oSBprqXVV YgE7a8cgyvUia58MS8YxuVWWMVi7E4PRPQjDOmslWwtbkqRrF3MPmKrDVlbUUiQAmQTw yJs74Vu/ckMhWt19zFaP3GeuOszIbqKMvG0iKFWCCpxHTCySs6P74SYCHjyMa52nOn2e ufyN/jfNpSbyP9nkISGq1F26WdmcY1biI0ZMX4nM1QA4PmjPwMktwslPPDOS7TJN2wSx Lm5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9tiH2XYaJ1BbJ9ON/oSrtvKOwGRw+bMwFzy8g3RTvns=; b=Sa2V1PBYRoCpADD2XAG2sNjUdVIdXNlzajLDus2XSXdTNryreuxBoH18b9+2kwCrsM ohjZL5kJxJHAGYk8g1qb7CacJbjfn+mEhsRlXoF5bHJkI80SeitO/H1pQ2S5aUCoKJiY w93TptP0bk2MWxg0Yrea2xGfjYI/W3njsMOEcq1DC0MZWXDpqbF1bVE34zkJdT/A5Meu lclVtHjpqoaxNLiR3QRS7+OlOxhaYvpEhynwWMqUqjbPrjHuapPXLesWSaA/VwrMXcy7 nJDdaiPfSRVDeZw1g8GDPDCbYpCBE49uP1u9QIroxFYrIB1kGmX8LVkCrZ6XcZj2/Vjt mUSw== X-Gm-Message-State: AHPjjUgSysft+qJloAKfqofcyV2EJI2rat7N9SJ4ahTa4QqyuS/Tobp5 rc9pcC2B1FXBcIijyXY8w+xA+Lw0oPClzME3M0qdcQ== X-Google-Smtp-Source: AOwi7QB/+GSCBHw/iOVLrKPikJs4Mg/QLzWLug336iW77volLYvsWdPdpt72lKmltxp8mf+5+pRThHju/rCxr0E5D+M= X-Received: by 10.98.200.197 with SMTP id i66mr431184pfk.73.1506117555118; Fri, 22 Sep 2017 14:59:15 -0700 (PDT) MIME-Version: 1.0 From: Yoshiro MIHIRA Date: Fri, 22 Sep 2017 21:59:04 +0000 Message-ID: Subject: [FreeBSD] update todo list on Wiki-arm-Allwinner To: jmcneill@freebsd.org, freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 21:59:16 -0000 Hi, all. Latest Crypto engine is listed on TODO list at Wiki arm Allwinner page. However, andrew added armv8crypto(driver for the AES accelerator on ARM CPUs). So I would like to update and add Crypto line on [[Supported devices/Legend] at Wiki page. Currently YES(r308921) is only for A64. openssl speed aes-256-cbc "PINE64 without crypto engine" aes-256 cbc 20817.02k 22166.74k 22629.38k 22734.17k 22754.10k /usr/bin/openssl speed -engine cryptodev -evp aes-256-cbc "PINE64 with crypto engine" aes-256-cbc 88225.27k 207383.62k 308516.25k 360612.50k 380447.40k Yours Yoshiro MIHIRA From owner-freebsd-arm@freebsd.org Fri Sep 22 22:13:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6AC0E10E50 for ; Fri, 22 Sep 2017 22:13:06 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 71303810DD for ; Fri, 22 Sep 2017 22:13:05 +0000 (UTC) (envelope-from brett@lariat.net) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id QAA21968 for ; Fri, 22 Sep 2017 16:06:28 -0600 (MDT) Message-Id: <201709222206.QAA21968@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 22 Sep 2017 16:06:25 -0600 To: freebsd-arm@freebsd.org From: Brett Glass Subject: ARM board recommendations with true GigE ports Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 22:13:06 -0000 All: I've been working with several ARM-based boards, and have discovered that many of them have "gigabit" Ethernet ports that actually cannot handle a gigabit! (They tend to max out at around 300 Mbps; the fine print in the spec sheets for some of them says that this is due to "bus limitations.") Any recommendations for ARM-based SBCs or project computers that have at least one (and preferably 2 or more) true gigabit Ethernet ports? --Brett Glass From owner-freebsd-arm@freebsd.org Fri Sep 22 22:30:43 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA95AE12611 for ; Fri, 22 Sep 2017 22:30:43 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 476348164C for ; Fri, 22 Sep 2017 22:30:43 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-wr0-x22e.google.com with SMTP id r74so1853104wrb.13 for ; Fri, 22 Sep 2017 15:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mHJPJCbDbtYFA26MtVONIUpeHU+Puwa6SJjVavBjElY=; b=WXho1rG2lpdPjmCQwCp2zzOXKAZ0aEk9TdC5GiyKVRhhvZbiRKyn825YOk2prHsnxO b5slEU/1xfwgCEJuPq4vUtlWx0Zk2pwZps5TzHu1Zo809bVRVA4Mnagaahg7OvXXmsQ3 qXeHFuyq2BpVRtDtL2LPURDWSj46+6k4lWhWA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mHJPJCbDbtYFA26MtVONIUpeHU+Puwa6SJjVavBjElY=; b=FQthp8dtXuyJW5a5GHy9OIqY5SA0gyI5f1u9X4nXfEn49koh1P9sDhOUKBu7CEaJI2 bsV2rFc9Q9hMeDXOPHcRh01Dvv0G1+jIS4gi6Armgew3W5r7xh/5z3H/rQC0M6NvNW5Q pansdtXiqA5xM1+jfJTNMUtZofpEa0LH7Ai+7QPfgXyu01XTsMLkAudQ4oD1Cu0O8Uzs uo8jKBSPRZWkNskbgy5iypJltHRGxC0ajqnwuQECkTqEmL4ji+0wiovI3MhJTH2Uj4K7 ncwOZyOOIi7276Cc++DAqEkR+dVzm+cwaAdRVWPANlPzzH/XbzgA3jZwWqAk3+EyaKKg Pq+g== X-Gm-Message-State: AHPjjUgXll1Hm7xsaxyrFNktCJtS9gTK3B4qCuqXnAUmhQY7KUPQrwQw flTEueJR221ukjllJ6+KwjL/HoQXl+g= X-Google-Smtp-Source: AOwi7QAhgyheujyjsMGI9BWW6hQWUAsHiBTfMCsj+Jb9pnfCqtFDYppTHJ/dqDez2RSDhmIA2sryIw== X-Received: by 10.223.164.206 with SMTP id h14mr366802wrb.221.1506119441454; Fri, 22 Sep 2017 15:30:41 -0700 (PDT) Received: from [192.168.2.47] (LNeuilly-656-1-101-235.w193-248.abo.wanadoo.fr. [193.248.221.235]) by smtp.gmail.com with ESMTPSA id a19sm842145wra.64.2017.09.22.15.30.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Sep 2017 15:30:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: ARM board recommendations with true GigE ports From: Jim Thompson X-Mailer: iPhone Mail (15A372) In-Reply-To: <201709222206.QAA21968@mail.lariat.net> Date: Sat, 23 Sep 2017 00:30:35 +0200 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <07D27DD7-2434-4A2E-91CE-A05D12BBAC2A@netgate.com> References: <201709222206.QAA21968@mail.lariat.net> To: Brett Glass X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 22:30:43 -0000 What do you mean by =E2=80=9Ctrue gigabit=E2=80=9D? I=E2=80=99ve trivially done 939mbps over TCP / IPv4 (iperf3, even a browser-= based Speedtest) on a couple different Armada 38x boards with the default pf= Sense ruleset =E2=80=9Con=E2=80=9D. Solid-Run makes one, we sell one.=20 Hell, even the little single core 600MHz OMAP / 2 Ethernet router we sell wi= ll do 550mbps using pkt-gen without =E2=80=9Cpf=E2=80=9D running. loos@ did= a huge amount of work on the NIC driver there. Same SoC family as=20 Beaglebone, and BBB is 1GHz.=20 They won=E2=80=99t do 1.488Mpps though, that still wants an Intel box and ne= tmap-fwd. I do have the netmap code for the 38x though, so maybe soon... Jim > On Sep 23, 2017, at 12:06 AM, Brett Glass wrote: >=20 > All: >=20 > I've been working with several ARM-based boards, and have discovered that m= any of them have "gigabit" Ethernet ports that actually cannot handle a giga= bit! (They tend to max out at around 300 Mbps; the fine print in the spec sh= eets for some of them says that this is due to "bus limitations.") Any recom= mendations for ARM-based SBCs or project computers that have at least one (a= nd preferably 2 or more) true gigabit Ethernet ports? >=20 > --Brett Glass >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri Sep 22 23:47:56 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDD0FE15ADD for ; Fri, 22 Sep 2017 23:47:56 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33C1F83043 for ; Fri, 22 Sep 2017 23:47:56 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x22c.google.com with SMTP id r17so2447677lff.6 for ; Fri, 22 Sep 2017 16:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XXlWaMEqJmm6Ro/jSsjtt80/5Uc7I603xFp7dZY7iO0=; b=C3yp8IE9ipZVrOtburWHCA5fn6GW9m1Zz1vHoNPV2eDVT6Xwox5pr4LOOtLTbn7TGf VjNYQHD+isoqad6zUSw35X4SJjuYRRa9lh9l19ww5TTcuikj9PNwr4jxt0gUKDzAVlMG XeqDy+mjEche//lpqZ6VUeBtXz+IZ4maw77SOh5VuHCPVIuEGGsTbA1O82tr0bD/ILBw nH+QSWLt0Ag52c/4cW1fGcfaCEcjj/HJNVDd4kGUxN5fE8hw9QMDIfq+hTrwNmOn7RfE 3iHNIMCMCj1Ec69ZHd3JiK7/1dCbK9/uUCF/G/V5qdAKL4pmbZhoeoc+4md1aGHPubaT yChQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XXlWaMEqJmm6Ro/jSsjtt80/5Uc7I603xFp7dZY7iO0=; b=Cm52tnU23qTvClvwXiJN+98zhIChNlukPkFkgzZBnsvG7+belnSo1aKsttd5aem0FX pwq0Sj9mYi6eG+y0/HUgNcQd5jZIdzkqRmoVTvOapmkhNt97SuWzfTv7Spcp3mxawSRJ +j3JA8fRfo+zTAubClzS5R+4cYDrZIPkDjJ3tMN/7k5iCZvGyO3OtbU4qDf8Bmd2IWMG zS7BMANtm3fARcbEDVyRoqqddbDhQUypHpY1ju+CEG7voENIHC01mevTvKfkpcFD1m7w 8bY0ASo0VCMDkfDRQsJnxXCK/AFLrJE564tJHe9o5rcqE5TPYDWkI//5+Fl1MAozGkWS pyuw== X-Gm-Message-State: AHPjjUh+V8vfJ+C42wikurDxFHRK7rqyQI62FwZP0oavktIrf29rY7es 1+CDgcLXU2PvoOsGLcSVe0khgXykpYjZKVT/Ce0= X-Google-Smtp-Source: AOwi7QCvixhw74Mv0ZDpHThrfU98AbcDX2sBm7NBR1826JZpbnIKPfqrIqLr+hwESiXpJzoHeJi6v64DqvAATvy2b1o= X-Received: by 10.25.41.67 with SMTP id p64mr230023lfp.200.1506124072973; Fri, 22 Sep 2017 16:47:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Fri, 22 Sep 2017 16:47:52 -0700 (PDT) In-Reply-To: <07D27DD7-2434-4A2E-91CE-A05D12BBAC2A@netgate.com> References: <201709222206.QAA21968@mail.lariat.net> <07D27DD7-2434-4A2E-91CE-A05D12BBAC2A@netgate.com> From: Russell Haley Date: Fri, 22 Sep 2017 16:47:52 -0700 Message-ID: Subject: Re: ARM board recommendations with true GigE ports To: Jim Thompson Cc: Brett Glass , freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 23:47:56 -0000 On Fri, Sep 22, 2017 at 3:30 PM, Jim Thompson wrote: > > What do you mean by =E2=80=9Ctrue gigabit=E2=80=9D? > > I=E2=80=99ve trivially done 939mbps over TCP / IPv4 (iperf3, even a brows= er-based Speedtest) on a couple different Armada 38x boards with the defaul= t pfSense ruleset =E2=80=9Con=E2=80=9D. Solid-Run makes one, we sell one. We make a custom product based on the Armada 38xx and it was measured at high 900 Mbps using a Buildroot Linux. I want to say 980 but the engineer who did the measurements is away so I can't confirm. I can't wait to get my hands on a netgate router. I had it all lined up for my tax return and then the clutch in my car died. :( https://www.netgate.com/products/sg-3100.html > Hell, even the little single core 600MHz OMAP / 2 Ethernet router we sell= will do 550mbps using pkt-gen without =E2=80=9Cpf=E2=80=9D running. loos@= did a huge amount of work on the NIC driver there. Same SoC family as > Beaglebone, and BBB is 1GHz. > > They won=E2=80=99t do 1.488Mpps though, that still wants an Intel box and= netmap-fwd. > > I do have the netmap code for the 38x though, so maybe soon... > > Jim > >> On Sep 23, 2017, at 12:06 AM, Brett Glass wrote: >> >> All: >> >> I've been working with several ARM-based boards, and have discovered tha= t many of them have "gigabit" Ethernet ports that actually cannot handle a = gigabit! (They tend to max out at around 300 Mbps; the fine print in the sp= ec sheets for some of them says that this is due to "bus limitations.") Any= recommendations for ARM-based SBCs or project computers that have at least= one (and preferably 2 or more) true gigabit Ethernet ports? >> >> --Brett Glass >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Sep 23 00:04:07 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F6BDE16892 for ; Sat, 23 Sep 2017 00:04:07 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 14ACC83870 for ; Sat, 23 Sep 2017 00:04:06 +0000 (UTC) (envelope-from brett@lariat.net) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id SAA22590; Fri, 22 Sep 2017 18:04:02 -0600 (MDT) Message-Id: <201709230004.SAA22590@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 22 Sep 2017 18:03:59 -0600 To: Russell Haley From: Brett Glass Subject: Re: ARM board recommendations with true GigE ports Cc: freebsd-arm In-Reply-To: References: <201709222206.QAA21968@mail.lariat.net> <07D27DD7-2434-4A2E-91CE-A05D12BBAC2A@netgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 00:04:07 -0000 At 05:47 PM 9/22/2017, you wrote: >We make a custom product based on the Armada 38xx and it was measured >at high 900 Mbps using a Buildroot Linux. I want to say 980 but the >engineer who did the measurements is away so I can't confirm. So, if this is a recommended SoC for network-related applications, what commercial boards that use it are recommended? And is there driver support for them in FreeBSD? --Brett Glass From owner-freebsd-arm@freebsd.org Sat Sep 23 00:37:01 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38734E178F5 for ; Sat, 23 Sep 2017 00:37:01 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8DF2842F5 for ; Sat, 23 Sep 2017 00:37:00 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-wr0-x232.google.com with SMTP id l22so1968333wrc.10 for ; Fri, 22 Sep 2017 17:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ozAB5IcB7yruye19mmFpaBEugchQNW+soDQzlA1QwtA=; b=KWmBxLJbAeqK2BfRVS+UhmlweoJUmZD6NjNZJmTf9Rig0UtwtsuRa5cK4JUAeyO36W uUUogCmkSVq402+VAmazeqWl1AvMBlUxiXutdXxQIZwJgvkylZcQHvXE9oLrRaL36DP5 sYpPcuv2ya18k8dXj1nxvc5IyxwhWHJGZ3D9Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ozAB5IcB7yruye19mmFpaBEugchQNW+soDQzlA1QwtA=; b=HcxWUT2LMKKWeD0pwnGA8Kw1eCXYKZFnsqV803DvvqnXJe36gPgAq4Z/s1pHGiy7Sx EVFjQUXDzbl5b5xFoEtHXIU8bbqg09L279RgFOhPVoYtuWEWkHRZgJvpmCMRSAZ3bZw6 GojIDedCTwk1adyUnoC9eSmkmKkMJAIXv+pj8goRnA7tK6YHfRXw6kei3lN/TTZ6P+YN OCcw25oV8W5weMCXGRS1J2zUhPX59aclcUU60Vih31UpiqXBMGITgEmIepVPeNRzIW2K 7AUldmUDnCxeG7kZ84BAkrjH9LUxCOkXi+DfMG5omGjVOTY0kGsMJIkDprtl6r4ieDRn G+/A== X-Gm-Message-State: AHPjjUik4N1iE/R3xYfWv5+nKWScueqNyGvx6ljEdBzEDuO01cN2Xquh 0QPDs9VYeckLfLymVvUMRrUY/rtg2DA= X-Google-Smtp-Source: AOwi7QDGUyHIACmyoNP+ylDRlEjspzBiIetToqwquYCEDiPvJ26mI7hzEkeKBaMrlaszWhLC3z8t2Q== X-Received: by 10.223.185.123 with SMTP id b56mr531728wrg.115.1506127019166; Fri, 22 Sep 2017 17:36:59 -0700 (PDT) Received: from [192.168.2.47] (LNeuilly-656-1-101-235.w193-248.abo.wanadoo.fr. [193.248.221.235]) by smtp.gmail.com with ESMTPSA id g37sm1218739wra.6.2017.09.22.17.36.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Sep 2017 17:36:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: ARM board recommendations with true GigE ports From: Jim Thompson X-Mailer: iPhone Mail (15A372) In-Reply-To: <201709230004.SAA22590@mail.lariat.net> Date: Sat, 23 Sep 2017 02:36:56 +0200 Cc: Russell Haley , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <4E771B56-D588-468E-AB60-35DB4DB31318@netgate.com> References: <201709222206.QAA21968@mail.lariat.net> <07D27DD7-2434-4A2E-91CE-A05D12BBAC2A@netgate.com> <201709230004.SAA22590@mail.lariat.net> To: Brett Glass X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 00:37:01 -0000 > On Sep 23, 2017, at 2:03 AM, Brett Glass wrote: >=20 > At 05:47 PM 9/22/2017, you wrote: >=20 >> We make a custom product based on the Armada 38xx and it was measured >> at high 900 Mbps using a Buildroot Linux. I want to say 980 but the >> engineer who did the measurements is away so I can't confirm. >=20 > So, if this is a recommended SoC for network-related applications, what co= mmercial boards that use it are recommended? And is there driver support for= them in FreeBSD? Armada 38x support landed in the tree a couple months back.=20 Solid-run makes one. Two, actually.=20 We make one.=20 Apparently russ.haley@gmail.com is employed by a company that makes one, tho= ugh from his description it=E2=80=99s might be an Armada 37x0, and there isn= =E2=80=99t any support in the tree for this SoC.=20 >=20 > --Brett Glass >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Sep 23 01:23:56 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3094E1B058 for ; Sat, 23 Sep 2017 01:23:56 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 564E2E83 for ; Sat, 23 Sep 2017 01:23:56 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id k9so2524448lfe.10 for ; Fri, 22 Sep 2017 18:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=er37IsUWjhjrLK/WB7cEJBrRpFgDxfGMhXcr6KoKR+c=; b=UlfmKwyfaBKRhikKEpALYQHvKtVKY7q7Jo78ALSmkaH5QRKDvFFkMZ21ovz3bIn6ny 2EZeCcr6bhL+mbwdhvtpVAv0c0L5dlRwhG0bxZyRH5M9kNfRHF6MFrgj9nrhmS6qykG9 uxlabV60a96Uc59mlhytTEwTHY9VHLKSThkUSchZMb4i8qewYZaWYbD6F3dahWKLjn2R DRM57dlfojz2sGul83+AqjfxWkrMHCw2+5ueb9y/L+inoIaWlN5wEuV7N2njv+Y7OYOW SBjFLK3hlYiAhVELCSGwD877O8yFlUvdrF+TiuCMKO5VllqjAcA6gJR9tbNSkBHqDi+I xU0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=er37IsUWjhjrLK/WB7cEJBrRpFgDxfGMhXcr6KoKR+c=; b=i3y5mxpy12GxMIuGuMHtj7vgNXH+jM6U0PMv0Zz5yaOlKGWlG75hYzUf7MfR0xhNQs 2o6fKaIrFgO2I0Z4cQPu82yO/J6KIiAb1n960ZueQpli5DxyEv0AQ/jvGGMf/0y8zfHO vwQjKntcpSi/C4dphIpideCiyZ4prGoFsXQN7iZqiYOZlbhtxgs97ujrZZpbusNb4mtO JJ6FN9j/du1JJxjNJ4tCSOnj7xYQC8Uc9Ghi496bI9107xoDlulwOdu3KF8pX+pttaT7 wnLmkJ5abYUeMnTLlFx28nVPQ6Gq0Ttk1I7sUG04qGcIgsVYwfiwtAMocZOQUZO21MkC qx6A== X-Gm-Message-State: AHPjjUh0rRLGfxyX7AlBvPfJGbIV9BtxKa8UGV8yXrTZFl1RHww5I7pW mlXmjOPCoYzuYfFKR2Pv45pf+BrlT1L7EOCwL24= X-Google-Smtp-Source: AOwi7QDp/H/pPgy+2ERN3bCieOzwsywj4L0zIPjdCgDMPxGEUsU6PcdzQaKn54Zemg4N9yhf7CXvcHkBHyXXl/3CbtQ= X-Received: by 10.46.64.142 with SMTP id r14mr305423lje.192.1506129833927; Fri, 22 Sep 2017 18:23:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Fri, 22 Sep 2017 18:23:52 -0700 (PDT) In-Reply-To: <4E771B56-D588-468E-AB60-35DB4DB31318@netgate.com> References: <201709222206.QAA21968@mail.lariat.net> <07D27DD7-2434-4A2E-91CE-A05D12BBAC2A@netgate.com> <201709230004.SAA22590@mail.lariat.net> <4E771B56-D588-468E-AB60-35DB4DB31318@netgate.com> From: Russell Haley Date: Fri, 22 Sep 2017 18:23:52 -0700 Message-ID: Subject: Re: ARM board recommendations with true GigE ports To: Jim Thompson Cc: Brett Glass , freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 01:23:56 -0000 On Fri, Sep 22, 2017 at 5:36 PM, Jim Thompson wrote: > >> On Sep 23, 2017, at 2:03 AM, Brett Glass wrote: >> >> At 05:47 PM 9/22/2017, you wrote: >> >>> We make a custom product based on the Armada 38xx and it was measured >>> at high 900 Mbps using a Buildroot Linux. I want to say 980 but the >>> engineer who did the measurements is away so I can't confirm. >> >> So, if this is a recommended SoC for network-related applications, what = commercial boards that use it are recommended? And is there driver support = for them in FreeBSD? > > Armada 38x support landed in the tree a couple months back. > > Solid-run makes one. Two, actually. > > We make one. > > Apparently russ.haley@gmail.com is employed by a company that makes one, = though from his description it=E2=80=99s might be an Armada 37x0, and there= isn=E2=80=99t any support in the tree for this SoC. We make a 12 port Vehicle Switch for Train Ethernet Networks. Our original prototype testing was done on a Solid-Run Clearfog board (I would have told them about NetGate if I had known there was an up-coming product at the time we were prototyping). The final product is custom hardware. Russ >> >> --Brett Glass >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Sep 23 01:25:25 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB7ACE1B2DA for ; Sat, 23 Sep 2017 01:25:25 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DF3DF71 for ; Sat, 23 Sep 2017 01:25:25 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x233.google.com with SMTP id 80so2537169lfy.4 for ; Fri, 22 Sep 2017 18:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=G4fFM+HQb0gYhySI1ktRbhv3n09xmY734u6VV+IuMSY=; b=XOn5tauQX6AJXrOKddmFuzzo/PyCAXNnWWYxSrCAYNbCoenA0Z6ABUJ9QAAsi4QZkY 7dO1+CWazI7RLHDmxozz5zaLWJv2ct0Hz4iKGMX+opPoc+G3d7fHFfAIKRoOwG3sGphJ yCGac4WqFe3cXHIZpTDFcpJCUcp+p4QAlazVPD+G4Aac0zKHqxMvrX8M9EdhYbDPO34/ /sVs+4sTPC0FzoI8p/n5VRs4Z0cFZQOPVV+iXJOnDAYYcngQRPhEXk44X+8ErYT5VsbA HVp+MHIeFjPEnTXio6JfCAplnwxQnrz39/zJ3xqN/XDAcB9bbgTg9gpALt58A+liOk9Z 0NoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=G4fFM+HQb0gYhySI1ktRbhv3n09xmY734u6VV+IuMSY=; b=ncdu7fCiLDsAx40+ArUuJhT2xiejvajvI4Awnvdq9bC6K4hGjXSNjrd08XXjROAaFl /4AfaVVLeiovFubxg8HnAObz+TnZR8satdahoZ+k8Q6idHppbk+TkiMiG8mCeuNTJc+E CqdSQSNWQp3ClKhqxFPIDQH7sxQYUpak5tqbRGiamAcJ1s7yEpwpCJ1B1snASR2kdoR2 SGDCYiOB76cIMitu9G59MuXvTNVDg2/v5JQncGvIvCMFzZtsXoa3vWh5W8oD+4nUBwgZ CvLrzbS3tGj62B75iPyKYTgDYX2m56pX3DLtq8Pxa9tLklJFCaYRAK3U7mhwBtEWCUlE JMbg== X-Gm-Message-State: AHPjjUhfQa3CK4HSdD2DLQHSYqgqSyGB8Y48ILmt6pZUivCCIbEMCsPA X4Kua8lUKB6IOro/HY/jJCrEro1dyYUtohBW/Po= X-Google-Smtp-Source: AOwi7QDbinXKyI0O93jddQx5TMYfNO6crRnAYVYvYqkIcpdNratGQtNALXOlb9ckMaGa7TEVsH+sblxZ1bK6huwzu9w= X-Received: by 10.25.19.197 with SMTP id 66mr253254lft.221.1506129923556; Fri, 22 Sep 2017 18:25:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Fri, 22 Sep 2017 18:25:22 -0700 (PDT) In-Reply-To: References: <201709222206.QAA21968@mail.lariat.net> <07D27DD7-2434-4A2E-91CE-A05D12BBAC2A@netgate.com> <201709230004.SAA22590@mail.lariat.net> <4E771B56-D588-468E-AB60-35DB4DB31318@netgate.com> From: Russell Haley Date: Fri, 22 Sep 2017 18:25:22 -0700 Message-ID: Subject: Re: ARM board recommendations with true GigE ports To: Jim Thompson Cc: Brett Glass , freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 01:25:26 -0000 On Fri, Sep 22, 2017 at 6:23 PM, Russell Haley wrote= : > On Fri, Sep 22, 2017 at 5:36 PM, Jim Thompson wrote: >> >>> On Sep 23, 2017, at 2:03 AM, Brett Glass wrote: >>> >>> At 05:47 PM 9/22/2017, you wrote: >>> >>>> We make a custom product based on the Armada 38xx and it was measured >>>> at high 900 Mbps using a Buildroot Linux. I want to say 980 but the >>>> engineer who did the measurements is away so I can't confirm. >>> >>> So, if this is a recommended SoC for network-related applications, what= commercial boards that use it are recommended? And is there driver support= for them in FreeBSD? >> >> Armada 38x support landed in the tree a couple months back. >> >> Solid-run makes one. Two, actually. >> >> We make one. >> >> Apparently russ.haley@gmail.com is employed by a company that makes one,= though from his description it=E2=80=99s might be an Armada 37x0, and ther= e isn=E2=80=99t any support in the tree for this SoC. > > We make a 12 port Vehicle Switch for Train Ethernet Networks. Our > original prototype testing was done on a Solid-Run Clearfog board (I > would have told them about NetGate if I had known there was an > up-coming product at the time we were prototyping). The final product > is custom hardware. They won't let me play with one (yet). I desperately want to install pfSens= e. > Russ > >>> >>> --Brett Glass >>> >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Sep 23 01:58:40 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57EB6E1E2F9 for ; Sat, 23 Sep 2017 01:58:40 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 2674D2AB0 for ; Sat, 23 Sep 2017 01:58:40 +0000 (UTC) (envelope-from brett@lariat.net) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id TAA23020; Fri, 22 Sep 2017 19:58:35 -0600 (MDT) Message-Id: <201709230158.TAA23020@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 22 Sep 2017 19:58:32 -0600 To: Russell Haley From: Brett Glass Subject: Re: ARM board recommendations with true GigE ports Cc: freebsd-arm In-Reply-To: References: <201709222206.QAA21968@mail.lariat.net> <07D27DD7-2434-4A2E-91CE-A05D12BBAC2A@netgate.com> <201709230004.SAA22590@mail.lariat.net> <4E771B56-D588-468E-AB60-35DB4DB31318@netgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 01:58:40 -0000 At 07:23 PM 9/22/2017, Russell Haley wrote: >We make a 12 port Vehicle Switch for Train Ethernet Networks. Our >original prototype testing was done on a Solid-Run Clearfog board (I >would have told them about NetGate if I had known there was an >up-coming product at the time we were prototyping). The final product >is custom hardware. Which image will run on the Solid-Run Clearfog board? And is there support for the extended version of the board that includes several GigE ports? --Brett Glass From owner-freebsd-arm@freebsd.org Sat Sep 23 05:24:55 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 560B1E26172 for ; Sat, 23 Sep 2017 05:24:55 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDE386774D for ; Sat, 23 Sep 2017 05:24:54 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x233.google.com with SMTP id k9so2732109lfe.10 for ; Fri, 22 Sep 2017 22:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KighvIVEvgOIbq/Dzh6Bgd5pzYGQJdnuQBezZyu/HaQ=; b=ktUDbA7DyxkqTl7BW3Qz4+kHYAXBsD6Flg8l7zI1GPiZjz7IdqBNvsfoY+/V1Sb6+t x5EcZoh6WoWZFzISXtZQgvIjSwDTu0SlTf+SwQ7l9xQFbd9paQqTSGt/o4ForIBDmHt8 Es5oRPsVhT6sTo/c3bL6Pkbs6W8tTi8EW46xYTlmdPu4t4qyKxWrPId5c7GGClXP3g9t rUALBlijWzUxlUHU2KCoty2s41lFyL+h9rknC+xZCTu3S3Sg+bVxLxb+26dQXa75lKOk 80SyRZUzuB2HI73P/0fY/wjnaZ/uwhms9eMq2emYOK6HX0xwJPcQTqBwm37FadZVGL22 nRag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KighvIVEvgOIbq/Dzh6Bgd5pzYGQJdnuQBezZyu/HaQ=; b=TGBUk92pn0uhkAyrRBh86rCXcHACBjCMgTW/9+RlPLBKG4VpMf1Ugo/xG+SnQcgSDE VhGojW8BWdQCaDwwTHWxBoqnfuoW+zL4KtDAvtmwXJq9ElqNmFjPDOWb/bUrEzvtAVz0 rK/6+atNUjLUVIMBQsNqRv+qCp4EOKvdea3qlWg7GsmC0VsmEuwpwNn2ofIwxDzyDjB7 xsB6jFN0v7GoB6cq7nOxfW/FKDgPn/Qk5aLFU1+7kSxPc82qD99+OdSYoaWDRkpF28/w 2Nw469Ge+AEZBEnGM58HH6HRIZzXZqg17AX7F6b7lROgK9nXwEa0rChid6OM8uAkv/Il wYWg== X-Gm-Message-State: AHPjjUjBUBWN1wGupto6cWlzarlYClYzaHJTx+VmC+yoohQ+J4+uxYM0 ttGqDN6Z6sdUBu7cwFoNZIubnc8fi8haHcSbCic= X-Google-Smtp-Source: AOwi7QBj2sekLQjKl9nI4gxHqc/KxnoSew/wj1bf9ZNn2pabjOanSkHXPPXYdXVJEbc3Gh/+OJbsXO84GVf8J4T/5Xw= X-Received: by 10.46.91.5 with SMTP id p5mr591633ljb.22.1506144292923; Fri, 22 Sep 2017 22:24:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Fri, 22 Sep 2017 22:24:51 -0700 (PDT) In-Reply-To: <201709230158.TAA23020@mail.lariat.net> References: <201709222206.QAA21968@mail.lariat.net> <07D27DD7-2434-4A2E-91CE-A05D12BBAC2A@netgate.com> <201709230004.SAA22590@mail.lariat.net> <4E771B56-D588-468E-AB60-35DB4DB31318@netgate.com> <201709230158.TAA23020@mail.lariat.net> From: Russell Haley Date: Fri, 22 Sep 2017 22:24:51 -0700 Message-ID: Subject: Re: ARM board recommendations with true GigE ports To: Brett Glass Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 05:24:55 -0000 On Fri, Sep 22, 2017 at 6:58 PM, Brett Glass wrote: > At 07:23 PM 9/22/2017, Russell Haley wrote: > >> We make a 12 port Vehicle Switch for Train Ethernet Networks. Our >> original prototype testing was done on a Solid-Run Clearfog board (I >> would have told them about NetGate if I had known there was an >> up-coming product at the time we were prototyping). The final product >> is custom hardware. > > > Which image will run on the Solid-Run Clearfog board? And is there support > for the extended version of the board that includes several GigE ports? >From 1000 feet as seen by a novice: The Armada38X conf file for the kernel is in head and I also see it in 11.1 https://svnweb.freebsd.org/base/head/sys/arm/conf/ https://svnweb.freebsd.org/base/release/11.1.0/sys/arm/conf/ARMADA38X?view=log FreeBSD will be agnostic of the number of ports you add if you use supported hardware. The clearfog supports 1 WAN and 5 switched ports via a specific switching chip (I forget which one), which means it's using 2 Gb ports. https://www.solid-run.com/marvell-armada-family/clearfog/clearfog-specifications/ The Armada 38X processor supports 2 or 3 full gigabit devices (buses?) depending on the version. https://www.marvell.com/embedded-processors/armada-38x/ Please correct me if I'm wrong. :) Russ From owner-freebsd-arm@freebsd.org Sat Sep 23 06:18:43 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54B60E27694 for ; Sat, 23 Sep 2017 06:18:43 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2407768A5C for ; Sat, 23 Sep 2017 06:18:43 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-io0-x22d.google.com with SMTP id i197so6159105ioe.9 for ; Fri, 22 Sep 2017 23:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3vuDw7Awdj9okSgf666HTpBpjOA8JfhQIiXeqbKlbo4=; b=dKsiZfiiYsn3IGL4fLlVzb2T0NTrlLtrJDUJwdzLCqdr8Kb9UORh+Gsy8lCukw+0nw jsKzlN9XpufQ8Ufwc/+dXI1FA2246KoM0bC55YR/ZWwv4YGOOCYQpV3t/LL8dHQ0Ukot Hf0VWrb7yELNfX4zAHq8ljYTbIc8ZiX7Q+70c5whbkQAGrPEXdctikdfTG6spxGR5sng 3HlQuKJ1GiwlsZE6gNI7QBKFc5GpvTmYFvmvP96/nk1yfqu5CWD93cw+l7sJXa0JPcTN dccjXFXtRHYY7v9OiDg32OijiM6t8eXWfg1DxeL46PyvGtOOvASSGlk4ZWLdE3MOP6D1 mGBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3vuDw7Awdj9okSgf666HTpBpjOA8JfhQIiXeqbKlbo4=; b=FHAnL5XcnVG1Tv5xDpRc4SK4LQd4u3kylkoZYmQBzkUTTCKJleoKER+245gnDwTFNY XwK4vyFHLzMpr84iC25+e92MXdceoJkZCRnJqk+Iu2+lNKsEod+gwwgerH7HzxmyAjgV R2NrhaQ5vDPZG2WBYlIHqF18CI6of68HK9Ci91HihGeBtWAZTXmIcQM5I0q0HfQWb3ur rY2J1thH8wGpyW07wVBecVOa9lUi/N3+kTfBUeHIk+h6kOUwOc34PyHHE5d9GQ/oC46n bl7bV49Cl2vgJr7x3arbewP8JyeF1LuJS9s5DrqMRASMbX6y47PIo7KVPIF/ftlgXQJP 2VOg== X-Gm-Message-State: AHPjjUi5Ec8r0BP9P5Hb6TWvHI90wzHHSVCYKrHKYno4Kt79W7N+yl3a fQt/UVHF7gxauTiHzjt6aE2bIibeUrdPl3k63LvuUg== X-Google-Smtp-Source: AOwi7QAhrPL8dQXscjmO1hkFBNkGZFB83j0GthRHLkdvykeOr9htgsv2rKKRReik212hqO5evVtJmn4yPJfz2mAE4Y8= X-Received: by 10.107.139.215 with SMTP id n206mr2056129iod.155.1506147522420; Fri, 22 Sep 2017 23:18:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.145.131 with HTTP; Fri, 22 Sep 2017 23:18:41 -0700 (PDT) In-Reply-To: <4E771B56-D588-468E-AB60-35DB4DB31318@netgate.com> References: <201709222206.QAA21968@mail.lariat.net> <07D27DD7-2434-4A2E-91CE-A05D12BBAC2A@netgate.com> <201709230004.SAA22590@mail.lariat.net> <4E771B56-D588-468E-AB60-35DB4DB31318@netgate.com> From: Marcin Wojtas Date: Sat, 23 Sep 2017 08:18:41 +0200 Message-ID: Subject: Re: ARM board recommendations with true GigE ports To: Jim Thompson Cc: Brett Glass , freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 06:18:43 -0000 Hi Jim, 2017-09-23 2:36 GMT+02:00 Jim Thompson : > >> On Sep 23, 2017, at 2:03 AM, Brett Glass wrote: >> >> At 05:47 PM 9/22/2017, you wrote: >> >>> We make a custom product based on the Armada 38xx and it was measured >>> at high 900 Mbps using a Buildroot Linux. I want to say 980 but the >>> engineer who did the measurements is away so I can't confirm. >> >> So, if this is a recommended SoC for network-related applications, what = commercial boards that use it are recommended? And is there driver support = for them in FreeBSD? > > Armada 38x support landed in the tree a couple months back. > > Solid-run makes one. Two, actually. > > We make one. > > Apparently russ.haley@gmail.com is employed by a company that makes one, = though from his description it=E2=80=99s might be an Armada 37x0, and there= isn=E2=80=99t any support in the tree for this SoC. > Actually about 3 weeks ago Semihalf did upstream support for the SoC. GENERIC arm64 config works on A3700 (brand new uart driver, network, usb 3.0 and 2.0, sata 3.0). What's missing is PCIe RC and SD/MMC driver. BTW. Armada 7k/8k family is supported as well now in the HEAD (uart, usb 3.0, sata 3.0, RTC). Missing features are network driver, PCIe RC and SD/MMC (last one shared with A3700). Best regards, Marcin From owner-freebsd-arm@freebsd.org Sat Sep 23 06:37:13 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39218E27F64 for ; Sat, 23 Sep 2017 06:37:13 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACBE7697C5 for ; Sat, 23 Sep 2017 06:37:12 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x232.google.com with SMTP id l196so2819373lfl.1 for ; Fri, 22 Sep 2017 23:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Wauf977+z8wgfW9dG5gHlKzFd7no8qjyeuAzyUvKpAo=; b=TRPU/Too8Cg/3pRfUlK0qka5XJb1z8Xp1ZNOcy9Hjld6Zw3u9s11lEDnLw9yK+7ncl GQetzxVmNqhY0zQc4lrZXGSdUrvwdq7UxVe8ssLgvQUL4PlfglDMkcSQ9jrJlY6nzDwg NtTknjQEuT80CkjbWgq+bbTIaUKup/789I6nZpZIk5df19TCXkx+ACPD6O58MyAxBYgn /Fl/7U7hHeHs6WkUuL6tuQVLsC5cHrmRWPWu04foHg+RfsDn3Zy/K3MZKPUYAAwf6HhA POqOW0yAFrPx8JmVmZQFUVPxmmQx6QjlEmoJlvS6VL4b+HcIFQIdsi2/3jrAIui+UJf6 b9+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Wauf977+z8wgfW9dG5gHlKzFd7no8qjyeuAzyUvKpAo=; b=acBbdWXSnG+sigx1xJOBr0sbbOcWUXgLWrFbRh8ITUNSSaTuYerdiMb/r2FS2i/3H6 gdwII0nQiviQ8rbk+Gzy/EfV1hB4iZh0whl5mGyMCkSrPQ2BT6Vj41egpG4tshmY9V61 Qx4U4FJQ7Izv3yswqTFPXd+g2gBqpejk6hF4DuxeP1CBUy/6dpZVs2AfjJp5tjwwjRXa htqWi/NnxVYm7sU4h/V9DfsZdtYPgGbuCbRID45rAyR646cin0NFlPXPHDOWYBWcKkBL n/HInGTofbCCjzSIml7a3bps4UR8tbXY71fR3qGvMMGtIkI0s+i18gq15uCLWil1sWBK Jmtg== X-Gm-Message-State: AHPjjUjPL5nfrldpwsq1G7cWa9mWQQXfQyQU9F/uhvc/3fMf86z3tKZq EzMh/XigbIiAXrwVch0UGTqhQ9BqevSwYVYqCGM/rA== X-Google-Smtp-Source: AOwi7QDLAWq9wRLuvFUFRR//2iTODVI+V52XTIEXEo24cSdNOxF2a6gZLMN4mpZRzLGp0efqJOSuIm5ZHCboQHk34Bg= X-Received: by 10.46.21.25 with SMTP id s25mr514358ljd.71.1506148630933; Fri, 22 Sep 2017 23:37:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Fri, 22 Sep 2017 23:37:10 -0700 (PDT) In-Reply-To: References: <201709222206.QAA21968@mail.lariat.net> <07D27DD7-2434-4A2E-91CE-A05D12BBAC2A@netgate.com> <201709230004.SAA22590@mail.lariat.net> <4E771B56-D588-468E-AB60-35DB4DB31318@netgate.com> From: Russell Haley Date: Fri, 22 Sep 2017 23:37:10 -0700 Message-ID: Subject: Re: ARM board recommendations with true GigE ports To: Marcin Wojtas Cc: Jim Thompson , freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 06:37:13 -0000 On Fri, Sep 22, 2017 at 11:18 PM, Marcin Wojtas wrote: > Hi Jim, > > 2017-09-23 2:36 GMT+02:00 Jim Thompson : >> >>> On Sep 23, 2017, at 2:03 AM, Brett Glass wrote: >>> >>> At 05:47 PM 9/22/2017, you wrote: >>> >>>> We make a custom product based on the Armada 38xx and it was measured >>>> at high 900 Mbps using a Buildroot Linux. I want to say 980 but the >>>> engineer who did the measurements is away so I can't confirm. >>> >>> So, if this is a recommended SoC for network-related applications, what= commercial boards that use it are recommended? And is there driver support= for them in FreeBSD? >> >> Armada 38x support landed in the tree a couple months back. >> >> Solid-run makes one. Two, actually. >> >> We make one. >> >> Apparently russ.haley@gmail.com is employed by a company that makes one,= though from his description it=E2=80=99s might be an Armada 37x0, and ther= e isn=E2=80=99t any support in the tree for this SoC. >> > > Actually about 3 weeks ago Semihalf did upstream support for the SoC. > GENERIC arm64 config works on A3700 (brand new uart driver, network, > usb 3.0 and 2.0, sata 3.0). What's missing is PCIe RC and SD/MMC > driver. > > BTW. Armada 7k/8k family is supported as well now in the HEAD (uart, > usb 3.0, sata 3.0, RTC). Missing features are network driver, PCIe RC > and SD/MMC (last one shared with A3700). Armada 7k/8k armv7 emulation or aarch64? > Best regards, > Marcin > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Sep 23 06:41:42 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BAFBE2817A for ; Sat, 23 Sep 2017 06:41:42 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0DB4969CAC for ; Sat, 23 Sep 2017 06:41:42 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x22d.google.com with SMTP id a18so2807202lfl.13 for ; Fri, 22 Sep 2017 23:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QULuosU7F1aoH1hhPQHRKuaIJE5DkZMVM5xiqQKNsb8=; b=n3XUt6Ge8wJ40L4LomKfdk51gz7DkI0tdCVfMSQBfTJx59UJEr7wKS9Vq0hNomhYR/ 5VwltpcuFieWS4BL4U/wGxV+no3+iEmpoi20WMBi0oo3kLngWcsNcyOGAM1uDJCgNETl 5dA7m/XMsqhUUAfaH5I+qPP6GRyGKBHtmThG63YeuQOMvHy6UjalGUYIzgUagZbOI9vj yK62kROkCMSZ2WhruCdoFdnd5ANhMTklXxRtxosgsFMWVuh5Fppx/J5Hv8qwnFmABqB4 WSnZwUYcHXfnY78MkmYMYzh0lnL30l9231MoeLT/5hDIPW/hya1ahf+VhyXy9hMgObmO le/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QULuosU7F1aoH1hhPQHRKuaIJE5DkZMVM5xiqQKNsb8=; b=OG3DDmBQvfv3v6sdNYjYw4U50SO2H3NhG/06EU++JSvkz2fd98bkHr58qSDAE87xvR uKJPiT0ubqZU4yr1bxdZAKkHCHX2o/Ogw1mVdT32o1t3NVlGNU7gk4GaFoTxKWlGOlar L3D2dC5Zmd15fFP+BZI9tzQgVBwKJ3PoOn4ucrmbQivr+BwQjfBs7VS9P5l2RqH8BzM2 w7cD+KMcCngeCpHBu2wEqIUmFzufkFd/Q55Hq11DVQlMEZPUzlymfKVsDoOAdLKPbwke IX+oW+Yv6yAopL8C2uU8O+Xs31PuDhzhHw0ePYQhm9JZBvBeBOYzPVfkxg2FoZNmuVP9 /tWA== X-Gm-Message-State: AHPjjUh7npuMCG0v6e6IAN6WNNZE5TobwGZVCycWiZxINUKei0wZ+uPi /xj7lvZPp7bk5htlJcqXVFs6NWn16sKR5xqbiVs= X-Google-Smtp-Source: AOwi7QAdv67kvszSwCeZI8OHLh0KN5sRSVgKIz8L7YFz7pWyRltyCAxzBX/SnzhNlejcGaHbevP3iH5ghAOw8dKV6qw= X-Received: by 10.25.19.197 with SMTP id 66mr413356lft.221.1506148899712; Fri, 22 Sep 2017 23:41:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Fri, 22 Sep 2017 23:41:39 -0700 (PDT) In-Reply-To: References: <201709222206.QAA21968@mail.lariat.net> <07D27DD7-2434-4A2E-91CE-A05D12BBAC2A@netgate.com> <201709230004.SAA22590@mail.lariat.net> <4E771B56-D588-468E-AB60-35DB4DB31318@netgate.com> From: Russell Haley Date: Fri, 22 Sep 2017 23:41:39 -0700 Message-ID: Subject: Re: ARM board recommendations with true GigE ports To: Marcin Wojtas Cc: Jim Thompson , freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 06:41:42 -0000 On Fri, Sep 22, 2017 at 11:37 PM, Russell Haley wrot= e: > On Fri, Sep 22, 2017 at 11:18 PM, Marcin Wojtas wrote: >> Hi Jim, >> >> 2017-09-23 2:36 GMT+02:00 Jim Thompson : >>> >>>> On Sep 23, 2017, at 2:03 AM, Brett Glass wrote: >>>> >>>> At 05:47 PM 9/22/2017, you wrote: >>>> >>>>> We make a custom product based on the Armada 38xx and it was measured >>>>> at high 900 Mbps using a Buildroot Linux. I want to say 980 but the >>>>> engineer who did the measurements is away so I can't confirm. >>>> >>>> So, if this is a recommended SoC for network-related applications, wha= t commercial boards that use it are recommended? And is there driver suppor= t for them in FreeBSD? >>> >>> Armada 38x support landed in the tree a couple months back. >>> >>> Solid-run makes one. Two, actually. >>> >>> We make one. >>> >>> Apparently russ.haley@gmail.com is employed by a company that makes one= , though from his description it=E2=80=99s might be an Armada 37x0, and the= re isn=E2=80=99t any support in the tree for this SoC. >>> >> >> Actually about 3 weeks ago Semihalf did upstream support for the SoC. >> GENERIC arm64 config works on A3700 (brand new uart driver, network, >> usb 3.0 and 2.0, sata 3.0). What's missing is PCIe RC and SD/MMC >> driver. >> >> BTW. Armada 7k/8k family is supported as well now in the HEAD (uart, >> usb 3.0, sata 3.0, RTC). Missing features are network driver, PCIe RC >> and SD/MMC (last one shared with A3700). > > Armada 7k/8k > armv7 emulation or aarch64? Sorry, didn't mean emulation: armv7 or aarch64? That's one sweet Network Video Recorder with two Sata 3.0 and a 10 Gb nic... >> Best regards, >> Marcin >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Sep 23 06:49:19 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C478E28499 for ; Sat, 23 Sep 2017 06:49:19 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 24E3069E90 for ; Sat, 23 Sep 2017 06:49:19 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-io0-x22b.google.com with SMTP id z187so6180383ioz.12 for ; Fri, 22 Sep 2017 23:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YFmejakGceePVyi5vjUkLPzE9WPcVWDeyE5LTEGuovM=; b=XlDaQAlANlIYorIhQZzbHB1CqjxdPzVjXfckYh6i4B0sc4+AxQmLJCwmfES7Li/GgA Ie4yNJnvoXKM4mOtreoxx0usmHYzWlqjLfKflhN/8BdaOnUdNa2ASQJotupjcf/2pNIa iXdbJIx6JB4XqveZGNgfIO78iYPJZA2z20n26mJEG3v1My1YNerv/hTU9xQza4dOut/f nqAgaSzfcBd2b2cICmPYWi9y5JGPGjd33CysryuaEc0RZOKuUlPCS5v0wu3PRXjfEDhP g5UYJRdk12QJXf5y/nOPd8krN8q9SYBl5OaTmmXLM3iHESw8/8OGQ5xaIuqa4GclR1fX w41g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YFmejakGceePVyi5vjUkLPzE9WPcVWDeyE5LTEGuovM=; b=SbwCXvEbNADRaGdyXUTf9IKgjjF9uobO700M4PzB0c68YsHGJ/PllTzacBEnydhQSv +wF9gYtvDz7XKG3HfaEwubdrg2EMOrDpVd+JzIjOjvHngbD5emuWSRhai0f7pRHCIT8d NyVElj1j9eBqihkMLUBDpWgg7/2SLYlr2jQ1qeQzzEwD2KlWdnqq32bftpMCiPtfDeP5 02wC2fa0TPUZD8tBNvIdMTQKPk0N+LUoLwcme8NTdl7eltFsrBZwYve8AMlhnw7pf/Cp gO+tqqx2nekgJYlasRj01PK4ocTFesC0+z61ja6bTi1nbl19F3KcMdatbVFUj+6UwXMj AlSA== X-Gm-Message-State: AHPjjUhSMGuR3ZGmMm+CFkh7y1WSTjW3sU5o7+OgRoQ9a/NvP9S+stnr DM/V0oHVOMtbcbqPsplLAU/dR+Cl8vjz6Cguc3V7Tw== X-Google-Smtp-Source: AOwi7QBdIgJUEmJziopnUUgC9OApymFmdKBmRnduWpQlR+MKhoKuBcHvZ/sHv8BGpnUgzm2A9E0/UzweFmhUeYlKiUQ= X-Received: by 10.107.134.229 with SMTP id q98mr1971751ioi.262.1506149358453; Fri, 22 Sep 2017 23:49:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.145.131 with HTTP; Fri, 22 Sep 2017 23:49:17 -0700 (PDT) In-Reply-To: References: <201709222206.QAA21968@mail.lariat.net> <07D27DD7-2434-4A2E-91CE-A05D12BBAC2A@netgate.com> <201709230004.SAA22590@mail.lariat.net> <4E771B56-D588-468E-AB60-35DB4DB31318@netgate.com> From: Marcin Wojtas Date: Sat, 23 Sep 2017 08:49:17 +0200 Message-ID: Subject: Re: ARM board recommendations with true GigE ports To: Russell Haley Cc: Jim Thompson , freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 06:49:19 -0000 2017-09-23 8:41 GMT+02:00 Russell Haley : > On Fri, Sep 22, 2017 at 11:37 PM, Russell Haley wr= ote: >> On Fri, Sep 22, 2017 at 11:18 PM, Marcin Wojtas wrote: >>> Hi Jim, >>> >>> 2017-09-23 2:36 GMT+02:00 Jim Thompson : >>>> >>>>> On Sep 23, 2017, at 2:03 AM, Brett Glass wrote: >>>>> >>>>> At 05:47 PM 9/22/2017, you wrote: >>>>> >>>>>> We make a custom product based on the Armada 38xx and it was measure= d >>>>>> at high 900 Mbps using a Buildroot Linux. I want to say 980 but the >>>>>> engineer who did the measurements is away so I can't confirm. >>>>> >>>>> So, if this is a recommended SoC for network-related applications, wh= at commercial boards that use it are recommended? And is there driver suppo= rt for them in FreeBSD? >>>> >>>> Armada 38x support landed in the tree a couple months back. >>>> >>>> Solid-run makes one. Two, actually. >>>> >>>> We make one. >>>> >>>> Apparently russ.haley@gmail.com is employed by a company that makes on= e, though from his description it=E2=80=99s might be an Armada 37x0, and th= ere isn=E2=80=99t any support in the tree for this SoC. >>>> >>> >>> Actually about 3 weeks ago Semihalf did upstream support for the SoC. >>> GENERIC arm64 config works on A3700 (brand new uart driver, network, >>> usb 3.0 and 2.0, sata 3.0). What's missing is PCIe RC and SD/MMC >>> driver. >>> >>> BTW. Armada 7k/8k family is supported as well now in the HEAD (uart, >>> usb 3.0, sata 3.0, RTC). Missing features are network driver, PCIe RC >>> and SD/MMC (last one shared with A3700). >> >> Armada 7k/8k >> armv7 emulation or aarch64? > Sorry, didn't mean emulation: armv7 or aarch64? That's one sweet > Network Video Recorder with two Sata 3.0 and a 10 Gb nic... > This is quad Cortex-A72 Marvell SoC, you can read more here: http://macchiatobin.net/ The chip has up to 4 Sata and 2x 10Gb (and 4x 1Gb/2.5Gb). Best regards, Marcin From owner-freebsd-arm@freebsd.org Sat Sep 23 07:01:28 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A3F9E28865 for ; Sat, 23 Sep 2017 07:01:28 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94FEC6A3A4 for ; Sat, 23 Sep 2017 07:01:27 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-wm0-x22a.google.com with SMTP id b195so8464153wmb.5 for ; Sat, 23 Sep 2017 00:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YR5fM4++sC3Cyx3HUMAd3SwODN17K2pU6rFVa46P8NI=; b=RSbmHgNbLHBahNc4C/9z1TSGEZ6Z+0YZADpZE/F886N31+T2x0V6CLpC10rJT+IQ6J C/98h/Eyw71G4Se6PokwnZGDCPGbWHoljbT1RKUsPDEj4ItUCrNcocYrFtkwhixKdubZ XYY4tJjlpv2A09mlmGQUjhX/Mhv9thaOb7CU8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YR5fM4++sC3Cyx3HUMAd3SwODN17K2pU6rFVa46P8NI=; b=dMhMwajPSYLCwZXUexRYDlLr/R/k1q2QjZZsyO0ymU9XrntZisqMwunBrKo37Ukr7s uJnnFRitdO4HviA6WlhXX0RIV9IdJLIQnnt7fBkjJ+qxy/qJPS81bLnnT0Cbk8YP+LFw qrb01uSi4V1SqqBcYM9572lEGII8G3hkwQHzs4SIib6Or9AmskiACegjq1xb+EMsrRj0 lSJZ48H5HuFqE7vGasBWBk1SMSy/5AL4m8eerG1EUaoVH9+tcbKBk/GKDdjiVm7NtRre xrC14G+GDF50JQXmcaS8soIYae6YoQ0DVR0EltWf+1jDfE6X+heqWzHrxnzaBF6anstI 174Q== X-Gm-Message-State: AHPjjUj51IJdWzwVOtvsCiSozHQY7NYLejjUqt9sJDW1vEmpKbM/NjYG lIEECvMu32oiN3CePHTg+q5rg9dGe/c= X-Google-Smtp-Source: AOwi7QAaDCxOIhS+23nRnLpjil3ZFpUJIlkJGoI0Z4v5Pyp6Q23BgBHBYuAQ0CG5voTqHj/Oziin7A== X-Received: by 10.28.183.85 with SMTP id h82mr5855506wmf.24.1506150084711; Sat, 23 Sep 2017 00:01:24 -0700 (PDT) Received: from [192.168.2.47] (LNeuilly-656-1-101-235.w193-248.abo.wanadoo.fr. [193.248.221.235]) by smtp.gmail.com with ESMTPSA id a19sm1921735wra.64.2017.09.23.00.01.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Sep 2017 00:01:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: ARM board recommendations with true GigE ports From: Jim Thompson X-Mailer: iPhone Mail (15A372) In-Reply-To: Date: Sat, 23 Sep 2017 09:01:22 +0200 Cc: Brett Glass , freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <944E946C-99EC-4DD5-B8A2-5895F7A9942C@netgate.com> References: <201709222206.QAA21968@mail.lariat.net> <07D27DD7-2434-4A2E-91CE-A05D12BBAC2A@netgate.com> <201709230004.SAA22590@mail.lariat.net> <4E771B56-D588-468E-AB60-35DB4DB31318@netgate.com> To: Marcin Wojtas X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 07:01:28 -0000 > On Sep 23, 2017, at 8:18 AM, Marcin Wojtas wrote: > > Actually about 3 weeks ago Semihalf did upstream support for the SoC. > GENERIC arm64 config works on A3700 (brand new uart driver, network, > usb 3.0 and 2.0, sata 3.0). What's missing is PCIe RC and SD/MMC > driver. > > BTW. Armada 7k/8k family is supported as well now in the HEAD (uart, > usb 3.0, sata 3.0, RTC). Missing features are network driver, PCIe RC > and SD/MMC (last one shared with A3700). > > Best regards, > Marcin Marcin, Cool. I saw the 8040 support go in, but missed the 3700 support. Thanks! Jim