From owner-freebsd-arm@freebsd.org Sun Mar 11 01:58:10 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 701D2F4AC9C for ; Sun, 11 Mar 2018 01:58: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 E8CB37142E for ; Sun, 11 Mar 2018 01:58:09 +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 8a570b18; Sun, 11 Mar 2018 02:58:01 +0100 (CET) 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=At7mhm0xAYv2i/PjGNFWZR7dZK8=; b=XOYGOe3VNqB3SuD+fhiyHafvWef0 OVfi2jIBJG6HsXpFrFau0fqKJq5znzjDovMB6E5vcMTOhj83rhRpT9RQ24R8kZpp ulg1jm00Px+5F/+QRwqIQIWQ2ZfjeBKzF67RJfypekDvdTecftgOVFM4hoY49rVn 9unuRa/w6dYaCOA= 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=UfiyeQN3FANuDtGUK4/R3x+oA32AEobmAuioT0kt+Odt2MlZLm/niWWc ZemquNmuVbxxLA6TDdKLUPdTtbYOdwOs3g2phncsL61ue8NJeW9HXcFWcMwZiib7 4XlOl+Hx6/OttlpLCNYE3ajOKhpCHXEm0NRRO7U6zys+Phoi5WA= Received: from arcadia (ai126174027189.26.access-internet.ne.jp [126.174.27.189]) by mail.blih.net (OpenSMTPD) with ESMTPSA id b27dc05c TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sun, 11 Mar 2018 02:58:01 +0100 (CET) Date: Sun, 11 Mar 2018 02:57:56 +0100 From: Emmanuel Vadot To: Luc Hondareyte Cc: Luc Hondareyte via freebsd-arm Subject: Re: cpufreq support on Allwinner H3 Message-Id: <20180311025756.bbddd0616bc61d78f66093a5@bidouilliste.com> In-Reply-To: <542a7663-b4e0-2093-4dfc-9b8e9c3b513b@laposte.net> References: <5332936b-f38b-ca7a-03d9-dfc7c92e2727@laposte.net> <20180308061806.d9c9c7282d1a956d86b6bb22@bidouilliste.com> <542a7663-b4e0-2093-4dfc-9b8e9c3b513b@laposte.net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) 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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 01:58:10 -0000 On Thu, 8 Mar 2018 12:33:44 +0100 Luc Hondareyte wrote: > Le 08/03/2018 =E0 06:18, Emmanuel Vadot a =E9crit=A0: > > On Tue, 6 Mar 2018 20:59:37 +0100 > > Luc Hondareyte via freebsd-arm wrote: > > > >> Hi, > >> > >> I've just build 12-current for Allwinner H3=A0 (armv7) and it seems th= at > >> cpufreq support is missing (orangepi or nanopi): > > There is no opp table (freq<->voltage table) in the DTS that's why > > it's not working. > This thread?=20 > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-February/55794= 0.html=20 Yep exactly. > > I think I've seen patches on the linux-arm kernel mailing list to add > > them but even with thoses we will need support for the v2 opp. > v2 opp? Does it mean that, as a workaround, with the appropriate DTS=20 > patch and a switch back to armv6, this should work? Switch back to armv6 will change nothing but a patched dtb will do the job. That what we had before and that's why on ganbold@ images cpufreq works. Since I don't want patched DTB in the tree our only option is to implement v2 opp table in sys/dev/cpufreq/cpufreq_dt.c and wait that the dts is updated upstream. > I say that because,=20 > on nanopi neo, with the "old" 12-current image build by Ganbold=20 > Tsagaankhuu (that was available on FriendlyArm Wiki), cpu_freq support=20 > is OK and it?s run at full speed: >=20 > root@allwinner-h3:~ # uname -a > FreeBSD allwinner-h3 12.0-CURRENT FreeBSD 12.0-CURRENT #7 r308116M: Mon=20 > Oct 31 10:56:20 ULAT 2016=20 > tsgan@beastie.mstride.com:/usr/obj/arm.armv6/usr/src/sys/GENERIC arm > root@allwinner-h3:~ # sysctl dev.cpu.0.freq > cpufreq: get returning known freq 1008 > cpufreq: get returning known freq 1008 > dev.cpu.0.freq: 1008 >=20 > And this image does not seem to use Linux DTS. > >> root@allwinner-h3:~ # service powerd onestart > >> Starting powerd. > >> powerd: no cpufreq(4) support -- aborting: No such file or directory > >> /etc/rc.d/powerd: WARNING: failed to start powerd > >> > >> So, on nanopi neo, it's slowdown (not on orange-pi that seems to run at > >> full speed). I am using a custom kernel conf that just contains: > >> > >> include GENERIC > >> nooptions=A0=A0=A0=A0=A0=A0 INVARIANTS > >> nooptions=A0=A0=A0=A0=A0=A0 INVARIANT_SUPPORT > >> nooptions=A0=A0=A0=A0=A0=A0 WITNESS > >> nooptions=A0=A0=A0=A0=A0=A0 WITNESS_SKIPSPIN > >> nooptions=A0=A0=A0=A0=A0=A0 BUF_TRACKING > >> nooptions=A0=A0=A0=A0=A0=A0 DEADLKRES > >> nooptions=A0=A0=A0=A0=A0=A0 FULL_BUF_TRACKING > >> > > You can use the GENERIC-NODEBUG for that > > > Oh, I missed that. Thanks. --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sun Mar 11 18:55:26 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 807BDF45E0A for ; Sun, 11 Mar 2018 18:55:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 09E917910B for ; Sun, 11 Mar 2018 18:55:26 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 147E138EA for ; Sun, 11 Mar 2018 18:55:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2BItOb7077194 for ; Sun, 11 Mar 2018 18:55:24 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2BItOEn077193 for freebsd-arm@FreeBSD.org; Sun, 11 Mar 2018 18:55:24 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 226536] glabel/partition mixup on sdcard images Date: Sun, 11 Mar 2018 18:55:25 +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 Some People X-Bugzilla-Who: trasz@FreeBSD.org 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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 18:55:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226536 Bug ID: 226536 Summary: glabel/partition mixup on sdcard images Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: trasz@FreeBSD.org The sdcard images distributed by the project contain two level (MBR/BSD) partition table. The root filesystem is mounted using UFS label, "ufs/root= fs". Problem is, the label gets attached to the wrong device: mmcsd0s2 instead = of mmcsd0s2a. The result is that on first startup, only the first level of partition table gets resized, which can result in significant confusion when moving the SD card to another system. Looking at the image on another system (using md(4)), it looks like this: [trasz@brick:~]% gpart show [snip] =3D> 63 6291393 md0 MBR (3.0G) 63 961 - free - (481K) 1024 34816 1 !12 [active] (17M) 35840 6255616 2 freebsd (3.0G) =3D> 0 6255616 md0s2 BSD (3.0G) 0 6255616 1 freebsd-ufs (3.0G) =3D> 0 6255616 ufsid/5a570a62577263b8 BSD (3.0G) 0 6255616 1 freebsd-ufs (3.0G) =3D> 0 6255616 ufs/rootfs BSD (3.0G) 0 6255616 1 freebsd-ufs (3.0G) [trasz@brick:~]% glabel list=20=20=20 [snip] Geom name: md0s1=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Providers:=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1. Name: msdosfs/MSDOSBOOT Mediasize: 17825792 (17M) Sectorsize: 512=20=20=20=20=20=20=20 Stripesize: 0 Stripeoffset: 524288 Mode: r0w0e0=20=20=20=20=20=20 secoffset: 0=20=20=20=20=20=20 offset: 0=20=20=20=20=20=20=20=20=20 seclength: 34816 length: 17825792=20=20=20=20=20=20=20=20=20=20=20=20 index: 0=20=20=20=20=20=20=20 Consumers:=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1. Name: md0s1=20=20=20=20=20=20=20=20=20=20=20 Mediasize: 17825792 (17M) Sectorsize: 512=20=20=20=20=20=20=20 Stripesize: 0 Stripeoffset: 524288 Mode: r0w0e0 Geom name: md0s2 Providers: 1. Name: ufsid/5a570a62577263b8 Mediasize: 3202875392 (3.0G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 18350080 Mode: r0w0e0 secoffset: 0 offset: 0 seclength: 6255616 length: 3202875392 index: 0 Consumers: 1. Name: md0s2 Mediasize: 3202875392 (3.0G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 18350080 Mode: r0w0e0 Geom name: md0s2 Providers: 1. Name: ufs/rootfs Mediasize: 3202875392 (3.0G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 18350080 Mode: r0w0e0 secoffset: 0 offset: 0 seclength: 6255616 length: 3202875392 index: 0 Consumers: 1. Name: md0s2 Mediasize: 3202875392 (3.0G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 18350080 Mode: r0w0e0 Notice how the last consumer is md0s2 instead of md0s2a. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sun Mar 11 19:39:13 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39A5BF49304 for ; Sun, 11 Mar 2018 19:39:13 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9003A7AE8D for ; Sun, 11 Mar 2018 19:39:11 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Sun, 11 Mar 2018 20:34:01 +0100 id 00DD6046.5AA584A9.000041F5 Date: Sun, 11 Mar 2018 20:34:00 +0100 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: GENERIC-MMCCAM/SDIO on Allwinner? Message-ID: <20180311203400.134f10cf@zeta.dino.sk> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; i386-portbld-freebsd10.4) 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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 19:39:13 -0000 Hi, I saw there is GENERIC-MMCCAM kernel config file now, which should make posible to try SDIO on arm boards, so I decided to try it on my Allwinner H2+ based Orange Pi Zero. It did not work, there was no disk found for root file system. Examining console output, I found no mention of aw_mmc device. I read wiki at https://wiki.freebsd.org/SDIO and looked over another boards device drivers, and came with following modification to /usr/sys/arm/allwinner/files.allwinner --- files.allwinner.orig 2018-03-11 08:23:34.971413000 +0100 +++ files.allwinner 2018-03-11 08:28:56.972933000 +0100 @@ -10,7 +10,7 @@ arm/allwinner/aw_gpio.c optional gpio arm/allwinner/aw_if_dwc.c optional dwc arm/allwinner/aw_machdep.c standard -arm/allwinner/aw_mmc.c optional mmc +arm/allwinner/aw_mmc.c optional mmc | mmccam arm/allwinner/aw_mp.c optional smp arm/allwinner/aw_nmi.c optional intrng arm/allwinner/aw_rsb.c optional rsb | p2wi and /usr/sys/arm/allwinner/aw_mmc.c --- aw_mmc.c.orig 2018-03-11 08:25:05.979124000 +0100 +++ aw_mmc.c 2018-03-11 08:25:56.993269000 +0100 @@ -52,6 +52,8 @@ #include #include +#include "opt_mmccam.h" + #define AW_MMC_MEMRES 0 #define AW_MMC_IRQRES 1 #define AW_MMC_RESSZ 2 @@ -1062,4 +1064,6 @@ DRIVER_MODULE(aw_mmc, simplebus, aw_mmc_driver, aw_mmc_devclass, NULL, NULL); +#ifndef MMCCAM MMC_DECLARE_BRIDGE(aw_mmc); +#endif This makes kernel with aw_mmc device, but it does not work either, in console output was just aw_mmc0: mem 0x1c0f000-0x1c0ffff irq 5 on simplebus0 aw_mmc0: vmmc-supply regulator found aw_mmc0: attaching MMC child failed! device_attach: aw_mmc0 attach returned 6 aw_mmc0: mem 0x1c10000-0x1c10fff irq 6 on simplebus0 aw_mmc0: cannot reset the controller device_attach: aw_mmc0 attach returned 6 (there are two devices in dtb, first one is for SD card with root filesystem, second one is for wifi/bluetooth device). This makes actually sense - there is no device mmc in MMCCAM kernel config files, however, I am no step nearer now to usable SDIO on Allwinner SoC. With some more look over sources I realised aw_mmc is not the same as drivers for devices with working MMCCAM according wiki mentioned above - in aw_mmc method table, we have just device, bus and MMC bridge interface, whereas others have SDHCI interface in addition. And naming suggests it too - aw_mmc vs. ti_sdhci and bcm2835_sdhci... All this together, it looks like aw_mmc needs some rework in order to be able to move to MMCCAM framework. Did anybody something more already which could be shared? regards, Milan From owner-freebsd-arm@freebsd.org Sun Mar 11 21:01:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 189EAF4E9BE for ; Sun, 11 Mar 2018 21:01:05 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 923227EBD4 for ; Sun, 11 Mar 2018 21:01:04 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id A082C4B4E for ; Sun, 11 Mar 2018 21:01:03 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2BL13lW026433 for ; Sun, 11 Mar 2018 21:01:03 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2BL13ln026422 for freebsd-arm@FreeBSD.org; Sun, 11 Mar 2018 21:01:03 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201803112101.w2BL13ln026422@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 11 Mar 2018 21:01:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 21:01:05 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 220297 | arch(7) rename arm64 to aarch64 respecting `uname 1 problems total for which you should take action. From owner-freebsd-arm@freebsd.org Sun Mar 11 23:17:06 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8385F2F0F4 for ; Sun, 11 Mar 2018 23:17:05 +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 55DE6845A7 for ; Sun, 11 Mar 2018 23:17:04 +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 74b735f6; Mon, 12 Mar 2018 00:17:02 +0100 (CET) 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=I+1KutcmtFJs/XENEN5jz4igq1w=; b=oRvhc34vu5WsvMRiwCaqlTDt8nWH Kwql5cdlU9xd3gZUHCfGHpJm8t9AYSNYlomgwuW+toh0TVZIeWs3FkzWAN57BNVZ 9uh/nGC6t41U9uFPj9ITzSpKBezLZ3mcIydQTBlrvcLV7jzdcK+Lt0UsKTLe7mLw 8+h3JBaT0rf9Vic= 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=BOory5S6MKsqrIge+sZZvgJXh89zBkXvygI9+kCXcVtVeZj1M1/345/g RutTJELIFcXa3gzO32gdqvlYpHR4olSGz7NeN8l78rP8jUSxslGvBNyd+/MAYQ/3 6O8R1bUNC2HK2vuYzBwhRbPcVXabi96nIVKKKWpAD7sPCw+NmXg= Received: from arcadia (ai126174027189.26.access-internet.ne.jp [126.174.27.189]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 4c9fca9b TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 12 Mar 2018 00:17:01 +0100 (CET) Date: Mon, 12 Mar 2018 00:16:56 +0100 From: Emmanuel Vadot To: Milan Obuch Cc: freebsd-arm@freebsd.org Subject: Re: GENERIC-MMCCAM/SDIO on Allwinner? Message-Id: <20180312001656.03013fb2359e5215c0f9b766@bidouilliste.com> In-Reply-To: <20180311203400.134f10cf@zeta.dino.sk> References: <20180311203400.134f10cf@zeta.dino.sk> X-Mailer: Sylpheed 3.7.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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 23:17:06 -0000 On Sun, 11 Mar 2018 20:34:00 +0100 Milan Obuch wrote: > Hi, > > I saw there is GENERIC-MMCCAM kernel config file now, which should make > posible to try SDIO on arm boards On supported arm boards. > so I decided to try it on my > Allwinner H2+ based Orange Pi Zero. It did not work, there was no disk > found for root file system. Examining console output, I found no > mention of aw_mmc device. > > I read wiki at https://wiki.freebsd.org/SDIO and looked over another > boards device drivers, and came with following modification to > /usr/sys/arm/allwinner/files.allwinner > > --- files.allwinner.orig 2018-03-11 08:23:34.971413000 +0100 > +++ files.allwinner 2018-03-11 08:28:56.972933000 +0100 > @@ -10,7 +10,7 @@ > arm/allwinner/aw_gpio.c optional gpio > arm/allwinner/aw_if_dwc.c optional dwc > arm/allwinner/aw_machdep.c standard > -arm/allwinner/aw_mmc.c optional mmc > +arm/allwinner/aw_mmc.c optional mmc | mmccam > arm/allwinner/aw_mp.c optional smp > arm/allwinner/aw_nmi.c optional intrng > arm/allwinner/aw_rsb.c optional rsb | p2wi > > and /usr/sys/arm/allwinner/aw_mmc.c > > --- aw_mmc.c.orig 2018-03-11 08:25:05.979124000 +0100 > +++ aw_mmc.c 2018-03-11 08:25:56.993269000 +0100 > @@ -52,6 +52,8 @@ > #include > #include > > +#include "opt_mmccam.h" > + > #define AW_MMC_MEMRES 0 > #define AW_MMC_IRQRES 1 > #define AW_MMC_RESSZ 2 > @@ -1062,4 +1064,6 @@ > > DRIVER_MODULE(aw_mmc, simplebus, aw_mmc_driver, aw_mmc_devclass, NULL, > NULL); > +#ifndef MMCCAM > MMC_DECLARE_BRIDGE(aw_mmc); > +#endif > > This makes kernel with aw_mmc device, but it does not work either, in > console output was just > > aw_mmc0: mem 0x1c0f000-0x1c0ffff irq 5 on simplebus0 > aw_mmc0: vmmc-supply regulator found > aw_mmc0: attaching MMC child failed! > device_attach: aw_mmc0 attach returned 6 > aw_mmc0: mem 0x1c10000-0x1c10fff irq 6 on simplebus0 > aw_mmc0: cannot reset the controller > device_attach: aw_mmc0 attach returned 6 > > (there are two devices in dtb, first one is for SD card with root > filesystem, second one is for wifi/bluetooth device). This makes > actually sense - there is no device mmc in MMCCAM kernel config files, > however, I am no step nearer now to usable SDIO on Allwinner SoC. > > With some more look over sources I realised aw_mmc is not the same as > drivers for devices with working MMCCAM according wiki mentioned above > - in aw_mmc method table, we have just device, bus and MMC bridge > interface, whereas others have SDHCI interface in addition. And naming > suggests it too - aw_mmc vs. ti_sdhci and bcm2835_sdhci... > > All this together, it looks like aw_mmc needs some rework in order to > be able to move to MMCCAM framework. Did anybody something more already > which could be shared? I've started to look at what is needed to convert an mmc driver to the MMCCAM stack, nothing to be shared for now. > regards, > Milan -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Mar 12 00:45:01 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 735C2F35AC0 for ; Mon, 12 Mar 2018 00:45:01 +0000 (UTC) (envelope-from shamim.shahriar@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 C927B873CC for ; Mon, 12 Mar 2018 00:45:00 +0000 (UTC) (envelope-from shamim.shahriar@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id x7so12983939wmc.0 for ; Sun, 11 Mar 2018 17:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=z6MagZ0mszxGWDgHmJtKdJnce+laiUtF8e6qtCDcRKw=; b=OykkXDuQooin6YkwYwVnlCOPnFke3lbxhKq6fgmCEQflX9JixOOXzyYYDs1Is3MBMR bUnjK4/ZzPxekIhCOYxwlAlf17rdddOITwbwC5Qe7LohRExi3KZOD0e/TLhVUldZcw9U LXAx+qtYSEfPUWjd9DS0I5XXKxy7NJECmse57lfJPa+Xz9chasOpMGF1GAqVrpQsUwNj 1LYFe8IS7VKmFsu6hXl+ocWzQqwlPbonA8CqZhzZY1vz3k9dHxKdl8wCwZQhu1xMhwrQ 2rx6rpNw4wsVKWEBjO5FsTpjWpcu+Uanb3M8UUu/NeUcEK/AxVUoXwcDvS/VmO9t+y+S mkzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=z6MagZ0mszxGWDgHmJtKdJnce+laiUtF8e6qtCDcRKw=; b=Spfsp2wKUNwqou2u/F9nCoAcxc8fqpA0b72aufF/maNP/R0lEC07UFrKdCc8cJHn2p ST6ip4s+zIwZcMatPGpQ/MnFlGMLsgn/1M8AjbkWnCm9rLH8f304igFSA7raqeKlANdL 601QuI/dXwY6pgHJvn4xW3Ye9Ov92sw/0vegB/LEwnLZnlXryHIQcWJpvJiyTf/J0jAO mGexuZSN+CYDUAX4OFq9s1Q3TtK2shotwSqki3hPpiAYu80Bbl6pDSHnqsOi2wwD34DQ Uhdl8j21dGntIG1F4UmzR43Tx10LTmb8Ed0OGOll1VMeHSjKAH9z9PG5eWXISl+F6nER LWog== X-Gm-Message-State: AElRT7Hi+5y7gC3pG7M7r1Lj9PQ27TPoA0lxrmellKG4xs8KL7c1/UGN y55MP1AA0ZZuPBER3i8cr4eL X-Google-Smtp-Source: AG47ELuKF2cD67jf4AWuBO8Bi9Masqlom34OOKaqm6Kc7RzWGt82Rd5x/MoP9+gxNadHybglxcaaag== X-Received: by 10.28.230.68 with SMTP id d65mr4446484wmh.13.1520815499366; Sun, 11 Mar 2018 17:44:59 -0700 (PDT) Received: from osk.homenet ([90.204.30.212]) by smtp.googlemail.com with ESMTPSA id k11sm3148420wrk.41.2018.03.11.17.44.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Mar 2018 17:44:58 -0700 (PDT) To: freebsd-arm@freebsd.org From: Shamim Shahriar Subject: PPS or /dev/ppsN on Raspberry Pi 3 Message-ID: <819975e8-56a8-677b-e5f5-003ff2091553@gmail.com> Date: Mon, 12 Mar 2018 00:44:57 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 00:45:01 -0000 Good evening everyone. Objective: get a GPS module work with Raspberry Pi 3 and FreeBSD v12-CURRENT (it has been indicated on several sites that the earlier versions of FreeBSD do not play well with Pi3), and get a /dev/pps0 so I can get the PPS from gpio 18 and time from a usb serial converter. I have the hardware and they are all plugged in exactly as they should. if I replace the pi with a Pi-B then it all works exactly as they should, but with Pi3 it is proving to be more challenging. I had been trying various things in the Kernel to get the /dev/pps0 (and also /dev/pps1, which I am enabling in case I get to use another module) which has not created even once so far. IAll the documentation I have come across refers to rPi up to model 2, and nothing on 3. As far as I can gather, I need to put options PPS_SYNC in the kernel configuration, which I did. There are also instructions on adding pps lines to the various dtb files that goes into the /boot/msdos folder -- but Rasperry Pi3 /does not/ have the /boot/msdos, it has efi, and my understanding is that the content of the efi is actually pulled from the github (no source available, only the final binaries to put in there). I tried to put those on rpi2.dts, didn't work. here are the relevant lines from the file. Please note, I want to PPS, one on gpio18 the other on gpio 23/ rpi_ft5406 { compatible = "rpi,rpi-ft5406"; status = "okay"; }; pps@0 { compatible = "pps-gpio"; gpios = <&gpio 18 0>; status = "okay"; }; pps@1 { compatible = "pps-gpio"; gpios = <&gpio 23 0>; status = "okay"; }; leds { compatible = "gpio-leds"; my understanding is, whatever dtb file is being used on RPi3, these are downloaded from github (https://github.com/raspberrypi/firmware/tree/master/boot) and there is no way of modifying them as they are all binary files. Would appreciate if someone could please confirm that for me. Would appreciate if someone could please point me to the correct direction as I seem to be going around very blindly and not seeing the possible solution to the problem. Best regards From owner-freebsd-arm@freebsd.org Mon Mar 12 01:12:13 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9BA18F37A07 for ; Mon, 12 Mar 2018 01:12:13 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 3B82F88098 for ; Mon, 12 Mar 2018 01:12:13 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1 (FreeBSD)) (envelope-from ) id 1evC0S-000Fs9-07; Sun, 11 Mar 2018 18:12:04 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id w2C1C3WW061016; Sun, 11 Mar 2018 18:12:03 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Sun, 11 Mar 2018 18:12:02 -0700 From: Oleksandr Tymoshenko To: Shamim Shahriar Cc: freebsd-arm@freebsd.org Subject: Re: PPS or /dev/ppsN on Raspberry Pi 3 Message-ID: <20180312011202.GA60784@bluezbox.com> References: <819975e8-56a8-677b-e5f5-003ff2091553@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <819975e8-56a8-677b-e5f5-003ff2091553@gmail.com> X-Operating-System: FreeBSD/11.1-RELEASE-p4 (amd64) User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Shamim Shahriar (shamim.shahriar@gmail.com) wrote: > Good evening everyone. > > Objective: get a GPS module work with Raspberry Pi 3 and FreeBSD > v12-CURRENT (it has been indicated on several sites t [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 01:12:13 -0000 Shamim Shahriar (shamim.shahriar@gmail.com) wrote: > Good evening everyone. > > Objective: get a GPS module work with Raspberry Pi 3 and FreeBSD > v12-CURRENT (it has been indicated on several sites that the earlier > versions of FreeBSD do not play well with Pi3), and get a /dev/pps0 so I > can get the PPS from gpio 18 and time from a usb serial converter. > > I have the hardware and they are all plugged in exactly as they should. > if I replace the pi with a Pi-B then it all works exactly as they > should, but with Pi3 it is proving to be more challenging. I had been > trying various things in the Kernel to get the /dev/pps0 (and also > /dev/pps1, which I am enabling in case I get to use another module) > which has not created even once so far. > > IAll the documentation I have come across refers to rPi up to model 2, > and nothing on 3. As far as I can gather, I need to put > options PPS_SYNC > > in the kernel configuration, which I did. There are also instructions on > adding pps lines to the various dtb files that goes into the /boot/msdos > folder -- but Rasperry Pi3 /does not/ have the /boot/msdos, it has efi, > and my understanding is that the content of the efi is actually pulled > from the github (no source available, only the final binaries to put in > there). I tried to put those on rpi2.dts, didn't work. > > here are the relevant lines from the file. Please note, I want to PPS, > one on gpio18 the other on gpio 23/ > > rpi_ft5406 { > compatible = "rpi,rpi-ft5406"; > status = "okay"; > }; > > > pps@0 { > compatible = "pps-gpio"; > gpios = <&gpio 18 0>; > status = "okay"; > }; > > pps@1 { > compatible = "pps-gpio"; > gpios = <&gpio 23 0>; > status = "okay"; > }; > > > leds { > compatible = "gpio-leds"; > > > my understanding is, whatever dtb file is being used on RPi3, these are > downloaded from github > (https://github.com/raspberrypi/firmware/tree/master/boot) and there is > no way of modifying them as they are all binary files. Would appreciate > if someone could please confirm that for me. > > Would appreciate if someone could please point me to the correct > direction as I seem to be going around very blindly and not seeing the > possible solution to the problem. You can use FDT overlays for this: - Use https://people.freebsd.org/~gonzo/pps-overlay-example.dts as a starting point. - Compile overlay: dtc -@ -o pps.dtbo pps-overlay-example.dts - Copy pps.dtbo to overlays/ directory on FAT partition - Add "dtoverlay=pps" to config.txt on FAT partition. - Reboot Pi3 and check if pps nodes are in active DTB: sysctl -b hw.fdt.dtb | dtc -I dtb -O dts | grep pps The problem with this approach is that it depends on default pinmux configuration. The right way is to use this example as a base: https://github.com/raspberrypi/linux/blob/rpi-4.9.y/arch/arm/boot/dts/overlays/pps-gpio-overlay.dts This is self-contained overlay that also includes pinmux configuration but requires pinctrl driver. Driver is implemented but not committed to HEAD yet because it depends on couple of changes that are still pending reviews. -- gonzo From owner-freebsd-arm@freebsd.org Mon Mar 12 02:42:30 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C9FDF4116A for ; Mon, 12 Mar 2018 02:42:30 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh504-vm13.bullet.mail.kks.yahoo.co.jp (nh504-vm13.bullet.mail.kks.yahoo.co.jp [183.79.57.99]) by mx1.freebsd.org (Postfix) with SMTP id 48CA58ADE7 for ; Mon, 12 Mar 2018 02:42:28 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.138] by nh504.bullet.mail.kks.yahoo.co.jp with NNFMP; 12 Mar 2018 02:40:24 -0000 Received: from [183.79.100.133] by t501.bullet.mail.kks.yahoo.co.jp with NNFMP; 12 Mar 2018 02:40:24 -0000 Received: from [127.0.0.1] by omp502.mail.kks.yahoo.co.jp with NNFMP; 12 Mar 2018 02:40:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 663036.22619.bm@omp502.mail.kks.yahoo.co.jp Received: (qmail 60822 invoked by uid 60001); 12 Mar 2018 02:40:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1520822424; bh=FiKohIRbi4Uh96v1883CuvHxJN9lFjlA3u84FS1sw2A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZxlkhXfLPwMStf/VopNBR8AhpXFB5+DlsArWkBxmU3XVMXA8CWI0mup5i7kUfVsw4an7c5RCUt7XzVXLKvp574gHVETsXVK26S5WMvjQjY2SDat3/cOu8UMyu/b5rWMx7Rae3MxpqoEY93HJKxZ9YZMKB3+fS0RI9uwcUwqTcLc= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MJNDMUHpF2qmoklPeBqG+xaMgbggLxPQ32f+uYoSY16Qp3qyBVLR0zQidymwZfJUrtsVu9b8k5533L4tyqz228qw+oL727OCNbdU1UUT/jdVyVbAdmet5NRDBSWU/hYvRbUt+eL9AjRXU74xxWKWaGeGdDHAZbMFloeYGP6BDSc=; Message-ID: <340750.57914.qm@web101714.mail.ssk.yahoo.co.jp> X-YMail-OSG: GVlmZiMVM1mWkrcCf4KzB8PpygjT8FjKsMxRFgHtFlaGiNpuGuDRl3VlQntA3JXFqdPg4ZfyPbUOjHyAeBy4hXxE9YO2UTWLqwPQs_GLe0syRGjRqY2nXK6BHPoB8D7kefg8skvCDAHkC92QWcqpURRy3v8yZF2yJ2n1WEQOZ9jf7l7DZUuFbdHsCQKdXHD25oVqP6gC4lhuXUodrNcJ8Ikuz2b17IYJj90tsd7HXZnoDh1t8Q0_HUWAkQkTxFrUJ7F54qqC8dEjf0ZHJe2J3Osc8roc76ToFqIdyuTmB0LA1bLnWVShaYM4oyQ0aYtsc7D5PQsO.CF440xWxr18qDd4jCTBEZsPQkODBoqIKOtx1bBlGY6zFpc8qI_azmDMuC0eUpWxydvpPcion8rDznVA7_Rc.fPcPOqziLTIgY_.OD89duYaytaolBi3cqTmzXIgIlV0ZtdLZLOXtNkn9LaOBR_oekpiX_vzq46Xk5cxV5BSINQ6K5.LRuWRyN_Y331HKC78fsJkJJ_Jfb.1z8x.MKGdMOj1fo9qyQncB8C6VkMd0sQZYP7kiTycqZwJwsaPeexeWlU2emezEo9Odm2YIWn75o1llZX_ZqjosMdajWt2V0YuxmaMDb6q_BA- Received: from [203.165.91.75] by web101714.mail.ssk.yahoo.co.jp via HTTP; Mon, 12 Mar 2018 11:40:22 JST X-Mailer: YahooMailWebService/0.8.111_74 X-YMail-JAS: .ZgJLKIVM1kXi7V_JBRiyI0SUQkzoVt5vxm23G5h.qYq5I2Eku.24NLvAwvUDVKk_TQ6h70dCIJGYi09s7AlcmLlalIXnMJEQe16AGQoNG6CYm3W6Ypx2mKcfdVv6xTg1ahp References: <815937.99592.qm@web101711.mail.ssk.yahoo.co.jp> Date: Mon, 12 Mar 2018 11:40:22 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Re: Dose clang support armv4 To: "freebsd-arm@freebsd.org" In-Reply-To: <815937.99592.qm@web101711.mail.ssk.yahoo.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 02:42:30 -0000 Hi.=0A=0AI try current. clang v6 is correct object to armv4 for cns11xx.=0A= =0Ahttps://gist.github.com/yamori813/ae047a28a825aac255e436fd8ccaf785=0A=0A= =0ABut still hang at up boot.=0A=0AThanks=0A=0AHiroki Mori=0A=0A=0A----- Or= iginal Message -----=0A> From: Mori Hiroki =0A> To: = "freebsd-arm@freebsd.org" =0A> Cc: =0A> Date: 2018= /2/4, Sun 23:33=0A> Subject: Dose clang support armv4=0A> =0A> Hi.=0A> =0A>= I try cns11xx to FDT away. But last clang not support armv4(not armv4t).= =0A> Dose clang will support armv4?=0A> =0A> Regards=0A> =0A> Hiroki Mori= =0A> _______________________________________________=0A> freebsd-arm@freebs= d.org mailing list=0A> https://lists.freebsd.org/mailman/listinfo/freebsd-a= rm=0A> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.or= g"=0A> From owner-freebsd-arm@freebsd.org Mon Mar 12 07:16:49 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A1FBF4F926 for ; Mon, 12 Mar 2018 07:16:49 +0000 (UTC) (envelope-from shamim.shahriar@gmail.com) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 AAF6F6BDDF for ; Mon, 12 Mar 2018 07:16:48 +0000 (UTC) (envelope-from shamim.shahriar@gmail.com) Received: by mail-wr0-x233.google.com with SMTP id h2so7234195wre.12 for ; Mon, 12 Mar 2018 00:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dv7TMcgbACseJivqsK1PmAd8+vbhMss7+AAaGKxNvOI=; b=iUK/Qi8yz8CuYOc0QD4RJ8sTKGDgUjfp2okNmJ/fEE4xqHBvIkYnlq2lSEJYOLWJja gC+sPzOQ8jqcKtG4qQIF5MSTb8URdi30j6wUjSBaSL+ddP1O4RnoLK5DtH3caV8U1xXp QmvJLN1TGj5IFUrBnkIob2i9xFG/Nopo4ysdGy2aKQFdsiRLZqztFTrgOVdmHBv4kSNG 8JKCsV2vjnWDYVD9zvydigdkNycB73obcb9UjqrROvK7UuseszFfX9SZMjfDAiAjdDsr ugWgrvcpEVTI8YynysZm5DPv0gkt06HmgK9vMZzHfiuK6cnV577PeFg3DrZ8+7hc/Yfo ALSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dv7TMcgbACseJivqsK1PmAd8+vbhMss7+AAaGKxNvOI=; b=krs4qTEa+AreMfJ46iCPAU5i1lJ7A2/o5DMtGpl3O4I6pC9r/C2ByUgsmG69dXdBbB 7b/ODnynpfERDF5WhnRDHvrDvttaiQK7I3txZxhUL7HVgI4w8XTjvndQay3dWZVziODS K5/7tCk4rQPtgGKvi7g6MOmD0sc1AHVC3t+Fvos71DhHJg5hoRkr5qROB9pwzFZhPUwi Cpy0VppacfLM6ZqFfg9jYtu7uHTBrD3OUfzKqJeJW/yKEZ0RR/Z0oLwVhDVBf2akFWSc 4NL8CBnNxKi+OtJkmMTReEKMZ3NZfUdLOPLQcN0y5oVMyPu7yOWqW4dnSJEswCkVWQIu wV6A== X-Gm-Message-State: AElRT7GAaHNykTqd4OglNkrcsjJ2eVBRr2BdfFdr5oN9Lifu/ctM9IL3 05kRaOJaT8+9SFrP5AF/Sgo6 X-Google-Smtp-Source: AG47ELugTC4jRRdzmXGMWUcvg/af7X4TtloOcVnRB40ymP69yalzbqbxLMfsS/EJQXLkYQFxApE0jw== X-Received: by 10.223.145.67 with SMTP id j61mr5623336wrj.152.1520839007303; Mon, 12 Mar 2018 00:16:47 -0700 (PDT) Received: from osk.homenet ([90.204.30.212]) by smtp.googlemail.com with ESMTPSA id z18sm5850415wrh.2.2018.03.12.00.16.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 00:16:46 -0700 (PDT) Subject: Re: PPS or /dev/ppsN on Raspberry Pi 3 To: Oleksandr Tymoshenko References: <819975e8-56a8-677b-e5f5-003ff2091553@gmail.com> <20180312011202.GA60784@bluezbox.com> Cc: freebsd-arm@freebsd.org From: Shamim Shahriar Message-ID: Date: Mon, 12 Mar 2018 07:16:45 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20180312011202.GA60784@bluezbox.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 07:16:49 -0000 On 12/03/2018 01:12, Oleksandr Tymoshenko wrote: > Shamim Shahriar (shamim.shahriar@gmail.com) wrote: > You can use FDT overlays for this: > > - Use https://people.freebsd.org/~gonzo/pps-overlay-example.dts as > a starting point. > - Compile overlay: dtc -@ -o pps.dtbo pps-overlay-example.dts > - Copy pps.dtbo to overlays/ directory on FAT partition > - Add "dtoverlay=pps" to config.txt on FAT partition. > - Reboot Pi3 and check if pps nodes are in active DTB: > sysctl -b hw.fdt.dtb | dtc -I dtb -O dts | grep pps > > The problem with this approach is that it depends on > default pinmux configuration. The right way is to use > this example as a base: > https://github.com/raspberrypi/linux/blob/rpi-4.9.y/arch/arm/boot/dts/overlays/pps-gpio-overlay.dts > > This is self-contained overlay that also includes > pinmux configuration but requires pinctrl driver. > Driver is implemented but not committed to HEAD yet > because it depends on couple of changes that > are still pending reviews. > Thank you Gonzo, that looks like a good starting point. I will try them out later and see what I can get out or it. Regards From owner-freebsd-arm@freebsd.org Mon Mar 12 07:38:59 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EC71F511CA for ; Mon, 12 Mar 2018 07:38:59 +0000 (UTC) (envelope-from shamim.shahriar@gmail.com) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 7F61C6CD49 for ; Mon, 12 Mar 2018 07:38:58 +0000 (UTC) (envelope-from shamim.shahriar@gmail.com) Received: by mail-wr0-x22b.google.com with SMTP id d10so2118375wrf.3 for ; Mon, 12 Mar 2018 00:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=P2uZSw0l5kkT7T3UGNk1xAE4mF4Wdj6WUkgxeDMwQWQ=; b=qf9MIB6XVMiPKafJBoxTmDh0z7KxsLgV5uQPrjFEJ9Tyy3Tns1igdoHMDtEbon4YPf LDg99LrqKDnJo/KA2Y5h5kYo2YYyTXekx0A4M+PyuBghAsSclrHpxdtLBw8YAVO4oSvF 6Uj71f4KgPdPMvMlP+rS5oPB8h8eCXK7Z4o3YfbbjO29o2VqulHQvea8jasxhXN2QjBw GxkR5jZxKILW3Y4mhbpRl4pB/EDfA4J7Ab9kV/BgSQE4k8gUfZk7VjTg3nCdaILVsvyM AxyhBM29zs9SZ1c2Zqy1pBYoVluEZi/rB70ImPZbvPUGOC//VGHUFJgQL/8p4yXbgS1e gu3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=P2uZSw0l5kkT7T3UGNk1xAE4mF4Wdj6WUkgxeDMwQWQ=; b=nm559P5LDpBzVGv2uHwmeO93HmMQ+Azyca7SxclaSt6gezQZm1Rl/ADWv7d6JqASPb uQ2lSLgevb/gr+t/iOYc6i0K4oTqDDlx/uOb7Xl6Ilyhoql1Z6rB3PXCybrGDoLVxSgm iFvVJMSqoY9wMK/ZiuVpcOJocCusgXG85qzKvpQNvN2LAWQGurq//8rbGo8DcZk7qXLe l6ghjjjbaz7IsVQHajki9DMfqpknyeYKiY8/iQU2KlXtuf9Kb/6nGbMI0NxE5uKst+Uw d510nvVZoFfXnMMIbVHAKfyFkMnRZKNQM0Op1rlOh4jKHD20hsUALvd8kLJGJZkEW+B1 fqAg== X-Gm-Message-State: AElRT7F1XPZT+yxvc9T3WvWvyJkjium53LgHq6ksN16hO/zCvKlBV39a mWq0fBXn/ZvNrYu7AkJVBqDh X-Google-Smtp-Source: AG47ELvOs+hVJcJYf/07UcRlWiwrMWiLbh4cUmgbccHyZ76SevIB0MT3gNlyUu1VZXbO42oR0GdSiA== X-Received: by 10.223.171.88 with SMTP id r24mr5346321wrc.194.1520840336911; Mon, 12 Mar 2018 00:38:56 -0700 (PDT) Received: from osk.homenet ([90.204.30.212]) by smtp.googlemail.com with ESMTPSA id t91sm13932642wrc.21.2018.03.12.00.38.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 00:38:55 -0700 (PDT) Subject: Re: PPS or /dev/ppsN on Raspberry Pi 3 To: Oleksandr Tymoshenko References: <819975e8-56a8-677b-e5f5-003ff2091553@gmail.com> <20180312011202.GA60784@bluezbox.com> Cc: freebsd-arm@freebsd.org From: Shamim Shahriar Message-ID: <9d27f6ff-d317-aa24-4f22-b06624fd6d1d@gmail.com> Date: Mon, 12 Mar 2018 07:38:55 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20180312011202.GA60784@bluezbox.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 07:38:59 -0000 On 12/03/2018 01:12, Oleksandr Tymoshenko wrote: > sysctl -b hw.fdt.dtb | dtc -I dtb -O dts | grep pps Hello Gonzo I made a little change (pps numbers) on your example and put that in place. After reboot, if I run the command above, I can see the two pps devices # sysctl -b hw.fdt.dtb | dtc -I dtb -O dts | grep pps pps@1 { compatible = "pps-gpio"; pps@0 { compatible = "pps-gpio"; However, there is no /dev/pps yet on the system. Is there something I need to do in addition to get the pps drivers in place? Regards From owner-freebsd-arm@freebsd.org Mon Mar 12 11:38:46 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 101C3F3ACDD; Mon, 12 Mar 2018 11:38:46 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9389576CD9; Mon, 12 Mar 2018 11:38:45 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id w2CBCp2B039990 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Mar 2018 12:12:51 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id w2CBCmXm002974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Mar 2018 12:12:48 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTPS id w2CBClOT014445 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Mar 2018 12:12:47 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id w2CBClGa014444; Mon, 12 Mar 2018 12:12:47 +0100 (CET) (envelope-from ticso) Date: Mon, 12 Mar 2018 12:12:47 +0100 From: Bernd Walter To: Hans Petter Selasky Cc: Bernd Walter , freebsd-arm@freebsd.org, freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: webcamd based touchscreen problem on Pi3 Message-ID: <20180312111246.GA14138@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20180308191131.GB86413@cicely7.cicely.de> <20180308200849.GC86413@cicely7.cicely.de> <20180308210805.GE86413@cicely7.cicely.de> <20180309004433.GI86413@cicely7.cicely.de> <4765ef04-6fb1-f9dc-315d-c4419d6ba016@selasky.org> <20180309114025.GJ86413@cicely7.cicely.de> <20180309132539.GL86413@cicely7.cicely.de> <20180310000336.GM86413@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180310000336.GM86413@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 11.0-STABLE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 11:38:46 -0000 On Sat, Mar 10, 2018 at 01:03:39AM +0100, Bernd Walter wrote: > On Fri, Mar 09, 2018 at 02:25:39PM +0100, Bernd Walter wrote: > > On Fri, Mar 09, 2018 at 01:19:54PM +0100, Hans Petter Selasky wrote: > > > On 03/09/18 12:40, Bernd Walter wrote: > > > >Will do the quirk test later. > > > > > > I don't see any stalls during plug-in, so it might be a request webcamd > > > issues, which the device doesn't support. Try building webcamd with > > > debug support. > > > > It is already build with debug. > > But I don't see anything of special interest in the output. > > > > [24]sa# webcamd -d ugen0.4 > > Linux video capture interface: v2.00 > > IR NEC protocol handler initialized > > IR RC5(x/sz) protocol handler initialized > > IR RC6 protocol handler initialized > > IR JVC protocol handler initialized > > IR Sony protocol handler initialized > > IR SANYO protocol handler initialized > > IR LIRC bridge handler initialized > > IR XMP protocol handler initialized > > b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully > > USB Video Class driver (1.1.1) > > cpia2: V4L-Driver for Vision CPiA2 based cameras v3.0.1 > > pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner > > pvrusb2: Debug mask is 31 (0x1f) > > USBVision USB Video Device Driver for Linux : 0.9.11 > > Attached to ugen0.4[0] > > INFO: 0003:0EEF:0005.0001: input: USB HID v1.10 Mouse [BYZHYYZHY By ZH851] on usb-/dev/usb-/dev/usb/input0 > > > > DBG: 0003:0EEF:0005.0001: Kicking head 1 tail 0 > > Creating /dev/input/event0 > > > > I will redo a test with raspbian. > > Waveshare delivered a binary kernel (so much about GPL) for their 7" HDMI C > > until they changed something in the device firmware and upgraded for a newer > > panel about 2-3 years ago. > > This is the 10.1" HMDI B and it is a very early version I have, which however > > should use a firmware similar to the newer 7" HDMI C. > > I will retest with a stock Raspbian image to be sure I wasn't accidently > > using a Waveshare image back then. > > As far as I can see the Linux drivers just quirk the device to the egalaxy > > driver, so they do know the Waveshare by ID. > > I couldn't spot a difference between Linux and what is included in the webcamd > > source. > > So the older 7" HDMI C Rev 1.1 with the non IPS panel won't even attach, but > it always needed some special binary support for Linux, no surprises here. > The newer Rev 2.1 with the IPS panel claims to be the same and work with > webcamd, at least I get data via /dev/input/event0, which looks reasonable > with evdev-dump. > That's an interesting starting point. I've got a new model of the 10" HDMI B. It behaves differently. First of all - uep seems to take it, which it didn't for any of the previous displays I'd tested. I had to remove the driver from the loader.conf to have webcamd attach to it. webcamd attaches fine and it delivers touch events: [29]sa# evdev-dump /dev/input/event0 /dev/input/event0 3041705595.425438 EV_ABS ABS_MT_TRACKING_ID 0x00000000 /dev/input/event0 3041705595.425438 EV_ABS ABS_MT_POSITION_X 0x000001CF /dev/input/event0 3041705595.425438 EV_ABS ABS_MT_POSITION_Y 0x0000025E /dev/input/event0 3041705595.425438 EV_ABS ABS_MT_PRESSURE 0x00000005 /dev/input/event0 3041705595.425438 EV_KEY BTN_TOUCH 0x00000001 /dev/input/event0 3041705595.425438 EV_ABS ABS_X 0x000001CF /dev/input/event0 3041705595.425438 EV_ABS ABS_Y 0x0000025E /dev/input/event0 3041705595.425438 EV_ABS ABS_PRESSURE 0x00000005 /dev/input/event0 3041705595.425438 EV_SYN SYN_REPORT 0x00000000 Whatever had been the cause for my previous problem, they obviously have fixed them in firmware. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Mon Mar 12 14:45:39 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26039F4BE39 for ; Mon, 12 Mar 2018 14:45:39 +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 A20E17EE53 for ; Mon, 12 Mar 2018 14:45:38 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: e7321e10-2603-11e8-b951-f99fef315fd9 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id e7321e10-2603-11e8-b951-f99fef315fd9; Mon, 12 Mar 2018 14:44:44 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w2CEjZhX016357; Mon, 12 Mar 2018 08:45:35 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1520865935.84937.169.camel@freebsd.org> Subject: Re: PPS or /dev/ppsN on Raspberry Pi 3 From: Ian Lepore To: Shamim Shahriar , Oleksandr Tymoshenko Cc: freebsd-arm@freebsd.org Date: Mon, 12 Mar 2018 08:45:35 -0600 In-Reply-To: <9d27f6ff-d317-aa24-4f22-b06624fd6d1d@gmail.com> References: <819975e8-56a8-677b-e5f5-003ff2091553@gmail.com> <20180312011202.GA60784@bluezbox.com> <9d27f6ff-d317-aa24-4f22-b06624fd6d1d@gmail.com> 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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 14:45:39 -0000 On Mon, 2018-03-12 at 07:38 +0000, Shamim Shahriar wrote: > On 12/03/2018 01:12, Oleksandr Tymoshenko wrote: > > > > sysctl -b hw.fdt.dtb | dtc -I dtb -O dts | grep pps > Hello Gonzo > > I made a little change (pps numbers) on your example and put that in  > place. After reboot, if I run the command above, I can see the two > pps  > devices > # sysctl -b hw.fdt.dtb | dtc -I dtb -O dts | grep pps >          pps@1 { >                  compatible = "pps-gpio"; >          pps@0 { >                  compatible = "pps-gpio"; > > However, there is no /dev/pps yet on the system. Is there something > I  > need to do in addition to get the pps drivers in place? > > Regards The pps-gpio driver creates devices named /dev/gpioppsN.  You need to create links to the /dev/ppsN numbers you want them assigned to (using devfs.conf entries).  The reason for this is that there may be many different pps-generating devices on the system and the admin needs to decide which ones link up to the pps devices specified in server configuration lines in ntp.conf. For example, on my beaglebone that I use for pps testing, my devfs.conf has these entries: link cuaU0 pps0 link cuau1 pps1 link dmtpps pps2 link gpiopps0 pps3 and my ntp.conf on that board has: server 127.127.22.0              minpoll 4 maxpoll 4 fudge  127.127.22.0 stratum 0 refid ucom server 127.127.22.1              minpoll 4 maxpoll 4 fudge  127.127.22.1 stratum 0 refid uart server 127.127.22.2              minpoll 4 maxpoll 4 fudge 127.127.22.2 stratum 0 refid timr server 127.127.22.3              minpoll 4 maxpoll 4 fudge 127.127.22.3 stratum 0 refid gpio -- Ian From owner-freebsd-arm@freebsd.org Mon Mar 12 14:51:55 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76E3AF4C49D for ; Mon, 12 Mar 2018 14:51:55 +0000 (UTC) (envelope-from ralph@ralphsmith.org) Received: from ralphsmith.org (ralphsmith.org [98.172.20.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ralphsmith.org", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 224A07F203 for ; Mon, 12 Mar 2018 14:51:54 +0000 (UTC) (envelope-from ralph@ralphsmith.org) Received: from [172.31.125.142] ([198.99.129.143]) (authenticated bits=0) by ralphsmith.org (8.15.2/8.15.2) with ESMTPSA id w2CEmdhF020464 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Mar 2018 10:48:40 -0400 (EDT) (envelope-from ralph@ralphsmith.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ralphsmith.org; s=201502; t=1520866120; bh=JmnYZY9PaO0JnqOKLGP1MCioJiPriIFCRZ7IZULlZSQ=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=Le1I2KoKxwCFro1aGWlRWLFqZ6RoXkvnLTQnUCDK/DeagyKvdRHe+7oVqOVuh6onj Pu1RXcaS/MSECWj28Ycm7dyq+nODnw+6xeOJZxTpwkKxZY3tqXm4A7yzrM9980CgHa 8h0BabdiV14RR3aGj2gDi8BjblngQjvStOLgswx0= References: <819975e8-56a8-677b-e5f5-003ff2091553@gmail.com> <20180312011202.GA60784@bluezbox.com> <9d27f6ff-d317-aa24-4f22-b06624fd6d1d@gmail.com> In-Reply-To: <9d27f6ff-d317-aa24-4f22-b06624fd6d1d@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5F567062-88EF-4707-B8A7-2B5841C23E38@ralphsmith.org> Cc: freebsd-arm@freebsd.org X-Mailer: iPad Mail (14G60) From: Ralph Smith Subject: Re: PPS or /dev/ppsN on Raspberry Pi 3 Date: Mon, 12 Mar 2018 10:48:33 -0400 To: Shamim Shahriar X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 14:51:55 -0000 Look for /dev/gpiopps* You may also need to load gpiopps.ko Ralph > On Mar 12, 2018, at 3:38 AM, Shamim Shahriar w= rote: >=20 >> On 12/03/2018 01:12, Oleksandr Tymoshenko wrote: >> sysctl -b hw.fdt.dtb | dtc -I dtb -O dts | grep pps > Hello Gonzo >=20 > I made a little change (pps numbers) on your example and put that in place= . After reboot, if I run the command above, I can see the two pps devices > # sysctl -b hw.fdt.dtb | dtc -I dtb -O dts | grep pps > pps@1 { > compatible =3D "pps-gpio"; > pps@0 { > compatible =3D "pps-gpio"; >=20 > However, there is no /dev/pps yet on the system. Is there something I need= to do in addition to get the pps drivers in place? >=20 > Regards > _______________________________________________ > 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 Mon Mar 12 16:43:23 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1155F2A456 for ; Mon, 12 Mar 2018 16:43:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 510C184D9E for ; Mon, 12 Mar 2018 16:43:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id k79-v6so12327554ita.2 for ; Mon, 12 Mar 2018 09:43:22 -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=zMqz4SUUrvaBPHXpm9+Bdypz+D1p8pGdYb4RI87RJq8=; b=U4IkLz5gYElb5gUZHmRYXfW5ZdZ5nwmDgD4N5nOUzLqTOoc5Wy1pB82Et8ypM3t11M Bwjr8pWFlVy2dM/31EvAyAcWIKjs16u8Whiwf4hNGnTPLtSK/8iCSev80THCiGaA5HUy tXM7a8tnPyQ8JdiaFO5QW+uriuD7OcBnPHxt1e9u49k+e/HcloiZzBTS83BnwtZmD4sv +815z/z7hUqVGl4zXW3OJyVYd22RNj/NwqS+B/kjlwowffMT8imReYqOg3CEwpNoAFb2 tG+Cc1wUFgBAg6bA9f2UpRQrAUmz71N8JsF2OJxF8rKjUaluppf8He3Mao24ALRXQy3A eR/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:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zMqz4SUUrvaBPHXpm9+Bdypz+D1p8pGdYb4RI87RJq8=; b=tQoh/0R5SIvAhSLBhBI42wzzjw3uw6TkJn8GdiRwtdg/afN0FLMd2O8G0XmGZFylQY 47g7Mr/G4sTniKQ0e8wBdGf+iirrqY9TDMuDKhJFzzZLMknBYo4bq5JkbbhBe6ZLAacy Cyzi9trl2Fm2Ka5gmkOI0i6kveBCDHEhPxtd9qU3/cKPl37fTT8O5zac0KcF9IIErY4n L7TX2ZLQqglXytJZ1QiBsalG7R3w/MNE5CkkMDIXMYzgueyqUdUv4u/tvOqL0HJs/uh1 pZHG1CiuSEcYawYyg3iGt0gPmthSGfiqbEEbPWc2rdJJnMRTeUbcFIInURxYhfbNZWh9 HtFA== X-Gm-Message-State: AElRT7FevVwZjZ+gcTNe3pA084DFKBKB228F/lh4ENepKn6nKtXtH/Aa EWniIdqg0MQYxsbeu6ID3eNcYu0X/8tW2UdCQfOfAQ== X-Google-Smtp-Source: AG47ELtTeeUtbzor9UvFQMx0RWH3SgUBd8E90wgiM9wIICKMmFWgg46S2hoR6M01ZRiSSyYX+7CpKgVJTs140EJJ6co= X-Received: by 10.36.179.8 with SMTP id e8mr241746itf.36.1520873001511; Mon, 12 Mar 2018 09:43:21 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Mon, 12 Mar 2018 09:43:20 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <340750.57914.qm@web101714.mail.ssk.yahoo.co.jp> References: <815937.99592.qm@web101711.mail.ssk.yahoo.co.jp> <340750.57914.qm@web101714.mail.ssk.yahoo.co.jp> From: Warner Losh Date: Mon, 12 Mar 2018 10:43:20 -0600 X-Google-Sender-Auth: lYON26P3pES21skeVuxcugGQ0hQ Message-ID: Subject: Re: Dose clang support armv4 To: Mori Hiroki Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 16:43:23 -0000 Hi Mori-san, I've not tried my armv4 boards with clang 6 yet. However, you are hanging in mountroot. What's normally printed there? Ian just did some things to fix it for USB ad ZFS. Maybe that broke this use case accidentally. Warner On Sun, Mar 11, 2018 at 8:40 PM, Mori Hiroki wrote: > Hi. > > I try current. clang v6 is correct object to armv4 for cns11xx. > > https://gist.github.com/yamori813/ae047a28a825aac255e436fd8ccaf785 > > > But still hang at up boot. > > Thanks > > Hiroki Mori > > > ----- Original Message ----- > > From: Mori Hiroki > > To: "freebsd-arm@freebsd.org" > > Cc: > > Date: 2018/2/4, Sun 23:33 > > Subject: Dose clang support armv4 > > > > Hi. > > > > I try cns11xx to FDT away. But last clang not support armv4(not armv4t). > > Dose clang will support armv4? > > > > Regards > > > > Hiroki Mori > > _______________________________________________ > > 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 Mon Mar 12 17:41:28 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A02CAF2F75E for ; Mon, 12 Mar 2018 17:41:28 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 2FA7A6805C for ; Mon, 12 Mar 2018 17:41:27 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 939578a4-261c-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 939578a4-261c-11e8-91c6-33ffc249f3e8; Mon, 12 Mar 2018 17:41:22 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w2CHfHq2016825; Mon, 12 Mar 2018 11:41:17 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1520876476.84937.226.camel@freebsd.org> Subject: Re: Dose clang support armv4 From: Ian Lepore To: Warner Losh , Mori Hiroki Cc: "freebsd-arm@freebsd.org" Date: Mon, 12 Mar 2018 11:41:16 -0600 In-Reply-To: References: <815937.99592.qm@web101711.mail.ssk.yahoo.co.jp> <340750.57914.qm@web101714.mail.ssk.yahoo.co.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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 17:41:28 -0000 On Mon, 2018-03-12 at 10:43 -0600, Warner Losh wrote: > Hi Mori-san, > > I've not tried my armv4 boards with clang 6 yet. > > However, you are hanging in mountroot. What's normally printed there? > Ian > just did some things to fix it for USB ad ZFS. Maybe that broke this > use > case accidentally. > > Warner > Unfortunately, my only armv4/5 system that's anywhere close to bootable  right now is a Dreamplug, and it also hangs at mountroot, but for a different reason: somehow its ethernet driver gets a continuous "RX error" interrupt storm (and my rootfs is on nfs).  I haven't had time to try putting together a rootfs on sdcard or sata to see if it boots all the way. -- Ian From owner-freebsd-arm@freebsd.org Tue Mar 13 01:05:10 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B5A5A7DCD7 for ; Tue, 13 Mar 2018 01:05:10 +0000 (UTC) (envelope-from shamim.shahriar@gmail.com) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 93A987D753 for ; Tue, 13 Mar 2018 01:05:09 +0000 (UTC) (envelope-from shamim.shahriar@gmail.com) Received: by mail-wr0-x22f.google.com with SMTP id n12so6757852wra.2 for ; Mon, 12 Mar 2018 18:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=j2PkcIZEDLv+tHwC265Ivwy8T3gO6XCApq137XhoKvE=; b=UfISaUa5t8ccc/mWAUDqXeI9TaMVidtxxOP+Yrxm99EbnhkCNkYJVMxr9btomMCBGk wRSBxpL0JKZ3p2ZHz7aN5Wn1zbIb5Q1y4PJPsLPLt7TIyV7BA+ck8jMwsEpvye/T/Gbu T5b6zNluIq8Ic5QsJuY9VzqKfjVfn21IbNtpleP4VOEVEZwaqoabI4oEHcOpw4m9ZfHE FAOJZBGFE9HweUx7iDR141PqOnOWJ8hvpm9l2Pzzt8O1LEenEsppNpAMz9VOVH8OqsBj sAtNxmH7xcjp4c7v/L65u0Bvn2IYo+KxkkGjWIkY9HKORR/AKDXNgHHdfWSNl4FJk6Rx 71UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=j2PkcIZEDLv+tHwC265Ivwy8T3gO6XCApq137XhoKvE=; b=fEuvf6WR6ZVge9KAkcIqexIYeaLz6vv96dLO4rHgijT/f0+bbEao+CNihjzzbvgULC R3DNkAOHyYot4MTBptCGvRkkGPhvWKGukrJ19C+ZEdBokTkiNXQu5zTX5m7kD0iMeoQP HSZcUljouxrf3pINNvLoWdYcGX96SAvtbIAU3eYj08qCakiz0IIhmkK4KcgiSczhQDu2 exOaGb1mhchfsCEiooryHV9uxR/l6fqxbnix5WFFClT8vMx+g50vM9zUUIkT7ZV5Tptc 7kBTwawlL5EfADXY7qoaTtzlIuTgTITqCRRy82Qh6ap0jE+4lqqCs24SikQbZbmFbF3n H3rQ== X-Gm-Message-State: AElRT7EoH1vKDNpirHhrwUX7iiJ+NxCnMrU3fJJf9csf75MSP3G0af81 QQkFu+uJEw0X/55UHLZdeZtg5Ac= X-Google-Smtp-Source: AG47ELttESSey96t20N0ZhzRMeVbzp5QF4lGIlufKFSskgX5TAz/72ho4QWqF+5VI7QwhwIOTDL1tA== X-Received: by 10.223.128.75 with SMTP id 69mr8431107wrk.139.1520903108345; Mon, 12 Mar 2018 18:05:08 -0700 (PDT) Received: from osk.homenet ([2.218.207.147]) by smtp.googlemail.com with ESMTPSA id i127sm8242667wmf.33.2018.03.12.18.05.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 18:05:07 -0700 (PDT) Subject: Re: PPS or /dev/ppsN on Raspberry Pi 3 To: Ralph Smith References: <819975e8-56a8-677b-e5f5-003ff2091553@gmail.com> <20180312011202.GA60784@bluezbox.com> <9d27f6ff-d317-aa24-4f22-b06624fd6d1d@gmail.com> <5F567062-88EF-4707-B8A7-2B5841C23E38@ralphsmith.org> Cc: freebsd-arm@freebsd.org From: Shamim Shahriar Message-ID: <2ef1f6f3-3e8f-529f-33dd-3a75f86891f3@gmail.com> Date: Tue, 13 Mar 2018 01:05:06 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <5F567062-88EF-4707-B8A7-2B5841C23E38@ralphsmith.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 01:05:10 -0000 On 12/03/2018 14:48, Ralph Smith wrote: > Look for /dev/gpiopps* > > You may also need to load gpiopps.ko > > Ralph > thanks to all who responded and helped with the issue. The problem was, even though i had gpiopps_load="YES" in my /boot/loader.conf, and the module was loaded during boot -- it was NOT creating anything in the /dev/ folder. Same was true for a uftdi_load="YES". Even worse, if I built the ftdi module into the kernel, the system would not boot for some reason. So I did what felt quite logical (after reading all the supporting emails you have sent me, thank you so much). I unloaded and re-loaded the kernel modules, and lo! all the devices popped up like magic :D And now I wrote a small script to wait a few seconds after boot, and then unload whatever has been loaded, and then load only the ones I need. Working like a charm! Thanks to everyone, once again, for helping me to make it work. Best regards From owner-freebsd-arm@freebsd.org Tue Mar 13 06:07:33 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D40CBF2977; Tue, 13 Mar 2018 06:07:33 +0000 (UTC) (envelope-from mizhka@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 7D69E6ACD2; Tue, 13 Mar 2018 06:07:32 +0000 (UTC) (envelope-from mizhka@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id w16-v6so5805145lfc.13; Mon, 12 Mar 2018 23:07:32 -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=w0UVSOtbfnDrKrUkz+vFq1oP1QTF7qPj3iNH8YR+YUY=; b=dL4uWWK3TxkyHBKFSRAVJeSKNXUnb7Abh7EWQiFFobnUROXgvpreUUNeVaibDrpTnD 8u1zIbMDrjpX3YOQCSdHykxWBN8l0ohUcWbmDuLWheHB4PyRbZ6yHeKTdPqqoWJayyhz 18Lbpe9aD65qo0oHNtE8ps/Yx75aNm09CJb4qImDtaUmryhrMC/qMvqtHgkaCO/oMLGh SiVbGRhxkBxY7LofCvDyIBQVzsJ7Zc+n0aog1QuRZmae0OZ1IneGwDtsspy3ZPYFj3sz fN+BJyefuoT/RB+xA4LeTjSqBhYYajgf8QKl1R4B92tNRUtzM8h+GOYU2uQugi4G0gcJ 3crQ== 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=w0UVSOtbfnDrKrUkz+vFq1oP1QTF7qPj3iNH8YR+YUY=; b=al8+oxJ+NAAWSpewlTLNflTfeUfoJoLRkvUaemQxhW1eB5z60tKXklwmtNtukguhpC ChrvEmUI/7ntozymFQ7gRuXJfUAKHz1gDt+RKc7ilFcGtHO6feuzf6Akp+8ApTSIz4Gi 9OQDNXnUeUy3oPPCettOZmb7IzZNVd8cu17sllHKHAxMTptt3a+DhhVYxLVoX+001vi3 1HmNU74cyk2n6ObzKNvKxx/ElgYq3Yeh8u97wwOVzubuU9MLUbkXuUGhEl7M45fBRLUV h2Rc5DMGmA7FfIPDRqeDR8wo3pIJalt7T3ZCHy8cgtLgcUg2TE1t0g72lpq4NqEAymsV jFYQ== X-Gm-Message-State: AElRT7FXxbvr9zULAYW7dN9Zvv5G1g7Y63foVvgJoD3i6TfT5CJ/x/G7 Q7gwgoHRgeYJTWV5/gd+YzYaLbeGSgm1Gno/OUQ= X-Google-Smtp-Source: AG47ELsEr07nlC8P/gHZ6VBxb9K7UNUBnSPWfEO/1J7MKYum88+SlIe9yi0VKKkDREgGA2IcZnX8rJaUvD4d+2AyG0g= X-Received: by 2002:a19:d89a:: with SMTP id r26-v6mr1379020lfi.25.1520921251171; Mon, 12 Mar 2018 23:07:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.5.21 with HTTP; Mon, 12 Mar 2018 23:07:30 -0700 (PDT) In-Reply-To: References: From: Michael Zhilin Date: Tue, 13 Mar 2018 15:07:30 +0900 Message-ID: Subject: Re: GSOC 2018 ARM Cortex Processor To: Vishal Gupta , "freebsd-arm@freebsd.org" Cc: "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 06:07:33 -0000 Hi, Disclaimer: I'm neither ARM expect nor GSoC person. I may be wrong, but FreeBSD (or Linux, doesn't matter) requires MMU which is missing in Cortex M/R family of ARM processors. So it's technically difficult/impossible to port it on non-MMU processor. Added freebsd-arm@ for wide audience. Thank you! On Tue, Mar 13, 2018 at 1:12 PM, Vishal Gupta wrote: > Hi, > I am interested in working on the project to port FreeBSD to ARM Cortex M > or R series microprocessor. Some queries related to the project are :- > 1) What are the expected deliverable for the project. > 2) Where to put my draft proposal for review so that it can be improved. > > An early reply is awaited. > > Thanks and regards, > Vishal Gupta > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org > " > From owner-freebsd-arm@freebsd.org Tue Mar 13 06:22:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 421CDBF3301 for ; Tue, 13 Mar 2018 06:22:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 CA63F6B4D8 for ; Tue, 13 Mar 2018 06:22:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id l12so14334496ioc.10 for ; Mon, 12 Mar 2018 23:22:04 -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=48Ekg1VIoXA/yVkYXk/o1ndaBXE/h288J6Jd9Exlxt0=; b=WT+niEHOkUgaceZKyw+5OIODUwUgQXPcTEIWFDr9V7YEsgKWKrFysa3ZO+z63MUlL1 Mi4tTeH53hzn+Ovzq81mL9gnEa3BOgvEBOH4u003jewhcMGM2rf5wza/yaKNF+7/lhsk OVPg/eedkMbqgljpR22kMtztm7gJs0uYgoXnBzDzJqY8QrD2e/QSOsTRYYO8J4hTphcg Qjf1vKAVNsshSA8sQd/8dpTXQFOQMz+kAD/KBgRhMJtflChLrSQJa7HINHpFdDB5Tnws v4R+XyLHoIwo18o1pUyLptEV8Yrm4kwboZD+GJw2aPQpU932tFko8irwkZj+YnoSmKE7 +JMQ== 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=48Ekg1VIoXA/yVkYXk/o1ndaBXE/h288J6Jd9Exlxt0=; b=OQy1IrdLDK+Rz6mB/lk0JMINYiPf4dNRi+o0D7t6kl9nd/+yNnLDVNcdX8rvqGcCjZ 389W5F3JqSK+XRYWxqqKPIb2mOl5do4PF34v1PKNKUfR6v49xIKT+Nobtp2pzzKd5j2Q 581OEvR+vW+mou8eQgLhASIVv+e1nqOn7Zp9XQAeo1doSuelMIrI/0cVrKLcvRGB/QlH DeltyRvxG58JAfseZOstwdhXAQ70drG5Oqu9PNG6YstND8ybD7oB5OYCbw1fiCplvtgi TpX9kqZEcb9hNDJ79MLpB0+eH4oyNztfgTAy0bg/QNPVkYK5+wh8+R7rk++NfgvF/OPg s28Q== X-Gm-Message-State: AElRT7Ej0XQTmHD90eT/vAq//3zdmbkShJEaycHUXx8IWBXV8DBI80UT nEtYgs0RBvNGI40YjjMY+XoaylYNd71sA/YHelEfPA== X-Google-Smtp-Source: AG47ELuB2Pz/uBnNkakrxKDCJPD91P3KMK5JQEw2xxEgn3cngq3wCzf0SLa5sjtSOAAQtLWRtFOYFY5Xb2ogw/0AIeU= X-Received: by 10.107.18.162 with SMTP id 34mr1223731ios.168.1520922123779; Mon, 12 Mar 2018 23:22:03 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Mon, 12 Mar 2018 23:22:03 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: References: From: Warner Losh Date: Tue, 13 Mar 2018 00:22:03 -0600 X-Google-Sender-Auth: Hgmt1geNK9shqfVYvy7TjHAqDGI Message-ID: Subject: Re: GSOC 2018 ARM Cortex Processor To: Michael Zhilin Cc: Vishal Gupta , "freebsd-arm@freebsd.org" , "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 06:22:05 -0000 There's not currently any other FreeBSD port that works on a system without a MMU. The buffer cache assumes that we can fault in pages as needed based on virtual address access. The TEXT sharing between programs assumes we can map the same page into multiple processes. The shared libraries we have assume something similar, and in some cases copy on write on top of that (though that's no different from a HW perspective than these first few cases). So, if you're willing to live without these features, or find some other way to accomplish the same sorts of things, a cortex M/R port would be tricky. Also, FreeBSD's kernel size may present some obstacles. We're optimized for a rich memory environment, so we trade extra copies of code to speed up execution of code, which matches the x86 market, as well as the high-end of embedded quite well. If you are looking for a BSD to port to these processors, you might consider looking at what www.retrobsd.org has done with their 2.11BSD port to the MIPS processor in the PIC32 core with the MIPS M4K architecture. It runs in as little as 128k of RAM, while FreeBSD these days needs at least 128MB of RAM without careful tuning... Warner On Tue, Mar 13, 2018 at 12:07 AM, Michael Zhilin wrote: > Hi, > > Disclaimer: I'm neither ARM expect nor GSoC person. > > I may be wrong, but FreeBSD (or Linux, doesn't matter) requires MMU which > is my tossing in Cortex M/R family of ARM processors. So it's technically > difficult/impossible to port it on non-MMU processor. > > Added freebsd-arm@ for wide audience. > > Thank you! > > > > On Tue, Mar 13, 2018 at 1:12 PM, Vishal Gupta > wrote: > > > Hi, > > I am interested in working on the project to port FreeBSD to ARM Cortex M > > or R series microprocessor. Some queries related to the project are :- > > 1) What are the expected deliverable for the project. > > 2) Where to put my draft proposal for review so that it can be improved. > > > > An early reply is awaited. > > > > Thanks and regards, > > Vishal Gupta > > _______________________________________________ > > freebsd-embedded@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-embedded > > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@ > freebsd.org > > " > > > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org > " > From owner-freebsd-arm@freebsd.org Tue Mar 13 06:31:04 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88633BF3928 for ; Tue, 13 Mar 2018 06:31:04 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh505-vm12.bullet.mail.kks.yahoo.co.jp (nh505-vm12.bullet.mail.kks.yahoo.co.jp [183.79.57.114]) by mx1.freebsd.org (Postfix) with SMTP id A41D86B7CA for ; Tue, 13 Mar 2018 06:31:02 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.139] by nh505.bullet.mail.kks.yahoo.co.jp with NNFMP; 13 Mar 2018 06:28:39 -0000 Received: from [183.79.100.137] by t502.bullet.mail.kks.yahoo.co.jp with NNFMP; 13 Mar 2018 06:28:39 -0000 Received: from [127.0.0.1] by omp506.mail.kks.yahoo.co.jp with NNFMP; 13 Mar 2018 06:28:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 408281.62474.bm@omp506.mail.kks.yahoo.co.jp Received: (qmail 73637 invoked by uid 60001); 13 Mar 2018 06:28:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1520922519; bh=C4jmKfmg7zm/zhD6uFETgxHArsxwKIccLr2xqG3VCsI=; 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=D8AmQSyasMKbjPZMZzqckZD7WvEyA7PpES74Vaxk+UbrlfnfSCDMYvhVZOPjMgeDqpN8eAU5vuoL5OrqQJjgWb+jce3RwGZcqrrBaocVYkpIgGa1sdk0yXLIXUpKVQAEPUx4BrERsOAqyqR+toEqPeji9CDvgsV2pwZQ5sY+ivg= 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=h1VH17mKYFapWbs0bCEWE13SpInf/Z3bbcjPfvN/ypBDRnRYQBN0s8wQvK7jyt2Grw7KRcYdo+4ritbc106XyoWOot1ZZ2m40WYZxOttXNwCQYwKmbfCgOr+Yfvye1SUPa0vD3FkTb79LLqvwbmspVOE+b5R5EqTsfx8IJEHyi4=; Message-ID: <173804.55612.qm@web101713.mail.ssk.yahoo.co.jp> X-YMail-OSG: RpZbhRgVM1mJwD_EvEu1vTX_5Qwv7bIsNd_hz0QEEwdkiN.iBWW3hL2WOapyxoTounl9qdk21GOhr9F2QxtXK0W5MayhoNHYO35IRYf8y8su1hcnKKs4OQlGRiVdADBvu1fdG4vyCuA_3G2S2STNUPVymPIxLxz4AkiRKckIQVXl3sAUpn0QVF40hvyETgcr1CLyAyGz0OpHxh3dGcoXP49Wcb26HnqIkk0fd_4A5aTmJi5EKzPFqxWws14IiLmbr7EJWuC8iqu4ZX7tII5_2w_1UFbqvwY6njs4OQPuouQK9dCc.aV0KRpIwrD2GgKx9J6vyDg6FtRkcmdagt10PbX2TcLbxSWvdd9EJqop0M1dcQVXnrg_PGcv9g1LYmewuqrFsp7WuSgMPnm4r_1jldves1HqGDdBopUn3VkCVvdb4kAIGqG0UuKmB9GNTVtBW3mWnjgtdMg9w1FeuZeP7.1J3IjAEC2P8P8kPxL44LFCCicPY7LE4qFzl9jlteGLVhx6DFBOsZSSIT.Py9uOxrU0OFZ52aS.EQwY0iF3sygiSLGTCYt1uqvI35HDcCGnj7rh1TtWZyduZbsFDEBVETGL7Ac0HTLnmEvrBSSLg3blp828XPi79Q4gVKGhvS_A Received: from [203.165.91.75] by web101713.mail.ssk.yahoo.co.jp via HTTP; Tue, 13 Mar 2018 15:28:38 JST X-Mailer: YahooMailWebService/0.8.111_74 X-YMail-JAS: S_PaA3AVM1nHukHfCxVsh4BiEMpGj2sG5cuzU4YTMP2m4i9DtPxZj3dxkpFCzDX0JjQ84moeDnj61g3jsgQ0wdqq55SGmSzmPJ4NOBx4nMyjBOTus0vm_uv6MFAzSTtm8G_q References: <815937.99592.qm@web101711.mail.ssk.yahoo.co.jp> <340750.57914.qm@web101714.mail.ssk.yahoo.co.jp> <1520876476.84937.226.camel@freebsd.org> Date: Tue, 13 Mar 2018 15:28:38 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Re: Dose clang support armv4 To: Ian Lepore , Warner Losh Cc: "freebsd-arm@freebsd.org" In-Reply-To: <1520876476.84937.226.camel@freebsd.org> 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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 06:31:04 -0000 Hi=0A=0AThanks for reply.=0A=0AI'm sorry last log is missing geom_flashmap = dts entry.=0A=0AI use to cfi rootfs.=0A=0A=0ANow rootfs mount and execute i= nit.=0A=0Ahttps://gist.github.com/yamori813/ae047a28a825aac255e436fd8ccaf78= 5=0A=0A=0Ainit is broken at armv4.=A0=0A=0AI checked init is not use arm4t = instrauction(bx).=0A=0AI seem crt problem on armv4.=0A=0ABTW I post review = geom_flashmap scan capability.=0AThis is same as geom_map=A0capability.=0A= =0Ahttps://reviews.freebsd.org/D13648=0A=0A=0AThis is ad hoc method. But It= 's useful for flash file system.=A0=0A=0AThanks=0A=0AHiroki Mori=0A=0A-----= Original Message -----=0A> From: Ian Lepore =0A> To: Warn= er Losh ; Mori Hiroki =0A> Cc: "free= bsd-arm@freebsd.org" =0A> Date: 2018/3/13, Tue 02:= 41=0A> Subject: Re: Dose clang support armv4=0A> =0A> On Mon, 2018-03-12 at= 10:43 -0600, Warner Losh wrote:=0A>> Hi Mori-san,=0A>> =0A>> I've not tr= ied my armv4 boards with clang 6 yet.=0A>> =0A>> However, you are hanging = in mountroot. What's normally printed there?=0A>> Ian=0A>> just did some = things to fix it for USB ad ZFS. Maybe that broke this=0A>> use=0A>> case= accidentally.=0A>> =0A>> Warner=0A>> =0A> =0A> Unfortunately, my only arm= v4/5 system that's anywhere close to bootable=0A> =A0right now is a Dreampl= ug, and it also hangs at mountroot, but for a=0A> different reason: somehow= its ethernet driver gets a continuous "RX=0A> error" interrupt storm (and = my rootfs is on nfs). =A0I haven't had time=0A> to try putting together a r= ootfs on sdcard or sata to see if it boots=0A> all the way.=0A> =0A> -- Ian= =0A> From owner-freebsd-arm@freebsd.org Tue Mar 13 07:49:17 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADD616438; Tue, 13 Mar 2018 07:49:17 +0000 (UTC) (envelope-from vishalgupta7972@gmail.com) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 244666E583; Tue, 13 Mar 2018 07:49:17 +0000 (UTC) (envelope-from vishalgupta7972@gmail.com) Received: by mail-wr0-x234.google.com with SMTP id d10so7212593wrf.3; Tue, 13 Mar 2018 00:49:17 -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=SEdTM3GCwQWEH7Z82VzE/bRA1qH55n86QttlXG92F3k=; b=tWqBYzo2V9LpBEQ/CQOZUQwxBJrTj73UpvSx2SN91SMCD93/UG+U5V5FWzTOKSZRFd Dd5HGomhQYPfyhuMmeaB1GDCZMeiquz2cVwl7YC9ENkyR+87j3iafqE23J+acZbE753L jdDP5GpWl1+1topmWMk49HBL/qphulTNfgoMK6AEyy6h1AORH0irMPaHWNvarkewdTgR +g0BcPsZ0F3pvs5Cw5re8OIE/v7SpJv75UQefd3ptu/NZTmbjU54xisnY8UOUtAii/4+ UW1yF+k4iQHjIcybmDUHce5D97GPRHMcUS4yg6wtjNePjgjB0zHgAEMJyQM8x71v3dkV i2EA== 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=SEdTM3GCwQWEH7Z82VzE/bRA1qH55n86QttlXG92F3k=; b=GVLcxR/I5nwHUuE4t8dxjn+0xtSJHJfL0BewqApqZd6u3HvbYSh2aQPoH8ej2DSzke xmTZqz1jT4zeeZFeJdpeGkjqK+VIIj64XURjiF38vWKL/h6K1JLxSx1HE0LjTe4h2j+f wE0aBC9miJBxgUYMyVzsob4C+YJS1WbdR9BT77QBQCm0pB0/7jYf0HqgfQOfQ8NUGQm/ d0iIdbwZX8U0ufLwiRnT2hQiJiMRiv1+BErR3Ke/53rCDKEwquWi7FD7lDP9rC2Qf/ap 4phlQwk+J229MxEMkAV64A9cUjigerVSVh2i+j452hUIFnbwARJcbAzeqLjHzEydG9dk SflA== X-Gm-Message-State: AElRT7HGnQBd1qE1nlzzdG1Xc3MbLtkUnlY3MaZJCUT9i2Q7cLH5QknE yspqyrEbU9667xnaF8X+GnryfBwJZhXR0cq9cyDNQ1p1 X-Google-Smtp-Source: AG47ELsA9aNgQiCA0cUicbIE9pqYwVYqSlB2oTAFypKtA2eqaOxcXr/GifuYkL4gjAelB3WX+besAwhx3QqGnfd+K6U= X-Received: by 10.223.179.84 with SMTP id k20mr8548681wrd.253.1520927355941; Tue, 13 Mar 2018 00:49:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.177.10 with HTTP; Tue, 13 Mar 2018 00:49:15 -0700 (PDT) In-Reply-To: References: From: Vishal Gupta Date: Tue, 13 Mar 2018 13:19:15 +0530 Message-ID: Subject: Re: GSOC 2018 ARM Cortex Processor To: Warner Losh Cc: Michael Zhilin , "freebsd-arm@freebsd.org" , "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 07:49:17 -0000 Thank you for the reply. Which new processor would you suggest between PowerPC, ARM, and MIPS which i can port during the summer period and will also be useful for the community. Vishal Gupta On Tue, Mar 13, 2018 at 11:52 AM, Warner Losh wrote: > There's not currently any other FreeBSD port that works on a system > without a MMU. The buffer cache assumes that we can fault in pages as > needed based on virtual address access. The TEXT sharing between programs > assumes we can map the same page into multiple processes. The shared > libraries we have assume something similar, and in some cases copy on write > on top of that (though that's no different from a HW perspective than these > first few cases). > > So, if you're willing to live without these features, or find some other > way to accomplish the same sorts of things, a cortex M/R port would be > tricky. Also, FreeBSD's kernel size may present some obstacles. We're > optimized for a rich memory environment, so we trade extra copies of code > to speed up execution of code, which matches the x86 market, as well as the > high-end of embedded quite well. > > If you are looking for a BSD to port to these processors, you might > consider looking at what www.retrobsd.org has done with their 2.11BSD > port to the MIPS processor in the PIC32 core with the MIPS M4K > architecture. It runs in as little as 128k of RAM, while FreeBSD these days > needs at least 128MB of RAM without careful tuning... > > Warner > > On Tue, Mar 13, 2018 at 12:07 AM, Michael Zhilin wrote: > >> Hi, >> >> Disclaimer: I'm neither ARM expect nor GSoC person. >> >> I may be wrong, but FreeBSD (or Linux, doesn't matter) requires MMU which >> is my tossing in Cortex M/R family of ARM processors. So it's technically >> difficult/impossible to port it on non-MMU processor. >> >> Added freebsd-arm@ for wide audience. >> >> Thank you! >> >> >> >> On Tue, Mar 13, 2018 at 1:12 PM, Vishal Gupta >> wrote: >> >> > Hi, >> > I am interested in working on the project to port FreeBSD to ARM Cortex >> M >> > or R series microprocessor. Some queries related to the project are :- >> > 1) What are the expected deliverable for the project. >> > 2) Where to put my draft proposal for review so that it can be improved. >> > >> > An early reply is awaited. >> > >> > Thanks and regards, >> > Vishal Gupta >> > _______________________________________________ >> > freebsd-embedded@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-embedded >> > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@ >> freebsd.org >> > " >> > >> _______________________________________________ >> freebsd-embedded@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-embedded >> To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@ >> freebsd.org" >> > > From owner-freebsd-arm@freebsd.org Tue Mar 13 09:26:40 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9AA5F31E35; Tue, 13 Mar 2018 09:26:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 1DE76729EE; Tue, 13 Mar 2018 09:26:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w2D9QS35071501 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Mar 2018 11:26:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w2D9QS35071501 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w2D9QRKT071500; Tue, 13 Mar 2018 11:26:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 13 Mar 2018 11:26:27 +0200 From: Konstantin Belousov To: Warner Losh Cc: Michael Zhilin , "freebsd-arm@freebsd.org" , Vishal Gupta , "freebsd-embedded@freebsd.org" Subject: Re: GSOC 2018 ARM Cortex Processor Message-ID: <20180313092627.GL76926@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 09:26:40 -0000 On Tue, Mar 13, 2018 at 12:22:03AM -0600, Warner Losh wrote: > There's not currently any other FreeBSD port that works on a system without > a MMU. The buffer cache assumes that we can fault in pages as needed based > on virtual address access. The TEXT sharing between programs assumes we can No, buffer cache does not fault the pages in, but it is indeed relies somewhat on ability to remap pages. This is true for B_VMIO buffers, not for the malloc-ed buffers. > map the same page into multiple processes. The shared libraries we have > assume something similar, and in some cases copy on write on top of that > (though that's no different from a HW perspective than these first few > cases). > > So, if you're willing to live without these features, or find some other > way to accomplish the same sorts of things, a cortex M/R port would be > tricky. Also, FreeBSD's kernel size may present some obstacles. We're > optimized for a rich memory environment, so we trade extra copies of code > to speed up execution of code, which matches the x86 market, as well as the > high-end of embedded quite well. Living without the listed features means, in essence, that userspace cannot be even started. Which, in fact, is not that fatal for the applications where -R cores are supposed to be used. If kernel-only operations are enough, or the application is adopted to be run as part of the kernel, it might be quite fun project to take. From owner-freebsd-arm@freebsd.org Tue Mar 13 10:20:21 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F11F3F36C18 for ; Tue, 13 Mar 2018 10:20:20 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 5761D75138 for ; Tue, 13 Mar 2018 10:20:20 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: by mail-wr0-x234.google.com with SMTP id z12so20966978wrg.4 for ; Tue, 13 Mar 2018 03:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=UygtnJb55Tpuiyb2BzP+Q4iDvL9NfzNmUAe6TpPBezc=; b=eIonMOx6B89VKX+YUsbQPDN1iAHBnpvsaL4H2HGfeErAs7gdU20WnLbbthNsEG/7Ll E3PjMbTKVVR5Tqos4DaufgTY0y3Y8QucBsEZJVpR5Xu8O7AW0XzKiaWMAlefIYFr7NqU 5MqHGQcM+9zvmLOtuyuo1JPfZ24E+j6GpSYQ89tBLVK8YxbAAROg8GbVkDI4x/HQmL7d 8e4kb1ulCKuR2hFnQVprRgb+EuHbP8HCP9mTu9D9v/e4GopKoivLHaj8ELYwDN+tkwNC 3d4XaaTo15QB5rMM0WIjc4dej/jZmIE/pn/skjWls0BfHNTLKy1nbD1MyIiWeTfn6ZwS yP8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=UygtnJb55Tpuiyb2BzP+Q4iDvL9NfzNmUAe6TpPBezc=; b=XatcPRPPZYqfgawxMl71EQCQNNHX3ODHFEplkCWxiG72XbzeDxWOKMnm5SPGgirRcF 0nX5CyCGG2a42RtORElv7MyP4oPCIoaa93kiKMoso5aJ0R5G8Kef5hfii+daq9WjtJYm 9+NbJYutBSeY38gd1lIO4mbg+OBtNzwpPxO+/itrUWnPT+KWSwPCqc1kJJ2AlC+EkYPn J4AxNsBLk+wgCpZlxVY3V868JYlJqyDSlrFpGb5MZjtUU0AD3QqTO5C5zpvUr9kR2irK 6Ggb/Vz2BJSzJ/kLW+dJ7MPkTxAED/74JI/nvZG6uDfOjUvR+99/ue18qZOO0PAf/T7Y NsPg== X-Gm-Message-State: AElRT7HRZQgWNbAkR9Zu0ikciErpVmoxpPsx1lK1OrT5MSeRIugDTkam y2YSlV60VesznlOhGXW/Oa2Cu0DF X-Google-Smtp-Source: AG47ELszs2l7Gw1uxBE1pvWMiWwXi6mOG0ZxsK2cVCuzJa7ESFM6jxzKC9yFCWJFZ32HH5Fpu2ezlg== X-Received: by 10.28.161.4 with SMTP id k4mr231475wme.103.1520936418747; Tue, 13 Mar 2018 03:20:18 -0700 (PDT) Received: from [172.16.0.150] (net-188-219-105-237.cust.vodafonedsl.it. [188.219.105.237]) by smtp.gmail.com with ESMTPSA id p68sm264996wmg.7.2018.03.13.03.20.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 03:20:17 -0700 (PDT) To: freebsd-arm@freebsd.org From: Nicola Mingotti Subject: Stable and Current not booting in BeagleBone Green Message-ID: Date: Tue, 13 Mar 2018 11:20:16 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 10:20:21 -0000 Hi, I would like to signal that FreeBSD-11.1 and CURRENT-8-march-2018 do not boot into BeagleBone Green. The problem seems related to the DTB. I attach two screenshot in case you get some extra info from that. Bye Nicola -- -------------------------- Dr. Nicola Mingotti R&D - Borghi Srl CTO - BondInsider -------------------------- From owner-freebsd-arm@freebsd.org Tue Mar 13 12:06:00 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78A19F43A12 for ; Tue, 13 Mar 2018 12:06:00 +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 0E95879843 for ; Tue, 13 Mar 2018 12:05:59 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=192.168.25.127; helo=restart.be; envelope-from=hlh@restart.be; receiver= DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 400tqB1mn1zxpK Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (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 400tqB1mn1zxpK for ; Tue, 13 Mar 2018 13:05:57 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [192.168.24.9]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id w2DC5uOv022771 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 13 Mar 2018 13:05:56 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: 3 problems with Pine64+ 12.0-CURRENT r328259 From: Henri Hennebert To: freebsd-arm@freebsd.org References: Message-ID: Date: Tue, 13 Mar 2018 13:05:56 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 12:06:00 -0000 On 01/29/2018 14:15, Henri Hennebert wrote: > Hello, > > I encounter some problems with r328259 on Pine64+ 2GB > > 1. to complete boot I must boot in verbose mode else kernel freeze after: > > ... > Timecounters tick every 1.000 msec > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 12Mbps Full Speed USB v1.0 > --- freeze --- Solved since r329463 > > 2. If I run multiple times `periodic daily` with root on a USB disk > connected with a auto powered hub, time drift too fast even with ntpd > running. Now I'm running r330758 and the time drift is still there. The ntpd log say that _every_ time the problem arise, the drift is around -178.95 > > 3. The connection to internet with mpd5 and a box in bridge mode has > a sluggish throughput (7 to 9 KB/s) > The same config running r320599 has a throughput of 3 to 4MB/s. This > r320599 run with this patch (Bug 220140): > > --- sys/netgraph/ng_iface.c.orig    2017-06-19 19:50:51.428612000 +0700 > +++ sys/netgraph/ng_iface.c    2017-06-19 19:51:31.196104000 +0700 > @@ -64,6 +64,7 @@ >  #include >  #include >  #include > +#include >  #include >  #include >  #include > @@ -112,9 +113,15 @@ struct ng_iface_private { >      int    unit;            /* Interface unit number */ >      node_p    node;            /* Our netgraph node */ >      hook_p    hooks[NUM_FAMILIES];    /* Hook for each address family */ > +    struct rmlock    lock;        /* Protect private data changes */ >  }; >  typedef struct ng_iface_private *priv_p; > > +#define    PRIV_RLOCK(priv, t)    rm_rlock(&priv->lock, t) > +#define    PRIV_RUNLOCK(priv, t)    rm_runlock(&priv->lock, t) > +#define    PRIV_WLOCK(priv)    rm_wlock(&priv->lock) > +#define    PRIV_WUNLOCK(priv)    rm_wunlock(&priv->lock) > + >  /* Interface methods */ >  static void    ng_iface_start(struct ifnet *ifp); >  static int    ng_iface_ioctl(struct ifnet *ifp, u_long cmd, caddr_t > data); > @@ -431,6 +438,7 @@ ng_iface_bpftap(struct ifnet *ifp, struc >  static int >  ng_iface_send(struct ifnet *ifp, struct mbuf *m, sa_family_t sa) >  { > +    struct rm_priotracker priv_tracker; >      const priv_p priv = (priv_p) ifp->if_softc; >      const iffam_p iffam = get_iffam_from_af(sa); >      int error; > @@ -448,7 +456,9 @@ ng_iface_send(struct ifnet *ifp, struct > >      /* Send packet. If hook is not connected, mbuf will get freed. */ >      NG_OUTBOUND_THREAD_REF(); > +    PRIV_RLOCK(priv, &priv_tracker); >      NG_SEND_DATA_ONLY(error, *get_hook_from_iffam(priv, iffam), m); > +    PRIV_RUNLOCK(priv, &priv_tracker); >      NG_OUTBOUND_THREAD_UNREF(); > >      /* Update stats. */ > @@ -516,6 +526,8 @@ ng_iface_constructor(node_p node) >          return (ENOMEM); >      } > > +    rm_init(&priv->lock, "ng_iface private rmlock"); > + >      /* Link them together */ >      ifp->if_softc = priv; >      priv->ifp = ifp; > @@ -562,16 +574,21 @@ static int >  ng_iface_newhook(node_p node, hook_p hook, const char *name) >  { >      const iffam_p iffam = get_iffam_from_name(name); > +    const priv_p priv = NG_NODE_PRIVATE(node); >      hook_p *hookptr; > >      if (iffam == NULL) >          return (EPFNOSUPPORT); > -    hookptr = get_hook_from_iffam(NG_NODE_PRIVATE(node), iffam); > -    if (*hookptr != NULL) > +    PRIV_WLOCK(priv); > +    hookptr = get_hook_from_iffam(priv, iffam); > +    if (*hookptr != NULL) { > +        PRIV_WUNLOCK(priv); >          return (EISCONN); > +    } >      *hookptr = hook; >      NG_HOOK_HI_STACK(hook); >      NG_HOOK_SET_TO_INBOUND(hook); > +    PRIV_WUNLOCK(priv); >      return (0); >  } > > @@ -730,6 +747,7 @@ ng_iface_shutdown(node_p node) >      CURVNET_RESTORE(); >      priv->ifp = NULL; >      free_unr(V_ng_iface_unit, priv->unit); > +    rm_destroy(&priv->lock); >      free(priv, M_NETGRAPH_IFACE); >      NG_NODE_SET_PRIVATE(node, NULL); >      NG_NODE_UNREF(node); > @@ -748,7 +766,9 @@ ng_iface_disconnect(hook_p hook) > >      if (iffam == NULL) >          panic("%s", __func__); > +    PRIV_WLOCK(priv); >      *get_hook_from_iffam(priv, iffam) = NULL; > +    PRIV_WUNLOCK(priv); >      return (0); >  } > > Does someone else encounter those problems? > > Henri > _______________________________________________ > 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 Tue Mar 13 13:35:43 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BEEEF4E4F5 for ; Tue, 13 Mar 2018 13:35:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 643187D4DD for ; Tue, 13 Mar 2018 13:35:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x230.google.com with SMTP id u84so112349iod.9 for ; Tue, 13 Mar 2018 06:35:42 -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=dMvKfeTAwhuBRSXXK8XtF5SYVPdfKmPMSntxBDRh2D8=; b=wWJCdanZE1CuMbaYo3oJ0vnap5Xc8NlxUYXJUzqf/0VnEv4YDjEwd3aBWmPN58QLYv NBT9gBYDGYQ+rf+pzlgFYmfQrmNXC8JB+tuf9FnxQLioHUzs1G+Z44SS2LReWlV/UVhu 46hBTH09KYyo3rk6BMhSKQed/MRKPyUOVWsdwg+Nl7i+IHCnYNPABpKE80b5oeuTVmKN jgmPVfT+vYVKRZ+WZVXDGB044hOO/cIY7akROSwakrNIxeMqHtQfC8WG0YlwHpnMr3M4 DOlpipS9Me033XDbAABCUffHSzQQzdDaLA+93aWuhpcF7bpXQTYN38uTDqWKCTlibbIx W7kA== 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=dMvKfeTAwhuBRSXXK8XtF5SYVPdfKmPMSntxBDRh2D8=; b=MD1/0kQVN+tQAyhr8LpXyUUjYrEu0skvR8wZJBVmqBpNn/6Qv7fa01P/4BZBqB3kJC fnwjoy6uiFdfFBTsL2HrRWQhYGPL8c4oOi94RvA26nPBSDe44WN/B8jtaOSqvfn1npNL xLBjTiKI2cYwjBFC+cCMOmZMRm66fa1+vqlR6p3cYDGHbQ+bkSw6XzxO/Iz18n1J2g3y OCXb0dSzTH7ZjqTTsVkWgJG5POFV/FXAwKxEUvkcfGKTFeGLrHaxMhmnSYx6l8w6mgFj oLRHJy3+b+2nklWUl/3IzK8rIzhUswFszaOqK2yJ2ldFA5d2xdx2X8K43Do/69QXfEnE 2L+w== X-Gm-Message-State: AElRT7HZlBMHygY3iraqA/Ylz5kj1jl8xjxmyPk18re3VXBe/yzLHj3f E3PNzYmgSON2H8XvjRNJPzT2nAt4s5ficN2+14jrWQ== X-Google-Smtp-Source: AG47ELsI7LAixPJvV3s4U31qzlI8+r1GD1w/0mId4KIzmyHmtsLHrNJKfJKbXulRRb5+NjV4FnmRZ+kYi/+Aa7Ue6gs= X-Received: by 10.107.187.129 with SMTP id l123mr702580iof.39.1520948141673; Tue, 13 Mar 2018 06:35:41 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Tue, 13 Mar 2018 06:35:40 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: References: From: Warner Losh Date: Tue, 13 Mar 2018 07:35:40 -0600 X-Google-Sender-Auth: IP7TZhyGhUgASKDQaI_Gp0aGWWI Message-ID: Subject: Re: Stable and Current not booting in BeagleBone Green To: Nicola Mingotti Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 13:35:43 -0000 The screen shots don't seem to have made it to the mailing list. Warner On Tue, Mar 13, 2018 at 4:20 AM, Nicola Mingotti wrote: > Hi, > > I would like to signal that FreeBSD-11.1 and CURRENT-8-march-2018 > do not boot into BeagleBone Green. The problem seems related > to the DTB. > > I attach two screenshot in case you get some extra info from that. > > Bye > Nicola > > > > -- > -------------------------- > Dr. Nicola Mingotti > R&D - Borghi Srl > CTO - BondInsider > -------------------------- > > _______________________________________________ > 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 Tue Mar 13 13:46:06 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEB4DF4F033 for ; Tue, 13 Mar 2018 13:46:06 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 28E347DC10 for ; Tue, 13 Mar 2018 13:46:06 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: by mail-wr0-x234.google.com with SMTP id l8so8520606wrg.5 for ; Tue, 13 Mar 2018 06:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=zBNwgAaeUVfe+Wt9ue0ceajJaaPEQoTUqav9De/rF4k=; b=pZnLrIXB7m8kYwQdrN/7C/uGDV1CoTODcsgPYcYD2Fc88t96Ts7XE2MxM4uh6krxfG NaAI5YrBedEFxr/HlIQIjYZnbvAx6QoCGfiwLetmU9t2Z84ksq99ZsCvGL6S0/6R932i GA9CGULUhaL4AQ5Sll/nLLCSC6W5MT5Ilp4qKBfnDptqzTwy/4thkai9ytJ2SEDydQTe C9OEki1U9DBpg+QxLxnVBT+da45DuRpv9X+aUctcd34RRQu01ia64gGnTwneyO0mnxTd tSPtp1FnKJ8MNoyl+yJM4InQIdYCPqFFMeY0hwZ/oatUazVmEUTYF/6vPrbSXG/bQZ19 furg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=zBNwgAaeUVfe+Wt9ue0ceajJaaPEQoTUqav9De/rF4k=; b=Cb2cg1kBJjWgYkaPvZTSxQrfkR/xz2036dafVUV2ak/3DTNbQkS9Gw6rWjvoVRnGQf b+tGYa4cdKH+c3ncDdZvV83Ihq98fs2rV6iGAlYt20raedP6QKxDHBe5z7L1iyOH49Gi xyMZdxEXxSdVJG8unS1+hegAkXG+4VwDYGVOWRnbu+IWh2Zls1XzWB9CwlC7DrGyLHKK MLi90Lm0+Bmu1CE0VwEZUGEiSNNYncKV+1IOpANb+iTIBZt8DKfY8d7r0BMC/8rdZq3N ydDpjX+DUekDY4wHsNMyRBqWLX9JnKQrW47c4VTybYWqsgQkMSB9GXpu+6wn/SffW/AW gYMw== X-Gm-Message-State: AElRT7Ge6okJG2nWBa5UcH6AJp9obKl85/BfHrDFKFIBRuwg/yea76+l +4LLjj1YcCN/LouXOesEMzQ= X-Google-Smtp-Source: AG47ELuUX4ivccgaLlSQXpJhv8QXiahN75r1zVWz3XCKIbvrHtVVZgutDZOSdei6sqLFczYx6+9kkA== X-Received: by 10.223.182.135 with SMTP id j7mr699769wre.66.1520948764757; Tue, 13 Mar 2018 06:46:04 -0700 (PDT) Received: from [172.16.0.150] (net-188-219-105-237.cust.vodafonedsl.it. [188.219.105.237]) by smtp.gmail.com with ESMTPSA id n127sm246716wmb.5.2018.03.13.06.46.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 06:46:03 -0700 (PDT) Subject: Re: Stable and Current not booting in BeagleBone Green To: Warner Losh Cc: "freebsd-arm@freebsd.org" , Nicola Mingotti References: From: Nicola Mingotti Message-ID: <1a3fc515-3a96-7781-49de-38ab41f04976@gmail.com> Date: Tue, 13 Mar 2018 14:46:02 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 13:46:07 -0000 Ok, here are the links: https://drive.google.com/open?id=1webPwU9IHDlT0yT2KTQXOAy3vt3sbZYd https://drive.google.com/open?id=1l_HxBbHeZI--_xK6NXcUAeNT6bd3zgIH Bye n. On 03/13/18 14:35, Warner Losh wrote: > The screen shots don't seem to have made it to the mailing list. > > Warner > > On Tue, Mar 13, 2018 at 4:20 AM, Nicola Mingotti > wrote: > > Hi, > > I would like to signal that FreeBSD-11.1 and CURRENT-8-march-2018 > do not boot into BeagleBone Green. The problem seems related > to the DTB. > > I attach two screenshot in case you get some extra info from that. > > Bye > Nicola > > > > -- > -------------------------- > Dr. Nicola Mingotti > R&D - Borghi Srl > CTO - BondInsider > -------------------------- > > _______________________________________________ > 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 > " > > -- -------------------------- Dr. Nicola Mingotti R&D - Borghi Srl CTO - BondInsider -------------------------- From owner-freebsd-arm@freebsd.org Tue Mar 13 23:14:12 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE50130F for ; Tue, 13 Mar 2018 23:14:12 +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 34EE67BA76 for ; Tue, 13 Mar 2018 23:14:11 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 188320d0-2714-11e8-b951-f99fef315fd9 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 188320d0-2714-11e8-b951-f99fef315fd9; Tue, 13 Mar 2018 23:13:10 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w2DNE2Oo020797; Tue, 13 Mar 2018 17:14:02 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1520982842.84937.282.camel@freebsd.org> Subject: Re: Dose clang support armv4 From: Ian Lepore To: Mori Hiroki , Warner Losh Cc: "freebsd-arm@freebsd.org" Date: Tue, 13 Mar 2018 17:14:02 -0600 In-Reply-To: <173804.55612.qm@web101713.mail.ssk.yahoo.co.jp> References: <815937.99592.qm@web101711.mail.ssk.yahoo.co.jp> <340750.57914.qm@web101714.mail.ssk.yahoo.co.jp> <1520876476.84937.226.camel@freebsd.org> <173804.55612.qm@web101713.mail.ssk.yahoo.co.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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 23:14:12 -0000 On Tue, 2018-03-13 at 15:28 +0900, Mori Hiroki wrote: > Hi > > Thanks for reply. > > I'm sorry last log is missing geom_flashmap dts entry. > > I use to cfi rootfs. > > > Now rootfs mount and execute init. > > https://gist.github.com/yamori813/ae047a28a825aac255e436fd8ccaf785 > > I think clang defaults to armv4t if the arch is just 'arm'.  You should be able to fix this by building everything with CPUTYPE=armv4.  Put that in your make.conf file.  If you are doing a cross build do not put it in your main /etc/make.conf, instead create another file somewhere, and add this to the make command line when you crossbuild:   __MAKE_CONF=/somewhere/make.conf  You will have to rebuild everything (make clean). -- Ian > init is broken at armv4.  > > I checked init is not use arm4t instrauction(bx). > > I seem crt problem on armv4. > > BTW I post review geom_flashmap scan capability. > This is same as geom_map capability. > > https://reviews.freebsd.org/D13648 > > > This is ad hoc method. But It's useful for flash file system.  > > Thanks > > Hiroki Mori > > ----- Original Message ----- > > > > From: Ian Lepore > > To: Warner Losh ; Mori Hiroki > p> > > Cc: "freebsd-arm@freebsd.org" > > Date: 2018/3/13, Tue 02:41 > > Subject: Re: Dose clang support armv4 > > > > On Mon, 2018-03-12 at 10:43 -0600, Warner Losh wrote: > > > > > >  Hi Mori-san, > > > > > >  I've not tried my armv4 boards with clang 6 yet. > > > > > >  However, you are hanging in mountroot. What's normally printed > > > there? > > >  Ian > > >  just did some things to fix it for USB ad ZFS. Maybe that broke > > > this > > >  use > > >  case accidentally. > > > > > >  Warner > > > > > Unfortunately, my only armv4/5 system that's anywhere close to > > bootable > >  right now is a Dreamplug, and it also hangs at mountroot, but for > > a > > different reason: somehow its ethernet driver gets a continuous "RX > > error" interrupt storm (and my rootfs is on nfs).  I haven't had > > time > > to try putting together a rootfs on sdcard or sata to see if it > > boots > > all the way. > > > > -- Ian > > > _______________________________________________ > 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 Mar 14 06:39:08 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 064AAF595D8; Wed, 14 Mar 2018 06:39:08 +0000 (UTC) (envelope-from mizhka@gmail.com) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (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 431A46F7FF; Wed, 14 Mar 2018 06:39:07 +0000 (UTC) (envelope-from mizhka@gmail.com) Received: by mail-lf0-x244.google.com with SMTP id l191-v6so3089759lfe.1; Tue, 13 Mar 2018 23:39:07 -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=9go4XGkk/pMlbmKrAKO9ZEvewlsQWgjy9WNaxzNYAXU=; b=plH1zOKyxnSPb7pdmbfYePcAonD6hnh2spyHDnGuiKo3yleiBNMvoQENVc7C7icEKp 0BgnS/NmkUwOHTjSYVpE8Ug8CnbifQE/BPeRmF6pl2EU3Y2tB0oCxDaL+jpa6AF5onEp kGvkFoONXZDraQJVUyXkK3GuXAY9FWxoK1Hgls92JC8Z2KHeFWIf9b35CNqleYHcVeO2 BEFAEkK2Qumt990bcXEukTkMjLySENHY/4/7fP2aYl3ZrM9cWFxSa+qxMJv4RG1o34fG HmS4FIvyi8OqU8o5YQQkgsYKMcY9C8hCFVBOv2E2lpdN0USdwJXVVylcEqMSpMMosduw hw7Q== 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=9go4XGkk/pMlbmKrAKO9ZEvewlsQWgjy9WNaxzNYAXU=; b=oOQah07A2idk/m7Yu+qFYPto4LEDy27cbqQ6/EK6dEZkArRQL+Zz2MKPOZtpapbtcR HYz6Ml/t4i3FtwUE1qohuA+IoiSLfnkg/jJHk4W/cOMtjfvZ4ZcrgI958PKHJlGejo2w CqQQJhcwwR4FYyAVDhG7AY/kSMjENbj9NjHo+q5gSgE6KLBxw2P50GWMEY8Z/mwlviud FSFXhccSYaYcf8qYvopwXHda4DMkPfjksRFAmt4ylnImdRTT5qgukWA86V1ilR7Dtc3U n0vbmHUaWzxQGw/ZJ8t7dmVvtVd6dzGoZEaP06AhaT8Us4Z0xVlHIMOProPpHeknn3jx Ixow== X-Gm-Message-State: AElRT7EcKmmAUMr0jxVeLkUWbPiIO+tpGGgutve9zRgUpLfhZZCtn3ko mbpq5+84WTwOkZa1coFq6Tdn7uTeM+WuD96RZHk= X-Google-Smtp-Source: AG47ELstwvI3Fehhh4i7RELKITRPAaeR3Qh04rXS7ORp+jnHylDQdugFVF4dXZMDdd6b5zUqQUxlznp347D4Lp14cQU= X-Received: by 10.46.47.23 with SMTP id v23mr2334966ljv.70.1521009545927; Tue, 13 Mar 2018 23:39:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.5.21 with HTTP; Tue, 13 Mar 2018 23:39:05 -0700 (PDT) In-Reply-To: References: From: Michael Zhilin Date: Wed, 14 Mar 2018 15:39:05 +0900 Message-ID: Subject: Re: GSOC 2018 ARM Cortex Processor To: Vishal Gupta Cc: Warner Losh , "freebsd-arm@freebsd.org" , "freebsd-embedded@freebsd.org" , freebsd-mips@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 06:39:08 -0000 Added freebsd-mips@ Regarding MIPS, I would like to see support for retail Realtek MIPS chips for instance (RTL8196, RTL8197). There are new brand router models: https://wikidevi.com/wiki/Tenda_AC6_V2 or https://wikidevi.com/wiki/Realtek#bgn_2 Thanks! On Tue, Mar 13, 2018 at 4:49 PM, Vishal Gupta wrote: > Thank you for the reply. > Which new processor would you suggest between PowerPC, ARM, and MIPS > which i can port during the summer period and will also be useful for the > community. > > Vishal Gupta > > On Tue, Mar 13, 2018 at 11:52 AM, Warner Losh wrote: > >> There's not currently any other FreeBSD port that works on a system >> without a MMU. The buffer cache assumes that we can fault in pages as >> needed based on virtual address access. The TEXT sharing between programs >> assumes we can map the same page into multiple processes. The shared >> libraries we have assume something similar, and in some cases copy on write >> on top of that (though that's no different from a HW perspective than these >> first few cases). >> >> So, if you're willing to live without these features, or find some other >> way to accomplish the same sorts of things, a cortex M/R port would be >> tricky. Also, FreeBSD's kernel size may present some obstacles. We're >> optimized for a rich memory environment, so we trade extra copies of code >> to speed up execution of code, which matches the x86 market, as well as the >> high-end of embedded quite well. >> >> If you are looking for a BSD to port to these processors, you might >> consider looking at what www.retrobsd.org has done with their 2.11BSD >> port to the MIPS processor in the PIC32 core with the MIPS M4K >> architecture. It runs in as little as 128k of RAM, while FreeBSD these days >> needs at least 128MB of RAM without careful tuning... >> >> Warner >> >> On Tue, Mar 13, 2018 at 12:07 AM, Michael Zhilin >> wrote: >> >>> Hi, >>> >>> Disclaimer: I'm neither ARM expect nor GSoC person. >>> >>> I may be wrong, but FreeBSD (or Linux, doesn't matter) requires MMU which >>> is my tossing in Cortex M/R family of ARM processors. So it's technically >>> difficult/impossible to port it on non-MMU processor. >>> >>> Added freebsd-arm@ for wide audience. >>> >>> Thank you! >>> >>> >>> >>> On Tue, Mar 13, 2018 at 1:12 PM, Vishal Gupta >> > >>> wrote: >>> >>> > Hi, >>> > I am interested in working on the project to port FreeBSD to ARM >>> Cortex M >>> > or R series microprocessor. Some queries related to the project are :- >>> > 1) What are the expected deliverable for the project. >>> > 2) Where to put my draft proposal for review so that it can be >>> improved. >>> > >>> > An early reply is awaited. >>> > >>> > Thanks and regards, >>> > Vishal Gupta >>> > _______________________________________________ >>> > freebsd-embedded@freebsd.org mailing list >>> > https://lists.freebsd.org/mailman/listinfo/freebsd-embedded >>> > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@ >>> freebsd.org >>> > " >>> > >>> _______________________________________________ >>> freebsd-embedded@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-embedded >>> To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@ >>> freebsd.org" >>> >> >> > From owner-freebsd-arm@freebsd.org Wed Mar 14 07:38:07 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DB7C794 for ; Wed, 14 Mar 2018 07:38:07 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh503-vm8.bullet.mail.kks.yahoo.co.jp (nh503-vm8.bullet.mail.kks.yahoo.co.jp [183.79.56.194]) by mx1.freebsd.org (Postfix) with SMTP id C9E0B72421 for ; Wed, 14 Mar 2018 07:38:06 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.139] by nh503.bullet.mail.kks.yahoo.co.jp with NNFMP; 14 Mar 2018 07:35:35 -0000 Received: from [183.79.100.135] by t502.bullet.mail.kks.yahoo.co.jp with NNFMP; 14 Mar 2018 07:35:35 -0000 Received: from [127.0.0.1] by omp504.mail.kks.yahoo.co.jp with NNFMP; 14 Mar 2018 07:35:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 42668.5690.bm@omp504.mail.kks.yahoo.co.jp Received: (qmail 16869 invoked by uid 60001); 14 Mar 2018 07:35:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1521012934; bh=wK9Q2fLHL6Q1o9D8SIbX4NxFASP8Rl6DPETWcrkk7uA=; 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=ZyvhcCbAeR1yRa+LmAxYlZkkf6VGgoOlp6RyKRh5qpStOYAsfntnClyUQ2oxHdaeKj7wipH22nUc47UkTu9oA+T2ycx5tMR6vO+Neqi1b4n6+xAGQJWcshij9zwSuqwo3Oj8Mcs1cypXPj9pS43K4cB8JqqlbAKeu3Iuv8zMBBc= 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=Vvfqclwodv1czPWsW1woP72a4PZWzOf+AHYjD/XYK0vxRGWM/BKXWJKTH2ErWdfk6GJjffJr7SepCdloO1/NRgX6XbxZFhuj2bVSFwE205/TQRufg36Jw6BmIpbC4dsAXQP3dvMWFApFrsiarxy6nuZSaFx5fq56iIL/Q2tolPM=; Message-ID: <661126.97758.qm@web101706.mail.ssk.yahoo.co.jp> X-YMail-OSG: tRA2wSMVM1nonZpv1WI2WoT7gngjFbD3kHgebK106NU1cJ0RS6T.bSAtbc51aUad2GjQxc9CEwvpUNE0mIcGtJsuiUcsYUyM4u5CL29lVKq4xzgvNr1jsZFmbsMGBrNBz6rudRkY_1Cg8Yw9Lxb7Gem8kwDTnfYQ9gQCqlCiMdZiW9ntKMzNLMm0kHjMkApGJ_G_8J3kpb4JIUnM7rI.xOLROSi4WqVxWqWfRoJRiV4vtEoZy2mCIRE.jkk8GH5YjPu11OFhomsmywH7M_otSRDSUl4eKEX_XJsyn5zbwSwJBLmMMNtUQHQeU_JcGrX6NW9D.gHnVZdVQ1ax4zUAbv4Rj7U5lAMFbfDGtFCjapkfbkn0QXdnM2JKKRRr3OX9tdXRGly1ZedXk8mTNO1917.8_XvspeQ3wEhuouIukv2kbTM93e1YBJo4kyA5b4WBg8yvH4o3X856uqRPe2oqOFPCApWlzAZsUWppW9rhNrKYqZtA_BaXsF67.grPnvrf4g.DfcLeRTajscOzPC_3NuYmXc.BLuZvOBuOPboxqB5A1KCXeDuL35FaZjxZO9wOFmGZeXBStPVnd6B3f8a8zCZtijm7ZMlhUQ5n5omYwm3DTt4SCcJRfh6DAWqS1j0- Received: from [203.165.91.75] by web101706.mail.ssk.yahoo.co.jp via HTTP; Wed, 14 Mar 2018 16:35:33 JST X-Mailer: YahooMailWebService/0.8.111_74 X-YMail-JAS: PtU1Ya4VM1nQ9iswvv15zLhfCGJTjfEBqPaFjcc7BwGuTvYG_rNmABtV4ZStdp79ihz.0nfVUf29jun1.DN7IuexbvXcVRl54yF0u0KSsijFcmrjSsf.6G2gOu_431aWHhqY References: Date: Wed, 14 Mar 2018 16:35:33 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Re: GSOC 2018 ARM Cortex Processor To: Michael Zhilin , Vishal Gupta Cc: "freebsd-arm@freebsd.org" , "freebsd-embedded@freebsd.org" , "freebsd-mips@freebsd.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 07:38:07 -0000 Hi=0A=0ARealtek is very strange company.=0A=0ARTL8197D -- Lexra base=0ARTL8= 197F -- MIPS 24K base=0A=0AI think we must not support Lexra type soc.=0ABe= cause of that instruction is very old.=0A=0ABut Realtek make new MIPS 24K b= ase soc.=0AThat support is good.=0A=0ARegards=0A=0AHiroki Mori=0A=0A=0A----= - Original Message -----=0A> From: Michael Zhilin =0A> To= : Vishal Gupta =0A> Cc: "freebsd-arm@freebsd.org= " ; "freebsd-embedded@freebsd.org" ; freebsd-mips@freebsd.org=0A> Date: 2018/3/14, Wed 15:39=0A= > Subject: Re: GSOC 2018 ARM Cortex Processor=0A> =0A> Added freebsd-mips@= =0A> =0A> Regarding MIPS, I would like to see support for retail Realtek MI= PS chips=0A> for instance (RTL8196, RTL8197). There are new brand router mo= dels:=0A> https://wikidevi.com/wiki/Tenda_AC6_V2 or=0A> https://wikidevi.co= m/wiki/Realtek#bgn_2=0A> =0A> Thanks!=0A> =0A> On Tue, Mar 13, 2018 at 4:49= PM, Vishal Gupta =0A> wrote:=0A> =0A>> Thank y= ou for the reply.=0A>> Which new processor would you suggest between Power= PC, ARM, and MIPS=0A>> which i can port during the summer period and will = also be useful for the=0A>> community.=0A>> =0A>> Vishal Gupta=0A>> =0A>>= On Tue, Mar 13, 2018 at 11:52 AM, Warner Losh wrote:=0A>= > =0A>>> There's not currently any other FreeBSD port that works on a syst= em=0A>>> without a MMU. The buffer cache assumes that we can fault in page= s as=0A>>> needed based on virtual address access. The TEXT sharing betwee= n =0A> programs=0A>>> assumes we can map the same page into multiple proce= sses. The shared=0A>>> libraries we have assume something similar, and in = some cases copy on =0A> write=0A>>> on top of that (though that's no diffe= rent from a HW perspective =0A> than these=0A>>> first few cases).=0A>>> = =0A>>> So, if you're willing to live without these features, or find some = =0A> other=0A>>> way to accomplish the same sorts of things, a cortex M/R = port would be=0A>>> tricky. Also, FreeBSD's kernel size may present some o= bstacles. =0A> We're=0A>>> optimized for a rich memory environment, so we = trade extra copies of =0A> code=0A>>> to speed up execution of code, which= matches the x86 market, as well as =0A> the=0A>>> high-end of embedded qu= ite well.=0A>>> =0A>>> If you are looking for a BSD to port to these proce= ssors, you might=0A>>> consider looking at what www.retrobsd.org has done = with their 2.11BSD=0A>>> port to the MIPS processor in the PIC32 core with= the MIPS M4K=0A>>> architecture. It runs in as little as 128k of RAM, whi= le FreeBSD these =0A> days=0A>>> needs at least 128MB of RAM without caref= ul tuning...=0A>>> =0A>>> Warner=0A>>> =0A>>> On Tue, Mar 13, 2018 at 12:= 07 AM, Michael Zhilin =0A> =0A>>> wrote:=0A>>> =0A>>>> = Hi,=0A>>>> =0A>>>> Disclaimer: I'm neither ARM expect nor GSoC person.=0A>= >>> =0A>>>> I may be wrong, but FreeBSD (or Linux, doesn't matter) require= s =0A> MMU which=0A>>>> is my tossing in Cortex M/R family of ARM processo= rs. So it's =0A> technically=0A>>>> difficult/impossible to port it on non= -MMU processor.=0A>>>> =0A>>>> Added freebsd-arm@ for wide audience.=0A>>>= > =0A>>>> Thank you!=0A>>>> =0A>>>> =0A>>>> =0A>>>> On Tue, Mar 13, 2018 = at 1:12 PM, Vishal Gupta =0A> >>> >=0A>>>> = wrote:=0A>>>> =0A>>>> > Hi,=0A>>>> > I am interested in working on the pr= oject to port FreeBSD to =0A> ARM=0A>>>> Cortex M=0A>>>> > or R series mi= croprocessor. Some queries related to the =0A> project are :-=0A>>>> > 1) = What are the expected deliverable for the project.=0A>>>> > 2) Where to pu= t my draft proposal for review so that it can be=0A>>>> improved.=0A>>>> = >=0A>>>> > An early reply is awaited.=0A>>>> >=0A>>>> > Thanks and regar= ds,=0A>>>> > Vishal Gupta=0A>>>> > ______________________________________= _________=0A>>>> > freebsd-embedded@freebsd.org mailing list=0A>>>> > htt= ps://lists.freebsd.org/mailman/listinfo/freebsd-embedded=0A>>>> > To unsub= scribe, send any mail to =0A> "freebsd-embedded-unsubscribe@=0A>>>> freebs= d.org=0A>>>> > "=0A>>>> >=0A>>>> _______________________________________= ________=0A>>>> freebsd-embedded@freebsd.org mailing list=0A>>>> https://= lists.freebsd.org/mailman/listinfo/freebsd-embedded=0A>>>> To unsubscribe,= send any mail to =0A> "freebsd-embedded-unsubscribe@=0A>>>> freebsd.org"= =0A>>>> =0A>>> =0A>>> =0A>> =0A> __________________________________________= _____=0A> freebsd-arm@freebsd.org mailing list=0A> https://lists.freebsd.or= g/mailman/listinfo/freebsd-arm=0A> To unsubscribe, send any mail to "freebs= d-arm-unsubscribe@freebsd.org"=0A> From owner-freebsd-arm@freebsd.org Wed Mar 14 15:38:21 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF60FF5984C for ; Wed, 14 Mar 2018 15:38:21 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from mfdf0201.ocn.ad.jp (mfdf0201.ocn.ad.jp [153.128.50.79]) by mx1.freebsd.org (Postfix) with ESMTP id 0D1EF8691C for ; Wed, 14 Mar 2018 15:38:20 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from mogw0904.ocn.ad.jp (mogw0904.ocn.ad.jp [153.149.227.10]) by mfdf0201.ocn.ad.jp (Postfix) with ESMTP id F23C7C27DB6 for ; Thu, 15 Mar 2018 00:04:05 +0900 (JST) Received: from mf-smf-ucb029c2 (mf-smf-ucb029c2.ocn.ad.jp [153.153.66.195]) by mogw0904.ocn.ad.jp (Postfix) with ESMTP id 76F295001E4; Thu, 15 Mar 2018 00:03:59 +0900 (JST) Received: from ntt.pod01.mv-mta-ucb024 ([153.149.142.98]) by mf-smf-ucb029c2 with ESMTP id w7wdePk4soJV6w7wdex2QS; Thu, 15 Mar 2018 00:03:59 +0900 Received: from smtp.ocn.ne.jp ([153.149.227.134]) by ntt.pod01.mv-mta-ucb024 with id Mr3z1x0092ud8JZ01r3zZJ; Wed, 14 Mar 2018 15:03:59 +0000 Received: from localhost (p795042-ipngn200602sizuokaden.shizuoka.ocn.ne.jp [180.9.168.42]) by smtp.ocn.ne.jp (Postfix) with ESMTPA; Thu, 15 Mar 2018 00:03:59 +0900 (JST) Date: Thu, 15 Mar 2018 00:03:27 +0900 (JST) Message-Id: <20180315.000327.244671182493000373.toshi@ruby.ocn.ne.jp> To: freebsd-arm@freebsd.org Subject: Re: PWM of BeagleBone Black on 11.1-RELEASE From: SAITOU Toshihide In-Reply-To: <20180308.220228.985768279546235038.toshi@ruby.ocn.ne.jp> References: <20180308.220228.985768279546235038.toshi@ruby.ocn.ne.jp> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 15:38:22 -0000 On Thu, 08 Mar 2018 22:02:28 +0900 (JST), SAITOU Toshihide wrote: > > How can I setup the PWM of BeagleBone Black? > The driver attached but no signal observed with the > followings. > > $ sysctl dev.am335x_ehrpwm.1.dutyB=50 > $ sysctl dev.am335x_ehrpwm.1.dutyA=50 > $ sysctl dev.am335x_ehrpwm.1.period=100 > > (nothing was observed) > > $ uname -a > FreeBSD beaglebone 11.1-RELEASE FreeBSD 11.1-RELEASE #0 > r321309: Fri Jul 21 10:22:32 UTC 2017 > root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE > arm > > # dtc -I dts -O dtb pwm.dts -o pwm.dtb > # cp pwm.dtb /boot/dtb/ > > # cat /boot/loader.conf > > fdt_overlays="pwm.dtb" > > # cat pwm.dts > > /dts-v1/; > /plugin/; > > / { > compatible = "ti,beaglebone", "ti,beaglebone-black", > "ti,beaglebone-green"; > > fragment@4 { > target = <&am33xx_pinmux>; > __overlay__ { > pinctrl-single,pins = < 0x048 0xe >; /* P9.21, > gpio0_3 */ > }; > }; > > fragment@5 { > target = <&epwmss1>; > __overlay__ { > status = "okay"; > }; > }; > > fragment@6 { > target = <&ehrpwm1>; > __overlay__ { > status = "okay"; > }; > }; > > fragment@7 { > target = <&ecap1>; > __overlay__ { > status = "okay"; > }; > }; > }; It worked with this settings (althought I don't understand yet): Edit the beaglebone-black.dts as follows: add followings to the &am33xx_pinmux entry: ehrpwm0_pins: pinmux_ehrpwm0_AB { }; ehrpwm1_pins: pinmux_ehrpwm1_AB { }; append the followings: &ehrpwm0 { pinctrl-names = "default"; pinctrl-0 = <&ehrpwm0_pins>; status = "okay"; }; &ehrpwm1 { pinctrl-names = "default"; pinctrl-0 = <&ehrpwm1_pins>; status = "okay"; }; And pwm.dts is : /dts-v1/; /plugin/; / { compatible = "ti,beaglebone", "ti,beaglebone-black", "ti,beaglebone-green"; fragment@0 { target = <&am33xx_pinmux>; __overlay__ { ehrpwm0_pins: pinmux_ehrpwm0_AB { pinctrl-single,pins = < 0x150 0x03 /* P9.21, 0x150, gpio0.2, mode3 */ 0x154 0x03 /* P9.22, 0x154, gpio0.3, mode3 */ >; }; }; }; fragment@1 { target = <&epwmss0>; __overlay__ { status = "okay"; }; }; fragment@2 { target = <&ehrpwm0>; __overlay__ { status = "okay"; }; }; fragment@3 { target = <&am33xx_pinmux>; __overlay__ { ehrpwm1_pins: pinmux_ehrpwm1_AB { pinctrl-single,pins = < 0x48 0x06 /* P9.14, 0x48, gpio1.18, mode6 */ 0x4c 0x06 /* P9.16, 0x4c, gpio1.19, mode6 */ >; }; }; }; fragment@4 { target = <&epwmss1>; __overlay__ { status = "okay"; }; }; fragment@5 { target = <&ehrpwm1>; __overlay__ { status = "okay"; }; }; }; I'm sorry for the noise. -- SAITOU Toshihide From owner-freebsd-arm@freebsd.org Thu Mar 15 14:00:19 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA164F54304; Thu, 15 Mar 2018 14:00:19 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 56890825BD; Thu, 15 Mar 2018 14:00:19 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x232.google.com with SMTP id l12so8670562ioc.10; Thu, 15 Mar 2018 07:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=pobxxFfI8LPErMtrBi+Ora961YfIrHjvKf5PYgoh6mw=; b=XWtAtws+fLo4h38Z/fB79Q/TRHopSCnmuyquoxibR51HfyXaCjQKI+37M5v3LRbb1+ 6paA0RLG5bs+gcTgLigNpaeaSwmp9Nyi/Uo7QRQMzZLwuGo9AWSxHLQ7YkKfoZXofpty IehrSKd/Yso+LF0iuyszj5xP8rWYyvNbt5HY4z6WNogvO3FUFFYdS62iCVi/LaRc47vs BsRAIQ1u8k6+3u/d4RGjya310tJvcDZdXZwKWwAelWf5Gt0dNwF07U4HzkiBnRP2pSfi JyUfdcSUhueRnM+DjrOefqVw/iPWwj+ae5yJLZpa4+2UglmeFh/Qn9XW260dqheqitlv Ru8w== 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=pobxxFfI8LPErMtrBi+Ora961YfIrHjvKf5PYgoh6mw=; b=Xidk7aqlx3WKeoLveIXFSEvu1jFxBGB+mbidFNNJy1bSS1SCY4A6mKAM92+DGphfWB aEdetbrdYT5fzMy36I23WudmKyiEw4Dt0F0dWTvfwnZa2TR95j9HKNGjjJihq5r5SeCy djDXrEuRFkUgMbhrzxekoGHtcX1uF/jZD47EY/InLfEYfgn7Pj5pUbXyi4Br/FOiqI5Z PiEEiZlNZStWtpVUmSVycXMBI9kXNXW9UeiST0zixKYl7x5mHtyZplFv/rDSxs+2AijK ciR0FvB4m/CTigQmZqNKMWzPDe+1dC16U/VX5i/JxnKj2+lQcki5SkTgk/BBzMh+9rfl l7Fg== X-Gm-Message-State: AElRT7EYYAD2wJ7wNHUfzF4bpfpQl7YbWTkesqp/35oCj3RpeOY017EK TRQ9bLz6ckZ/Os/+M6uggMqc0kBkgoHlLCJWAvw= X-Google-Smtp-Source: AG47ELt2Mmbz2DuC1aJRtu4DNUfF2Dc+1/xZWqEfzhSI3+pdGOaf56oBk4nqFLQ/Mc+c6BrDnK29s3TyG/lrkkjTIJ0= X-Received: by 10.107.20.131 with SMTP id 125mr9340082iou.239.1521122418696; Thu, 15 Mar 2018 07:00:18 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.163.13 with HTTP; Thu, 15 Mar 2018 06:59:58 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Thu, 15 Mar 2018 09:59:58 -0400 X-Google-Sender-Auth: aJM0-WqgYVGLuv0N2i3BTc43IoI Message-ID: Subject: Re: Migrating arm(v7) to LLD_BOOTSTRAP To: meloun.michal@gmail.com Cc: Warner Losh , "freebsd-arm@freebsd.org" , "freebsd-toolchain@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 14:00:20 -0000 On 17 January 2018 at 00:35, Michal Meloun wrote: > >>> ld: error: lld may use movt/movw, no object with architecture >>> supporting feature detected. > > But this means that we can not use lld for kernel module linking. > (assuming that lld can emits movt/movw with attached relocation). Right now for pre-v7 lld exits with the "may use" before attempting to link, with no indication of whether movt/movw would actually be used. It seems in practice linking armv7 with lld does not use movt/movw. From owner-freebsd-arm@freebsd.org Fri Mar 16 02:22:40 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B0FEF41944; Fri, 16 Mar 2018 02:22:40 +0000 (UTC) (envelope-from thedarshansharma@gmail.com) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 26DF385E76; Fri, 16 Mar 2018 02:22:40 +0000 (UTC) (envelope-from thedarshansharma@gmail.com) Received: by mail-qk0-x22d.google.com with SMTP id b198so9565268qkg.9; Thu, 15 Mar 2018 19:22:40 -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:cc; bh=DXCxemrvN3S7XdTr/koI5X1A9NXeR2xhx5VK7k298I8=; b=HMJa0rhz6xC0FmMNj0tZaLz1aRLKOB0Y32VCLeevlhS5Ru0gPp18lxvrEttsDRNZXx p0uw+dL8ORsQvYvxwYCWoEPWCoaagK7yy6UH0BSntqBO6sXKK53mGQuG6KXj8btDGyRr t1x8m08CYKoD24DNI18oyakAQR/WSjzOS75LVLpxSGhmWHp8UdVvfUw77JdfGsG6/+s9 BcN8FYMtOWDrL7fJ4oecKHmfEDZIjrngsHaHIre4sFIDFP6bY46Ee+aJ1qOgvLrPPKOm CdfKk2GwoJTzlIyfxZjLOBiIlvRlfmsEEC12hYJUWDtygDuwzqshpnrLD2PwaumDQJx2 jjOQ== 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:cc; bh=DXCxemrvN3S7XdTr/koI5X1A9NXeR2xhx5VK7k298I8=; b=rf2eOh2S52szR9k7vPZonfxRGRevFGrARID/A7flGJLu2GrRJCzooJI7e9xOyedTBU tCsS/MQV8H/AcxbEWW7HVyiK+F+1pN+OZl16QWrA2vmoVFEoRFaO/l6RN93Zlbu3cEM3 LBGPZm47c/kF7fiJiXSS8EruJilS5U9IW9fv++42x98R+ken2NGql6QHUtZSxlOQ9Snr uomvSZVvCEdCGbYV+0qLBTRMNSbs8su4zIufW7knPH/p+b2C0VNlBhRvDA19kFj/ODgy 2z3xfLKPYDix7Q/QHv/VyUds8Qr49yR47jXyfLn9jRIwgIqSesbcl6W4VTaj2o0FdU3C l+8g== X-Gm-Message-State: AElRT7FL1hKs/w1Oy9u1TPhVm8b4RWw7CqdOGy8gHYpYB2WzbOnPqMNM WUDtutyBR3G3pMUV8BawmPbBnKucA/5vUaCMDCUqyQGC+Pg= X-Google-Smtp-Source: AG47ELvdAUGr9os8Gy1GCFgvQOQooiEu2bvMsdaKIZcfA9nmzbSXSfnaVvIv4Vji7yIAhdbjrsuS5ozcQxeBLg4IE/4= X-Received: by 10.55.24.214 with SMTP id 83mr144635qky.267.1521166959433; Thu, 15 Mar 2018 19:22:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.181.226 with HTTP; Thu, 15 Mar 2018 19:22:39 -0700 (PDT) From: Darshan Sharma Date: Fri, 16 Mar 2018 07:52:39 +0530 Message-ID: Subject: GSoC idea: Improve support for an embedded CPU/board To: freebsd-arm@freebsd.org Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 02:22:40 -0000 Hello, I am Darshan Sharma a CSE student from Panjab University, India. I like the idea of - Improve support for an embedded CPU/board . I will choose an arm based board for this because that is more easily available in our country. Though I have not selected any specific board yet but soon will. I have used Gentoo before so I am already familiar with kernel programming. I will be happy to learn new things which will stand in my way and I am sure enough that I can complete the project in the given time. Is there anyone who is willing to mentor this project? I will discuss this more with you. My GitHub Profile - https://github.com/darshansharma My Linkedin Profile - https://www.linkedin.com/in/darshansharmain/ Thanks & Regards, Darshan Sharma From owner-freebsd-arm@freebsd.org Fri Mar 16 11:10:51 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54A49F31C67 for ; Fri, 16 Mar 2018 11:10:51 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (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 E96F57902B for ; Fri, 16 Mar 2018 11:10:50 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) X-Originating-IP: 193.54.192.15 Received: from dmc12.centralesupelec.fr (unknown [193.54.192.15]) (Authenticated sender: ganael.laplanche@martymac.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 865C11C0029 for ; Fri, 16 Mar 2018 12:10:41 +0100 (CET) From: Ganael Laplanche To: freebsd-arm@freebsd.org Subject: FreeBSD on Planetcom's Gemini PDA ? Date: Fri, 16 Mar 2018 12:10:34 +0100 Message-ID: <19257002.U5ZEKZfeh6@dmc12.centralesupelec.fr> User-Agent: KMail/4.14.10 (FreeBSD/11.1-RELEASE-p7; KDE/4.14.38; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 11:10:51 -0000 Hi, Is someone working on a FreeBSD port to new Planetcom's Gemini PDA ? (https://www.planetcom.co.uk/) The device uses a MediaTek Helio X27 (X25 for 1st batch devices) SOC which embeds clusters of ARM-A72 and ARM-A53 CPUs. Detailed specs are here : https://www.mediatek.com/products/smartphones/mt6797x-helio-x27 Would that be easy to port FreeBSD to that device ? -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org From owner-freebsd-arm@freebsd.org Fri Mar 16 21:40:45 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E222BF4FD07 for ; Fri, 16 Mar 2018 21:40:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 7580276476 for ; Fri, 16 Mar 2018 21:40:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x22c.google.com with SMTP id v194-v6so3795888itb.0 for ; Fri, 16 Mar 2018 14:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=C/bR3b6BcAbCv/jIxuyby8GFvG3RQPQjjaUf6AkmRL4=; b=lvS4+IE5U/PAqDuiljDsxLpzpZxRdxDK7XwCaklckQ0s6KrVyg3Qt1+gQQkT3KFSi7 dpgo4qPvQ53NwIq0RlBKnhV1vjwgFPf5NgLf2LLNlRHRv48rjgJd1TrSPpmrxS3a5LmQ aA+9yTjK4wU0TfO2W6PMAVwq72UHDKsg51Z9OJ7QMBxY0atxo9XaIvfkrMOAV+UnRSxL uSTM9Ep+yDHxDMrijGyD/QJSVa+MOzPwQ9EBsQFonhmIXaoZ1FjS7UPzb/f9LdKfdg+8 uidI6PTMJ4xdk68hKjDmyCu8doWrUfuKQVscEbfCLs0pXA5yDG/dZlN7lo5QUJqEvHh/ /fUQ== 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:from:date:message-id:subject :to; bh=C/bR3b6BcAbCv/jIxuyby8GFvG3RQPQjjaUf6AkmRL4=; b=cRhmlggGpMvlfTF4/Ic9b7GwqOUUGJnEBayy3WmFd1jnWgPjYvgeerkX1BTCznIvcN a8pZT7IEoYfiM/7DvYQbJw91pEsOQW8qcphDs164DQRyTh1k9Gm8DfUeH3FttWsRdPmE EyzMhe7fcUgh1ds1UAudxtZbPxQehzk9yB1OakwF2UX6ypFpujwhO60kmwsVffnfAq7/ c64mdu1K2X364O6r6bbJS8O5IruMq+/qRpnlklAQQw1ntrzyqR4M3VCZ3sKqYBWYrigH hq7HhDsYYlK2WgB1wc8LtHz7HyB6rvWjf8OYWWFT1Op4TCpdqsXm9fDMx+d2zuS20sH8 XSTw== X-Gm-Message-State: AElRT7EiONcxTFnJxDxF8dHSzHRYLyRmO3qSyFgrJAD7RZ4TAyFvPCv0 sNf7oGIzRhj4Zoo1G7wXpmdUqixt3Aha4bGbQxuKC/od X-Google-Smtp-Source: AG47ELsvhwHFNVGEX29fZOA0lL03mCvfb+Gxh7ZYFSQjK6X3tv8KinKtz2lJo7YkNcVg3mWOPahlLACcBLLIb4J1GpI= X-Received: by 2002:a24:af45:: with SMTP id l5-v6mr3779908iti.52.1521236443587; Fri, 16 Mar 2018 14:40:43 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.163.13 with HTTP; Fri, 16 Mar 2018 14:40:22 -0700 (PDT) From: Ed Maste Date: Fri, 16 Mar 2018 17:40:22 -0400 X-Google-Sender-Auth: I8PB3absFFXWb8xNtfhE6uKKkJs Message-ID: Subject: Magic incantation for Pine64 UEFI/PXE boot To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 21:40:45 -0000 This seems to be somewhat under-documented, so for anyone else trying to PXE boot a Pine64: after some trial and error I found "dhcp" followed by "bootefi ${fileaddr} ${fdtcontroladdr}" works. I used the most recent FreeBSD SD-card image (to provide U-boot), and used standard configuration on the PXE boot host. => dhcp BOOTP broadcast 1 DHCP client bound to address 10.0.0.101 (4 ms) Using ethernet@01c30000 device TFTP from server 10.0.0.1; our IP address is 10.0.0.101 Filename 'arm64/boot/loader.efi'. Load address: 0x42000000 Loading: *^H#################################### 840.8 KiB/s done Bytes transferred = 517120 (7e400 hex) => bootefi ${fileaddr} ${fdtcontroladdr} ## Starting EFI application at 42000000 ... ... From owner-freebsd-arm@freebsd.org Sat Mar 17 00:54:47 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D7B4F5BB6A for ; Sat, 17 Mar 2018 00:54:47 +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 503AE7D0BE; Sat, 17 Mar 2018 00:54:45 +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 06f340ec; Sat, 17 Mar 2018 01:54:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mail; bh= ZoSQmRReOA9KifFAcM/+AttC2sA=; b=In6+Bdi2UPaz5pLv1IhBR4Ar+AdyZUxe ECrGAJJKXPsV1iJ4M7cq7UnvU9oOSatOYQ8iSz+WgSDbDGYRdsq655wq4/6ImAFB vDMZwGNsZTVzbJBZ4tZtztk1wV4O5oYBPNAO4sPB0UpOOJe8VYNPHalkaMaNq624 qAopLALXL30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= mail; b=o3hnjkda7Ka3Q6JYeZetsVdSgmGqOgrai9UmTnRXNdbECeCaMstCkMQc UGdINiqo9/1fq6NalsepShNkGFsL0Ov+naeDhWQB89YHbXInEMP3hLfhedMeCEoJ k5Q4OcFTGBtuX12K5TfR0cqrd7x0Il5bIaIplP3mbHKGwE35Yb8= Received: from [192.168.128.100] (ai126173013235.46.access-internet.ne.jp [126.173.13.235]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 7bc740bc TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sat, 17 Mar 2018 01:54:37 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Magic incantation for Pine64 UEFI/PXE boot From: Emmanuel Vadot X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Sat, 17 Mar 2018 09:54:31 +0900 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ed Maste X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 00:54:47 -0000 =46rom U-Boot prompt : setenv boot_targets dhcp (saveenv) boot And if you don=E2=80=99t have anything bootable on the sdcard u-boot will tr= y sd, usb then dhcp iirc --=20 Emmanuel Vadot > Le 17 mars 2018 =C3=A0 06:40, Ed Maste a =C3=A9crit := >=20 > This seems to be somewhat under-documented, so for anyone else trying > to PXE boot a Pine64: after some trial and error I found "dhcp" > followed by "bootefi ${fileaddr} ${fdtcontroladdr}" works. >=20 > I used the most recent FreeBSD SD-card image (to provide U-boot), and > used standard configuration on the PXE boot host. >=20 > =3D> dhcp > BOOTP broadcast 1 > DHCP client bound to address 10.0.0.101 (4 ms) > Using ethernet@01c30000 device > TFTP from server 10.0.0.1; our IP address is 10.0.0.101 > Filename 'arm64/boot/loader.efi'. > Load address: 0x42000000 > Loading: *^H#################################### > 840.8 KiB/s > done > Bytes transferred =3D 517120 (7e400 hex) > =3D> bootefi ${fileaddr} ${fdtcontroladdr} > ## Starting EFI application at 42000000 ... > ... > _______________________________________________ > 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 Mar 17 06:54:53 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 465A6F4B596 for ; Sat, 17 Mar 2018 06:54:53 +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 A1FAA6ADEB; Sat, 17 Mar 2018 06:54:52 +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 be83e466; Sat, 17 Mar 2018 07:54:49 +0100 (CET) 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=XWShZehpHKkuxLObtUkjY3JxJsQ=; b=KFPGCSCBsWjRncNyEzefUSRFQCU2 H5Tweuzt+Ts03hzQZbekBIZrGKH29ZP0dJJi0fgKije+wZKrj6be2kAtRmJZVzgj 6jMGWoqMGbaNfBgGbCeYDUh9wD8BNT5CqlIQzci68afYFVwBqL0b9Q8NTxjgl5rY HQ8I6KBPY5zcfgI= 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=mKbYUuqcCqjFZ+I+JOdOAD8Qtz3tUFhGKd4SaO2nZce2AaEB78sMd14+ lu2naeKWksNXYWEW1TzmngtIRLuoyhOfikWcQIB5PQFQZnvPNHtA4gAr9y4nNPG0 WMtOZEk09mAXt6/t7SwMEjS+2+PV+vSVx1yLCB2qd7Jf02+4xpQ= Received: from arcadia (ai126173013235.46.access-internet.ne.jp [126.173.13.235]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 584eaedd TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sat, 17 Mar 2018 07:54:49 +0100 (CET) Date: Sat, 17 Mar 2018 07:54:42 +0100 From: Emmanuel Vadot To: Ed Maste Cc: freebsd-arm Subject: Re: Magic incantation for Pine64 UEFI/PXE boot Message-Id: <20180317075442.5e6b545f85e71e10f1a81083@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.7.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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 06:54:53 -0000 On Fri, 16 Mar 2018 17:40:22 -0400 Ed Maste wrote: > This seems to be somewhat under-documented, so for anyone else trying > to PXE boot a Pine64: after some trial and error I found "dhcp" > followed by "bootefi ${fileaddr} ${fdtcontroladdr}" works. > > I used the most recent FreeBSD SD-card image (to provide U-boot), and > used standard configuration on the PXE boot host. > > => dhcp > BOOTP broadcast 1 > DHCP client bound to address 10.0.0.101 (4 ms) > Using ethernet@01c30000 device > TFTP from server 10.0.0.1; our IP address is 10.0.0.101 > Filename 'arm64/boot/loader.efi'. > Load address: 0x42000000 > Loading: *^H#################################### > 840.8 KiB/s > done > Bytes transferred = 517120 (7e400 hex) > => bootefi ${fileaddr} ${fdtcontroladdr} > ## Starting EFI application at 42000000 ... > ... (Better answer now that I have a real keyboard) U-Boot is compiled with distroboot_cmd stuff. This mean that it will take the values present in the boot_targets variable (defaults to mmc0 mmc1 (if present) usb dhcp) and for each targets will do the following : - Check if a uboot.scr (u-boot script) exists and load/execute it, this will be the default for armv6/armv7 after I update u-boot to 2018.01 (or .03 since it's out now) - Check if a extlinux.conf or extlinux/extlinux.conf file exists and load/execute it (I wanted to use that as you can make menu with it but since we are not using an ELF binary for ubldr it makes things harder. - Check is efi/boot/boot.efi exist (in case of an local storage boot) or if the file provided by tftp is an efi executable. In that case u-boot will always use a DTB. The default DTB is loaded and available in $fdtcontroladdr, if the file set by the variable $fdtfile exist this will override it (usefull for testing newer dtb etc ...) but a user should always use the u-boot provided dtb. What you've done work but u-boot will do that (and more) for you without intervention. P.S.: I don't remember if the order I gave is the right one, I only remember that efi is done last. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sat Mar 17 10:20:55 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A1A3F5A104 for ; Sat, 17 Mar 2018 10:20:55 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8DDE73237 for ; Sat, 17 Mar 2018 10:20:54 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from dhcp-10-248-110-205.eduroam.wireless.private.cam.ac.uk (global-5-142.nat-2.net.cam.ac.uk [131.111.5.142]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 94EA3721E281E for ; Sat, 17 Mar 2018 11:20:51 +0100 (CET) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: arm64 panics on boot on a RPi3 Message-Id: <7D7EAF74-95E3-4B48-BC57-C3CE4D13501B@freebsd.org> Date: Sat, 17 Mar 2018 10:20:50 +0000 To: freebsd-arm X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 10:20:55 -0000 Dear all, FreeBSD head of today panics when booting the arm64 code on a RPi3: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: UFS Probing 3 block devices.....* done UFS found 1 partition Consoles: EFI console =20 Command line arguments: loader.efi Image base: 0x39ab8008 EFI version: 2.05 EFI Firmware: Das U-boot (rev 0.00) FreeBSD/arm64 EFI loader, Revision 1.1 (Wed Dec 6 19:13:14 CET 2017 root@bsd18.fh-muenster.de) EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x8482a0 data=3D0x137018+0x71f83c = syms=3D[0x8+0x1148a0+0x8+0x106675] /boot/entropy size=3D0x1000 /boot/kernel/geom_label.ko text=3D0x2b40 text=3D0x2610 = data=3D0x10120+0xfee4 syms=3D[0x8+0x15a8+0x8+0xf73] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB provided by EFI at 0x8004000. KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2018 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 #65 r331093: Sat Mar 17 11:05:06 CET 2018 = tuexen@bsd10.fh-muenster.de:/usr/home/tuexen/head/sys/arm64/compile/TCP = arm64 FreeBSD clang version 5.0.1 (branches/release_50 319231) (based on LLVM = 5.0.1) VT: init without driver. sysctl_warn_reuse: can't re-use a leaf (kern.features.geom_label)! module_register: cannot register g_label from kernel; already loaded = from geom_label.ko Module g_label failed to register: 17 Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. MAP 39b1b000 mode 2 pages 1 MAP 3af86000 mode 2 pages 2 MAP 3f100000 mode 1 pages 1 random: entropy device external interface kbd0 at kbdmux0 ofwbus0: simplebus0: on ofwbus0 ofw_clkbus0: on ofwbus0 clk_fixed0: on ofw_clkbus0 clk_fixed1: on ofw_clkbus0 regfix0: on ofwbus0 regfix1: on ofwbus0 psci0: on ofwbus0 local_intc0: mem 0x40000000-0x400000ff on = simplebus0 intc0: mem 0x7e00b200-0x7e00b3ff irq 16 = on simplebus0 generic_timer0: irq 47,48,49,50 on simplebus0 Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000 x0: ffff0000000109e0 x1: ffff0000000109b0 x2: 4 x3: ffff00000043e638 x4: ffff00000076eb28 x5: 110 x6: ffff000000010808 x7: ffff000000010638 x8: 3af61fd0 x9: 0 x10: ffff000000993f20 x11: 0 x12: ffff0000003b3ab4 x13: ffff00000043e2f0 x14: a x15: 0 x16: 7 x17: ffff00000043e2f0 x18: ffff0000000109b0 x19: ffff0000000109e0 x20: ffff000000993000 x21: ffff000000b89000 x22: fffffd00012d9070 x23: 0 x24: fffffd00011c1d00 x25: fffffd00011c1c80 x26: fffffd00011c1cd8 x27: 0 x28: fffffd00011d0080 x29: ffff0000000109d0 sp: ffff0000000109b0 lr: ffff0000000fee88 elr: 3af61fd0 spsr: a00001c5 far: 3af61fd0 esr: 86000007 panic: data abort in critical section or under mutex cpuid =3D 0 time =3D 1 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff00000066ead0 lr =3D 0xffff0000000ba870 sp =3D 0xffff0000000103a0 fp =3D 0xffff0000000105b0 db_trace_self_wrapper() at vpanic+0x19c pc =3D 0xffff0000000ba870 lr =3D 0xffff000000362fb0 sp =3D 0xffff0000000105c0 fp =3D 0xffff000000010670 vpanic() at panic+0x44 pc =3D 0xffff000000362fb0 lr =3D 0xffff000000362e10 sp =3D 0xffff000000010680 fp =3D 0xffff000000010700 panic() at data_abort+0x21c pc =3D 0xffff000000362e10 lr =3D 0xffff0000006868b8 sp =3D 0xffff000000010710 fp =3D 0xffff0000000107c0 data_abort() at do_el1h_sync+0x11c pc =3D 0xffff0000006868b8 lr =3D 0xffff000000686598 sp =3D 0xffff0000000107d0 fp =3D 0xffff000000010800 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff000000686598 lr =3D 0xffff000000671074 sp =3D 0xffff000000010810 fp =3D 0xffff000000010920 handle_el1h_sync() at efi_get_time+0x38 pc =3D 0xffff000000671074 lr =3D 0xffff0000000fee84 sp =3D 0xffff000000010930 fp =3D 0xffff0000000109d0 efi_get_time() at efirtc_probe+0x18 pc =3D 0xffff0000000fee84 lr =3D 0xffff0000000ff5b8 sp =3D 0xffff0000000109e0 fp =3D 0xffff000000010a00 efirtc_probe() at device_probe_child+0x150 pc =3D 0xffff0000000ff5b8 lr =3D 0xffff000000397c1c sp =3D 0xffff000000010a10 fp =3D 0xffff000000010a70 device_probe_child() at device_probe+0x88 pc =3D 0xffff000000397c1c lr =3D 0xffff0000003988ac sp =3D 0xffff000000010a80 fp =3D 0xffff000000010aa0 device_probe() at bus_generic_new_pass+0xec pc =3D 0xffff0000003988ac lr =3D 0xffff00000039a78c sp =3D 0xffff000000010ab0 fp =3D 0xffff000000010ae0 bus_generic_new_pass() at bus_generic_new_pass+0xd0 pc =3D 0xffff00000039a78c lr =3D 0xffff00000039a770 sp =3D 0xffff000000010af0 fp =3D 0xffff000000010b20 bus_generic_new_pass() at root_bus_configure+0x78 pc =3D 0xffff00000039a770 lr =3D 0xffff00000039c700 sp =3D 0xffff000000010b30 fp =3D 0xffff000000010b60 root_bus_configure() at mi_startup+0xc8 pc =3D 0xffff00000039c700 lr =3D 0xffff0000002fbbcc sp =3D 0xffff000000010b70 fp =3D 0xffff000000010bb0 mi_startup() at virtdone+0x54 pc =3D 0xffff0000002fbbcc lr =3D 0xffff000000001084 sp =3D 0xffff000000010bc0 fp =3D 0x0000000000000000 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at 0x3af61fd0:KDB: reentering KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff00000066ead0 lr =3D 0xffff0000000ba870 sp =3D 0xffff00000000f990 fp =3D 0xffff00000000fba0 db_trace_self_wrapper() at kdb_reenter+0x38 pc =3D 0xffff0000000ba870 lr =3D 0xffff0000003a778c sp =3D 0xffff00000000fbb0 fp =3D 0xffff00000000fbc0 kdb_reenter() at do_el1h_sync+0x11c pc =3D 0xffff0000003a778c lr =3D 0xffff000000686598 sp =3D 0xffff00000000fbd0 fp =3D 0xffff00000000fc00 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff000000686598 lr =3D 0xffff000000671074 sp =3D 0xffff00000000fc10 fp =3D 0xffff00000000fd20 handle_el1h_sync() at db_read_bytes+0x34 pc =3D 0xffff000000671074 lr =3D 0xffff00000066e878 sp =3D 0xffff00000000fd30 fp =3D 0xffff00000000ffe0 db_read_bytes() at db_get_value+0x38 pc =3D 0xffff00000066e878 lr =3D 0xffff0000000b69fc sp =3D 0xffff00000000fff0 fp =3D 0xffff000000010020 db_get_value() at db_disasm_read_word+0x10 pc =3D 0xffff0000000b69fc lr =3D 0xffff00000066e7f4 sp =3D 0xffff000000010030 fp =3D 0xffff000000010030 db_disasm_read_word() at disasm+0x40 pc =3D 0xffff00000066e7f4 lr =3D 0xffff00000066f6a0 sp =3D 0xffff000000010040 fp =3D 0xffff0000000100a0 disasm() at db_print_loc_and_inst+0x40 pc =3D 0xffff00000066f6a0 lr =3D 0xffff0000000b8adc sp =3D 0xffff0000000100b0 fp =3D 0xffff0000000100c0 db_print_loc_and_inst() at db_trap+0xd4 pc =3D 0xffff0000000b8adc lr =3D 0xffff0000000ba9b8 sp =3D 0xffff0000000100d0 fp =3D 0xffff0000000102f0 db_trap() at kdb_trap+0x1c8 pc =3D 0xffff0000000ba9b8 lr =3D 0xffff0000003a7bdc sp =3D 0xffff000000010300 fp =3D 0xffff0000000103b0 kdb_trap() at do_el1h_sync+0xf0 pc =3D 0xffff0000003a7bdc lr =3D 0xffff00000068656c sp =3D 0xffff0000000103c0 fp =3D 0xffff0000000103f0 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff00000068656c lr =3D 0xffff000000671074 sp =3D 0xffff000000010400 fp =3D 0xffff000000010510 handle_el1h_sync() at kdb_enter+0x34 pc =3D 0xffff000000671074 lr =3D 0xffff0000003a7280 sp =3D 0xffff000000010520 fp =3D 0xffff0000000105b0 kdb_enter() at vpanic+0x1b8 pc =3D 0xffff0000003a7280 lr =3D 0xffff000000362fcc sp =3D 0xffff0000000105c0 fp =3D 0xffff000000010670 vpanic() at panic+0x44 pc =3D 0xffff000000362fcc lr =3D 0xffff000000362e10 sp =3D 0xffff000000010680 fp =3D 0xffff000000010700 panic() at data_abort+0x21c pc =3D 0xffff000000362e10 lr =3D 0xffff0000006868b8 sp =3D 0xffff000000010710 fp =3D 0xffff0000000107c0 data_abort() at do_el1h_sync+0x11c pc =3D 0xffff0000006868b8 lr =3D 0xffff000000686598 sp =3D 0xffff0000000107d0 fp =3D 0xffff000000010800 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff000000686598 lr =3D 0xffff000000671074 sp =3D 0xffff000000010810 fp =3D 0xffff000000010920 handle_el1h_sync() at efi_get_time+0x38 pc =3D 0xffff000000671074 lr =3D 0xffff0000000fee84 sp =3D 0xffff000000010930 fp =3D 0xffff0000000109d0 efi_get_time() at efirtc_probe+0x18 pc =3D 0xffff0000000fee84 lr =3D 0xffff0000000ff5b8 sp =3D 0xffff0000000109e0 fp =3D 0xffff000000010a00 efirtc_probe() at device_probe_child+0x150 pc =3D 0xffff0000000ff5b8 lr =3D 0xffff000000397c1c sp =3D 0xffff000000010a10 fp =3D 0xffff000000010a70 device_probe_child() at device_probe+0x88 pc =3D 0xffff000000397c1c lr =3D 0xffff0000003988ac sp =3D 0xffff000000010a80 fp =3D 0xffff000000010aa0 device_probe() at bus_generic_new_pass+0xec pc =3D 0xffff0000003988ac lr =3D 0xffff00000039a78c sp =3D 0xffff000000010ab0 fp =3D 0xffff000000010ae0 bus_generic_new_pass() at bus_generic_new_pass+0xd0 pc =3D 0xffff00000039a78c lr =3D 0xffff00000039a770 sp =3D 0xffff000000010af0 fp =3D 0xffff000000010b20 bus_generic_new_pass() at root_bus_configure+0x78 pc =3D 0xffff00000039a770 lr =3D 0xffff00000039c700 sp =3D 0xffff000000010b30 fp =3D 0xffff000000010b60 root_bus_configure() at mi_startup+0xc8 pc =3D 0xffff00000039c700 lr =3D 0xffff0000002fbbcc sp =3D 0xffff000000010b70 fp =3D 0xffff000000010bb0 mi_startup() at virtdone+0x54 pc =3D 0xffff0000002fbbcc lr =3D 0xffff000000001084 sp =3D 0xffff000000010bc0 fp =3D 0x0000000000000000 *** error reading from address 3af61fd0 *** KDB: reentering KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff00000066ead0 lr =3D 0xffff0000000ba870 sp =3D 0xffff00000000fdb0 fp =3D 0xffff00000000ffc0 db_trace_self_wrapper() at kdb_reenter+0x38 pc =3D 0xffff0000000ba870 lr =3D 0xffff0000003a778c sp =3D 0xffff00000000ffd0 fp =3D 0xffff00000000ffe0 kdb_reenter() at db_get_value+0x50 pc =3D 0xffff0000003a778c lr =3D 0xffff0000000b6a14 sp =3D 0xffff00000000fff0 fp =3D 0xffff000000010020 db_get_value() at db_disasm_read_word+0x10 pc =3D 0xffff0000000b6a14 lr =3D 0xffff00000066e7f4 sp =3D 0xffff000000010030 fp =3D 0xffff000000010030 db_disasm_read_word() at disasm+0x40 pc =3D 0xffff00000066e7f4 lr =3D 0xffff00000066f6a0 sp =3D 0xffff000000010040 fp =3D 0xffff0000000100a0 disasm() at db_print_loc_and_inst+0x40 pc =3D 0xffff00000066f6a0 lr =3D 0xffff0000000b8adc sp =3D 0xffff0000000100b0 fp =3D 0xffff0000000100c0 db_print_loc_and_inst() at db_trap+0xd4 pc =3D 0xffff0000000b8adc lr =3D 0xffff0000000ba9b8 sp =3D 0xffff0000000100d0 fp =3D 0xffff0000000102f0 db_trap() at kdb_trap+0x1c8 pc =3D 0xffff0000000ba9b8 lr =3D 0xffff0000003a7bdc sp =3D 0xffff000000010300 fp =3D 0xffff0000000103b0 kdb_trap() at do_el1h_sync+0xf0 pc =3D 0xffff0000003a7bdc lr =3D 0xffff00000068656c sp =3D 0xffff0000000103c0 fp =3D 0xffff0000000103f0 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff00000068656c lr =3D 0xffff000000671074 sp =3D 0xffff000000010400 fp =3D 0xffff000000010510 handle_el1h_sync() at kdb_enter+0x34 pc =3D 0xffff000000671074 lr =3D 0xffff0000003a7280 sp =3D 0xffff000000010520 fp =3D 0xffff0000000105b0 kdb_enter() at vpanic+0x1b8 pc =3D 0xffff0000003a7280 lr =3D 0xffff000000362fcc sp =3D 0xffff0000000105c0 fp =3D 0xffff000000010670 vpanic() at panic+0x44 pc =3D 0xffff000000362fcc lr =3D 0xffff000000362e10 sp =3D 0xffff000000010680 fp =3D 0xffff000000010700 panic() at data_abort+0x21c pc =3D 0xffff000000362e10 lr =3D 0xffff0000006868b8 sp =3D 0xffff000000010710 fp =3D 0xffff0000000107c0 data_abort() at do_el1h_sync+0x11c pc =3D 0xffff0000006868b8 lr =3D 0xffff000000686598 sp =3D 0xffff0000000107d0 fp =3D 0xffff000000010800 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff000000686598 lr =3D 0xffff000000671074 sp =3D 0xffff000000010810 fp =3D 0xffff000000010920 handle_el1h_sync() at efi_get_time+0x38 pc =3D 0xffff000000671074 lr =3D 0xffff0000000fee84 sp =3D 0xffff000000010930 fp =3D 0xffff0000000109d0 efi_get_time() at efirtc_probe+0x18 pc =3D 0xffff0000000fee84 lr =3D 0xffff0000000ff5b8 sp =3D 0xffff0000000109e0 fp =3D 0xffff000000010a00 efirtc_probe() at device_probe_child+0x150 pc =3D 0xffff0000000ff5b8 lr =3D 0xffff000000397c1c sp =3D 0xffff000000010a10 fp =3D 0xffff000000010a70 device_probe_child() at device_probe+0x88 pc =3D 0xffff000000397c1c lr =3D 0xffff0000003988ac sp =3D 0xffff000000010a80 fp =3D 0xffff000000010aa0 device_probe() at bus_generic_new_pass+0xec pc =3D 0xffff0000003988ac lr =3D 0xffff00000039a78c sp =3D 0xffff000000010ab0 fp =3D 0xffff000000010ae0 bus_generic_new_pass() at bus_generic_new_pass+0xd0 pc =3D 0xffff00000039a78c lr =3D 0xffff00000039a770 sp =3D 0xffff000000010af0 fp =3D 0xffff000000010b20 bus_generic_new_pass() at root_bus_configure+0x78 pc =3D 0xffff00000039a770 lr =3D 0xffff00000039c700 sp =3D 0xffff000000010b30 fp =3D 0xffff000000010b60 root_bus_configure() at mi_startup+0xc8 pc =3D 0xffff00000039c700 lr =3D 0xffff0000002fbbcc sp =3D 0xffff000000010b70 fp =3D 0xffff000000010bb0 mi_startup() at virtdone+0x54 pc =3D 0xffff0000002fbbcc lr =3D 0xffff000000001084 sp =3D 0xffff000000010bc0 fp =3D 0x0000000000000000 db>=20 Any idea what goes wrong? Best regards Michael= From owner-freebsd-arm@freebsd.org Sat Mar 17 11:18:21 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52B06F5E2EC for ; Sat, 17 Mar 2018 11:18:21 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACAFF76551 for ; Sat, 17 Mar 2018 11:18:20 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.179.222.246]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LkTSx-1eMRO40D5X-00cNzC for ; Sat, 17 Mar 2018 12:18:19 +0100 Date: Sat, 17 Mar 2018 12:17:45 +0100 From: "O. Hartmann" To: freebsd-arm@freebsd.org Subject: ROCK64: support for RK3328 A53? Message-ID: <20180317121812.2680c6f5@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/d0x6/+9SHOc3/ef8H6dF1Fx"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:Tj4oZAQTfl8rJMBlbth+tvRNjHGzR0HEn78LS4WlpuUG3z4AJHU ZAxcCL1WGH7fPpWx45HgXeK19LcPimm1EnVGg/wz6J4gBYE0k5tR+ACKNopMFkgGDno848w J8TZ3BLKn67yqMYCd5sZNRP5SUY7bis0XPehLXMXUpjeq8m9Ds4/DeLsA8USnO6Rh4YAEhT 6ljYDvuQu6hHp+nvgFUXg== X-UI-Out-Filterresults: notjunk:1;V01:K0:wkY0klqvfDA=:hminxUqEhVkg0s4Fdcd/uD 05f8KnmkM9cCMucB3RwT+J9A2MOzaShErEzWG4GuKyeh3tMfqu2ORdUY2rnz48nEp7RKE7RoR aJn2jkOUXpVpUcMQXMMqL1b1PluJhM6hXnV78qWjQNDWiDzkFQRricNMzlzAEuP//c3Ri72vL PSz+N3Q5erJIpPRzH+v0MIQ6R/uoBmSIuoQgarAt/TSPUfatPCPAl6dasQEFn9wLK4He1Yi/X 0QOL8EB1gdbJR/gZE/kqY0w3vyshI5Nzzy8PTC/TNVhXohD05bx2aqY+atQSVGEQL63++6dEk u4y+SdfeMMk5IyDtdzYnPPirtBInJc/hCokS59nAJ9mcFKc8A2NoSRndrq2rSDfaQH4P61oN+ SlZL65LtXOfXj2BCyp1DDDuj2Bs4Ea4VkNsokpQAfSEDp0u4fEHcFnDaDMAMiGJgumjnBFwbd bwCcrWjQExYH9Gjz6eS1qWq5UE415FSOF6ddBAzuy4Pi/YY1LeAdF8vvtWpGqY90bpW6r5UJv 89+1Kl/7/yfPuta7xexhLJbxJj/6jWCaJdYPYrd/I16OXrUqeDuCX65tykf+9PhwHT24IswAH k6W4D4d7bqre1R6eSG2DJZhs7yVMTq0aSd9nnedzBK4bm33fMjkf8Koj7LK+aDLv5ZYPj+ZQQ nTDkv0ubkPvQCKyAu71hqdzjIIPwDP3Url7P0OLDF1G5HYWq6iYjIPteKmWh9KOVi1oRw3phf rboeXZ4UFAAxOsLW9F5DM7WRafluOoK/B5Wx9EB1MEP4Oi0CisHQsi/v8tLXfHHpE6OFu8cFc tpAMQxm27xlJ5yMPBzJVknKCovdtw== X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 11:18:21 -0000 --Sig_/d0x6/+9SHOc3/ef8H6dF1Fx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello list, I'm courios about the support of the ROCK64 SoC. This board is very interes= ting and I'd like to ask whether there is support via FreeBSD 12-CURRENT? Kind regards, O. Hartmann --=20 O. Hartmann --Sig_/d0x6/+9SHOc3/ef8H6dF1Fx Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWqz5dAAKCRDS528fyFhY lJGjAf9cgbRXBVRc039txqgwQcTKKms2O3Ti2b/J+/JKgIAkv9YgdD47Pb3lQJ6g SyWUkH6avnxqXeBbQBRo53RQhHXnAgCOPR9jo22EYZj9nqMT2DhmJ02hUkj8+fMy uXid5GJ0iBGygNwbRQa2hOBSDQEU+Em6No+S6qwoFiVwZgOMgl6l =rHWK -----END PGP SIGNATURE----- --Sig_/d0x6/+9SHOc3/ef8H6dF1Fx-- From owner-freebsd-arm@freebsd.org Sat Mar 17 12:09:59 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B274BF62719 for ; Sat, 17 Mar 2018 12:09:59 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4623E78952; Sat, 17 Mar 2018 12:09:58 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [IPv6:2a02:c7f:1e13:cf00:99b9:b5e4:a4a6:d276] (unknown [IPv6:2a02:c7f:1e13:cf00:99b9:b5e4:a4a6:d276]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 719CD4ECA0; Sat, 17 Mar 2018 12:02:19 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: arm64 panics on boot on a RPi3 From: Andrew Turner In-Reply-To: <7D7EAF74-95E3-4B48-BC57-C3CE4D13501B@freebsd.org> Date: Sat, 17 Mar 2018 12:02:18 +0000 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <7D7EAF74-95E3-4B48-BC57-C3CE4D13501B@freebsd.org> To: Michael Tuexen X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 12:10:00 -0000 You need to update loader.efi. A recent change to the kernel means we = can now enable the EFI runtime services when booting from U-Boot. There = is however an issue where if you try to read the time before calling = SetVirtualAddressMap it will try to call into a function out side of the = runtime map. As this isn=E2=80=99t a valid address we don=E2=80=99t = include it in the memory map so you get the panic below. It doesn=E2=80=99t seem to be an issue on UEFI implementations derived = from EDK2. Andrew > On 17 Mar 2018, at 10:20, Michael Tuexen wrote: >=20 > Dear all, >=20 > FreeBSD head of today panics when booting the arm64 code on a RPi3: >=20 >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > Initializing modules: UFS > Probing 3 block devices.....* done > UFS found 1 partition > Consoles: EFI console =20 > Command line arguments: loader.efi > Image base: 0x39ab8008 > EFI version: 2.05 > EFI Firmware: Das U-boot (rev 0.00) >=20 > FreeBSD/arm64 EFI loader, Revision 1.1 > (Wed Dec 6 19:13:14 CET 2017 root@bsd18.fh-muenster.de) > EFI boot environment > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=3D0x8482a0 data=3D0x137018+0x71f83c = syms=3D[0x8+0x1148a0+0x8+0x106675] > /boot/entropy size=3D0x1000 > /boot/kernel/geom_label.ko text=3D0x2b40 text=3D0x2610 = data=3D0x10120+0xfee4 syms=3D[0x8+0x15a8+0x8+0xf73] >=20 > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... =20 > Using DTB provided by EFI at 0x8004000. > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2018 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 #65 r331093: Sat Mar 17 11:05:06 CET 2018 > = tuexen@bsd10.fh-muenster.de:/usr/home/tuexen/head/sys/arm64/compile/TCP = arm64 > FreeBSD clang version 5.0.1 (branches/release_50 319231) (based on = LLVM 5.0.1) > VT: init without driver. > sysctl_warn_reuse: can't re-use a leaf (kern.features.geom_label)! > module_register: cannot register g_label from kernel; already loaded = from geom_label.ko > Module g_label failed to register: 17 > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: unblocking device. > MAP 39b1b000 mode 2 pages 1 > MAP 3af86000 mode 2 pages 2 > MAP 3f100000 mode 1 pages 1 > random: entropy device external interface > kbd0 at kbdmux0 > ofwbus0: > simplebus0: on ofwbus0 > ofw_clkbus0: on ofwbus0 > clk_fixed0: on ofw_clkbus0 > clk_fixed1: on ofw_clkbus0 > regfix0: on ofwbus0 > regfix1: on ofwbus0 > psci0: on ofwbus0 > local_intc0: mem 0x40000000-0x400000ff = on simplebus0 > intc0: mem 0x7e00b200-0x7e00b3ff irq 16 = on simplebus0 > generic_timer0: irq 47,48,49,50 on simplebus0 > Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality = 1000 > Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000 > x0: ffff0000000109e0 > x1: ffff0000000109b0 > x2: 4 > x3: ffff00000043e638 > x4: ffff00000076eb28 > x5: 110 > x6: ffff000000010808 > x7: ffff000000010638 > x8: 3af61fd0 > x9: 0 > x10: ffff000000993f20 > x11: 0 > x12: ffff0000003b3ab4 > x13: ffff00000043e2f0 > x14: a > x15: 0 > x16: 7 > x17: ffff00000043e2f0 > x18: ffff0000000109b0 > x19: ffff0000000109e0 > x20: ffff000000993000 > x21: ffff000000b89000 > x22: fffffd00012d9070 > x23: 0 > x24: fffffd00011c1d00 > x25: fffffd00011c1c80 > x26: fffffd00011c1cd8 > x27: 0 > x28: fffffd00011d0080 > x29: ffff0000000109d0 > sp: ffff0000000109b0 > lr: ffff0000000fee88 > elr: 3af61fd0 > spsr: a00001c5 > far: 3af61fd0 > esr: 86000007 > panic: data abort in critical section or under mutex > cpuid =3D 0 > time =3D 1 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc =3D 0xffff00000066ead0 lr =3D 0xffff0000000ba870 > sp =3D 0xffff0000000103a0 fp =3D 0xffff0000000105b0 >=20 > db_trace_self_wrapper() at vpanic+0x19c > pc =3D 0xffff0000000ba870 lr =3D 0xffff000000362fb0 > sp =3D 0xffff0000000105c0 fp =3D 0xffff000000010670 >=20 > vpanic() at panic+0x44 > pc =3D 0xffff000000362fb0 lr =3D 0xffff000000362e10 > sp =3D 0xffff000000010680 fp =3D 0xffff000000010700 >=20 > panic() at data_abort+0x21c > pc =3D 0xffff000000362e10 lr =3D 0xffff0000006868b8 > sp =3D 0xffff000000010710 fp =3D 0xffff0000000107c0 >=20 > data_abort() at do_el1h_sync+0x11c > pc =3D 0xffff0000006868b8 lr =3D 0xffff000000686598 > sp =3D 0xffff0000000107d0 fp =3D 0xffff000000010800 >=20 > do_el1h_sync() at handle_el1h_sync+0x74 > pc =3D 0xffff000000686598 lr =3D 0xffff000000671074 > sp =3D 0xffff000000010810 fp =3D 0xffff000000010920 >=20 > handle_el1h_sync() at efi_get_time+0x38 > pc =3D 0xffff000000671074 lr =3D 0xffff0000000fee84 > sp =3D 0xffff000000010930 fp =3D 0xffff0000000109d0 >=20 > efi_get_time() at efirtc_probe+0x18 > pc =3D 0xffff0000000fee84 lr =3D 0xffff0000000ff5b8 > sp =3D 0xffff0000000109e0 fp =3D 0xffff000000010a00 >=20 > efirtc_probe() at device_probe_child+0x150 > pc =3D 0xffff0000000ff5b8 lr =3D 0xffff000000397c1c > sp =3D 0xffff000000010a10 fp =3D 0xffff000000010a70 >=20 > device_probe_child() at device_probe+0x88 > pc =3D 0xffff000000397c1c lr =3D 0xffff0000003988ac > sp =3D 0xffff000000010a80 fp =3D 0xffff000000010aa0 >=20 > device_probe() at bus_generic_new_pass+0xec > pc =3D 0xffff0000003988ac lr =3D 0xffff00000039a78c > sp =3D 0xffff000000010ab0 fp =3D 0xffff000000010ae0 >=20 > bus_generic_new_pass() at bus_generic_new_pass+0xd0 > pc =3D 0xffff00000039a78c lr =3D 0xffff00000039a770 > sp =3D 0xffff000000010af0 fp =3D 0xffff000000010b20 >=20 > bus_generic_new_pass() at root_bus_configure+0x78 > pc =3D 0xffff00000039a770 lr =3D 0xffff00000039c700 > sp =3D 0xffff000000010b30 fp =3D 0xffff000000010b60 >=20 > root_bus_configure() at mi_startup+0xc8 > pc =3D 0xffff00000039c700 lr =3D 0xffff0000002fbbcc > sp =3D 0xffff000000010b70 fp =3D 0xffff000000010bb0 >=20 > mi_startup() at virtdone+0x54 > pc =3D 0xffff0000002fbbcc lr =3D 0xffff000000001084 > sp =3D 0xffff000000010bc0 fp =3D 0x0000000000000000 >=20 > KDB: enter: panic > [ thread pid 0 tid 100000 ] > Stopped at 0x3af61fd0:KDB: reentering > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc =3D 0xffff00000066ead0 lr =3D 0xffff0000000ba870 > sp =3D 0xffff00000000f990 fp =3D 0xffff00000000fba0 >=20 > db_trace_self_wrapper() at kdb_reenter+0x38 > pc =3D 0xffff0000000ba870 lr =3D 0xffff0000003a778c > sp =3D 0xffff00000000fbb0 fp =3D 0xffff00000000fbc0 >=20 > kdb_reenter() at do_el1h_sync+0x11c > pc =3D 0xffff0000003a778c lr =3D 0xffff000000686598 > sp =3D 0xffff00000000fbd0 fp =3D 0xffff00000000fc00 >=20 > do_el1h_sync() at handle_el1h_sync+0x74 > pc =3D 0xffff000000686598 lr =3D 0xffff000000671074 > sp =3D 0xffff00000000fc10 fp =3D 0xffff00000000fd20 >=20 > handle_el1h_sync() at db_read_bytes+0x34 > pc =3D 0xffff000000671074 lr =3D 0xffff00000066e878 > sp =3D 0xffff00000000fd30 fp =3D 0xffff00000000ffe0 >=20 > db_read_bytes() at db_get_value+0x38 > pc =3D 0xffff00000066e878 lr =3D 0xffff0000000b69fc > sp =3D 0xffff00000000fff0 fp =3D 0xffff000000010020 >=20 > db_get_value() at db_disasm_read_word+0x10 > pc =3D 0xffff0000000b69fc lr =3D 0xffff00000066e7f4 > sp =3D 0xffff000000010030 fp =3D 0xffff000000010030 >=20 > db_disasm_read_word() at disasm+0x40 > pc =3D 0xffff00000066e7f4 lr =3D 0xffff00000066f6a0 > sp =3D 0xffff000000010040 fp =3D 0xffff0000000100a0 >=20 > disasm() at db_print_loc_and_inst+0x40 > pc =3D 0xffff00000066f6a0 lr =3D 0xffff0000000b8adc > sp =3D 0xffff0000000100b0 fp =3D 0xffff0000000100c0 >=20 > db_print_loc_and_inst() at db_trap+0xd4 > pc =3D 0xffff0000000b8adc lr =3D 0xffff0000000ba9b8 > sp =3D 0xffff0000000100d0 fp =3D 0xffff0000000102f0 >=20 > db_trap() at kdb_trap+0x1c8 > pc =3D 0xffff0000000ba9b8 lr =3D 0xffff0000003a7bdc > sp =3D 0xffff000000010300 fp =3D 0xffff0000000103b0 >=20 > kdb_trap() at do_el1h_sync+0xf0 > pc =3D 0xffff0000003a7bdc lr =3D 0xffff00000068656c > sp =3D 0xffff0000000103c0 fp =3D 0xffff0000000103f0 >=20 > do_el1h_sync() at handle_el1h_sync+0x74 > pc =3D 0xffff00000068656c lr =3D 0xffff000000671074 > sp =3D 0xffff000000010400 fp =3D 0xffff000000010510 >=20 > handle_el1h_sync() at kdb_enter+0x34 > pc =3D 0xffff000000671074 lr =3D 0xffff0000003a7280 > sp =3D 0xffff000000010520 fp =3D 0xffff0000000105b0 >=20 > kdb_enter() at vpanic+0x1b8 > pc =3D 0xffff0000003a7280 lr =3D 0xffff000000362fcc > sp =3D 0xffff0000000105c0 fp =3D 0xffff000000010670 >=20 > vpanic() at panic+0x44 > pc =3D 0xffff000000362fcc lr =3D 0xffff000000362e10 > sp =3D 0xffff000000010680 fp =3D 0xffff000000010700 >=20 > panic() at data_abort+0x21c > pc =3D 0xffff000000362e10 lr =3D 0xffff0000006868b8 > sp =3D 0xffff000000010710 fp =3D 0xffff0000000107c0 >=20 > data_abort() at do_el1h_sync+0x11c > pc =3D 0xffff0000006868b8 lr =3D 0xffff000000686598 > sp =3D 0xffff0000000107d0 fp =3D 0xffff000000010800 >=20 > do_el1h_sync() at handle_el1h_sync+0x74 > pc =3D 0xffff000000686598 lr =3D 0xffff000000671074 > sp =3D 0xffff000000010810 fp =3D 0xffff000000010920 >=20 > handle_el1h_sync() at efi_get_time+0x38 > pc =3D 0xffff000000671074 lr =3D 0xffff0000000fee84 > sp =3D 0xffff000000010930 fp =3D 0xffff0000000109d0 >=20 > efi_get_time() at efirtc_probe+0x18 > pc =3D 0xffff0000000fee84 lr =3D 0xffff0000000ff5b8 > sp =3D 0xffff0000000109e0 fp =3D 0xffff000000010a00 >=20 > efirtc_probe() at device_probe_child+0x150 > pc =3D 0xffff0000000ff5b8 lr =3D 0xffff000000397c1c > sp =3D 0xffff000000010a10 fp =3D 0xffff000000010a70 >=20 > device_probe_child() at device_probe+0x88 > pc =3D 0xffff000000397c1c lr =3D 0xffff0000003988ac > sp =3D 0xffff000000010a80 fp =3D 0xffff000000010aa0 >=20 > device_probe() at bus_generic_new_pass+0xec > pc =3D 0xffff0000003988ac lr =3D 0xffff00000039a78c > sp =3D 0xffff000000010ab0 fp =3D 0xffff000000010ae0 >=20 > bus_generic_new_pass() at bus_generic_new_pass+0xd0 > pc =3D 0xffff00000039a78c lr =3D 0xffff00000039a770 > sp =3D 0xffff000000010af0 fp =3D 0xffff000000010b20 >=20 > bus_generic_new_pass() at root_bus_configure+0x78 > pc =3D 0xffff00000039a770 lr =3D 0xffff00000039c700 > sp =3D 0xffff000000010b30 fp =3D 0xffff000000010b60 >=20 > root_bus_configure() at mi_startup+0xc8 > pc =3D 0xffff00000039c700 lr =3D 0xffff0000002fbbcc > sp =3D 0xffff000000010b70 fp =3D 0xffff000000010bb0 >=20 > mi_startup() at virtdone+0x54 > pc =3D 0xffff0000002fbbcc lr =3D 0xffff000000001084 > sp =3D 0xffff000000010bc0 fp =3D 0x0000000000000000 >=20 > *** error reading from address 3af61fd0 *** > KDB: reentering > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc =3D 0xffff00000066ead0 lr =3D 0xffff0000000ba870 > sp =3D 0xffff00000000fdb0 fp =3D 0xffff00000000ffc0 >=20 > db_trace_self_wrapper() at kdb_reenter+0x38 > pc =3D 0xffff0000000ba870 lr =3D 0xffff0000003a778c > sp =3D 0xffff00000000ffd0 fp =3D 0xffff00000000ffe0 >=20 > kdb_reenter() at db_get_value+0x50 > pc =3D 0xffff0000003a778c lr =3D 0xffff0000000b6a14 > sp =3D 0xffff00000000fff0 fp =3D 0xffff000000010020 >=20 > db_get_value() at db_disasm_read_word+0x10 > pc =3D 0xffff0000000b6a14 lr =3D 0xffff00000066e7f4 > sp =3D 0xffff000000010030 fp =3D 0xffff000000010030 >=20 > db_disasm_read_word() at disasm+0x40 > pc =3D 0xffff00000066e7f4 lr =3D 0xffff00000066f6a0 > sp =3D 0xffff000000010040 fp =3D 0xffff0000000100a0 >=20 > disasm() at db_print_loc_and_inst+0x40 > pc =3D 0xffff00000066f6a0 lr =3D 0xffff0000000b8adc > sp =3D 0xffff0000000100b0 fp =3D 0xffff0000000100c0 >=20 > db_print_loc_and_inst() at db_trap+0xd4 > pc =3D 0xffff0000000b8adc lr =3D 0xffff0000000ba9b8 > sp =3D 0xffff0000000100d0 fp =3D 0xffff0000000102f0 >=20 > db_trap() at kdb_trap+0x1c8 > pc =3D 0xffff0000000ba9b8 lr =3D 0xffff0000003a7bdc > sp =3D 0xffff000000010300 fp =3D 0xffff0000000103b0 >=20 > kdb_trap() at do_el1h_sync+0xf0 > pc =3D 0xffff0000003a7bdc lr =3D 0xffff00000068656c > sp =3D 0xffff0000000103c0 fp =3D 0xffff0000000103f0 >=20 > do_el1h_sync() at handle_el1h_sync+0x74 > pc =3D 0xffff00000068656c lr =3D 0xffff000000671074 > sp =3D 0xffff000000010400 fp =3D 0xffff000000010510 >=20 > handle_el1h_sync() at kdb_enter+0x34 > pc =3D 0xffff000000671074 lr =3D 0xffff0000003a7280 > sp =3D 0xffff000000010520 fp =3D 0xffff0000000105b0 >=20 > kdb_enter() at vpanic+0x1b8 > pc =3D 0xffff0000003a7280 lr =3D 0xffff000000362fcc > sp =3D 0xffff0000000105c0 fp =3D 0xffff000000010670 >=20 > vpanic() at panic+0x44 > pc =3D 0xffff000000362fcc lr =3D 0xffff000000362e10 > sp =3D 0xffff000000010680 fp =3D 0xffff000000010700 >=20 > panic() at data_abort+0x21c > pc =3D 0xffff000000362e10 lr =3D 0xffff0000006868b8 > sp =3D 0xffff000000010710 fp =3D 0xffff0000000107c0 >=20 > data_abort() at do_el1h_sync+0x11c > pc =3D 0xffff0000006868b8 lr =3D 0xffff000000686598 > sp =3D 0xffff0000000107d0 fp =3D 0xffff000000010800 >=20 > do_el1h_sync() at handle_el1h_sync+0x74 > pc =3D 0xffff000000686598 lr =3D 0xffff000000671074 > sp =3D 0xffff000000010810 fp =3D 0xffff000000010920 >=20 > handle_el1h_sync() at efi_get_time+0x38 > pc =3D 0xffff000000671074 lr =3D 0xffff0000000fee84 > sp =3D 0xffff000000010930 fp =3D 0xffff0000000109d0 >=20 > efi_get_time() at efirtc_probe+0x18 > pc =3D 0xffff0000000fee84 lr =3D 0xffff0000000ff5b8 > sp =3D 0xffff0000000109e0 fp =3D 0xffff000000010a00 >=20 > efirtc_probe() at device_probe_child+0x150 > pc =3D 0xffff0000000ff5b8 lr =3D 0xffff000000397c1c > sp =3D 0xffff000000010a10 fp =3D 0xffff000000010a70 >=20 > device_probe_child() at device_probe+0x88 > pc =3D 0xffff000000397c1c lr =3D 0xffff0000003988ac > sp =3D 0xffff000000010a80 fp =3D 0xffff000000010aa0 >=20 > device_probe() at bus_generic_new_pass+0xec > pc =3D 0xffff0000003988ac lr =3D 0xffff00000039a78c > sp =3D 0xffff000000010ab0 fp =3D 0xffff000000010ae0 >=20 > bus_generic_new_pass() at bus_generic_new_pass+0xd0 > pc =3D 0xffff00000039a78c lr =3D 0xffff00000039a770 > sp =3D 0xffff000000010af0 fp =3D 0xffff000000010b20 >=20 > bus_generic_new_pass() at root_bus_configure+0x78 > pc =3D 0xffff00000039a770 lr =3D 0xffff00000039c700 > sp =3D 0xffff000000010b30 fp =3D 0xffff000000010b60 >=20 > root_bus_configure() at mi_startup+0xc8 > pc =3D 0xffff00000039c700 lr =3D 0xffff0000002fbbcc > sp =3D 0xffff000000010b70 fp =3D 0xffff000000010bb0 >=20 > mi_startup() at virtdone+0x54 > pc =3D 0xffff0000002fbbcc lr =3D 0xffff000000001084 > sp =3D 0xffff000000010bc0 fp =3D 0x0000000000000000 >=20 > db>=20 >=20 > Any idea what goes wrong? >=20 > Best regards > Michael > _______________________________________________ > 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" >=20 From owner-freebsd-arm@freebsd.org Sat Mar 17 20:06:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A935FF6520B for ; Sat, 17 Mar 2018 20:06:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 465276C605 for ; Sat, 17 Mar 2018 20:06:05 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 7EA787689 for ; Sat, 17 Mar 2018 20:06:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2HK64H5071348 for ; Sat, 17 Mar 2018 20:06:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2HK64RR071346 for freebsd-arm@FreeBSD.org; Sat, 17 Mar 2018 20:06:04 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 226682] ARMADA38X: Running out of CESA TDMA descriptors for disk I/O on GELI SSD Date: Sat, 17 Mar 2018 20:06:04 +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 Some People X-Bugzilla-Who: chris@mumac.de 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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 20:06:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226682 Bug ID: 226682 Summary: ARMADA38X: Running out of CESA TDMA descriptors for disk I/O on GELI SSD Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: chris@mumac.de While testing I/O performance on a SolidRun Clearfog Pro (ARMADA A38x) with= an SSD (PLEXTOR PX-128M6G-2242) encrypted by GELI AES-CBC, errors were reporte= d on the console/dmesg about running out of TMDA descriptors. Looking at sys/dev/cesa/cesa.h, the comments seem to focus on network buffe= rs with a maximum size of 1500 bytes while SSD disk I/O in my case would invol= ve 4KB buffers. Without really diving into the rest of the code, I've increased the values in cesa.h and can now operate the SSD with sustained rates ~200M= B/s without running out of TDMA descriptors. There might be better ways to do this but the "diff" below most certainly f= ixed my issue. Index: sys/dev/cesa/cesa.h =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 --- sys/dev/cesa/cesa.h (revision 329554) +++ sys/dev/cesa/cesa.h (working copy) @@ -63,8 +63,8 @@ */ /* Values below are optimized for requests containing about 1.5 kB of data= */ -#define CESA_SA_DESC_PER_REQ 2 -#define CESA_TDMA_DESC_PER_REQ 8 +#define CESA_SA_DESC_PER_REQ (2 * 3) /* 4KB, not 1.5kB */ +#define CESA_TDMA_DESC_PER_REQ (8 * 3) /* 4KB, not 1.5kB */ #define CESA_SA_DESCRIPTORS (CESA_SA_DESC_PER_REQ * CESA_REQUES= TS) #define CESA_TDMA_DESCRIPTORS (CESA_TDMA_DESC_PER_REQ * CESA_REQUESTS) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Mar 17 22:38:43 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09030F4AE24 for ; Sat, 17 Mar 2018 22:38:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 994CA71B78 for ; Sat, 17 Mar 2018 22:38:42 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id ED4E510B0B for ; Sat, 17 Mar 2018 22:38:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w2HMcfqf027925 for ; Sat, 17 Mar 2018 22:38:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w2HMcfAL027924 for freebsd-arm@FreeBSD.org; Sat, 17 Mar 2018 22:38:41 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 226684] mmcsd driver does not indicate SD card activity on 'activity' LED Date: Sat, 17 Mar 2018 22:38:41 +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: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: bobf@mrp3.com 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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 22:38:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226684 Bug ID: 226684 Summary: mmcsd driver does not indicate SD card activity on 'activity' LED Product: Base System Version: 11.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: bobf@mrp3.com although the 'geom' driver has the capability of assigning an LED to indica= te activity, assigning "kern.geom.disk.mmcsd0.led" to the correct 'led' device name does NOT appear to work. Upon further investigation, there appears to be no supporting code (i.e. ca= lls to 'led_set' for example) in the mmcsd driver. And none of the code in the 'geom' driver appears to actually set the LED to 'on', except for errors. I first observed this in FreeBSD 11.0 on the Raspberry Pi 2 (RPI2 kernel). = I can still observe it in the latest '-STABLE' release as of last week. I may be able to add a patch to this bug report that could possibly correct= for this, either to the 'geom' driver or to the 'mmcsd' driver (as appropriate)= .=20 In short, the mmcsd (or geom) driver would need to be updated to blink the = LED in an appropriate manner while there is disk activity, using the appropriate sysctl variable (in this case, "kern.geom.disk.mmcsd0.led" or similar) to indicate which led to use (via 'led_set'), similar to some of the existing = code in the geom driver. SYSTEM INFO: 'uname -a' string: FreeBSD pi2b 11.1-STABLE FreeBSD 11.1-STABLE #0 r330739: Sat Mar 10 16:07:22 PST 2018 bobf@hack.SFT.local:/usr/obj/arm.armv6/usr/src/sys/RPI2 arm doing 'geom PART list' gives me this output: Geom name: mmcsd0 modified: false state: OK fwheads: 255 fwsectors: 63 last: 62333951 first: 63 entries: 4 scheme: MBR Providers: 1. Name: mmcsd0s1 Mediasize: 17805312 (17M) Sectorsize: 512 Stripesize: 4194304 Stripeoffset: 32256 Mode: r1w1e2 attrib: active rawtype: 12 length: 17805312 offset: 32256 type: !12 index: 1 end: 34838 start: 63 2. Name: mmcsd0s2 Mediasize: 31897145856 (30G) Sectorsize: 512 Stripesize: 4194304 Stripeoffset: 1060352 Mode: r1w1e3 rawtype: 165 length: 31897145856 offset: 17837568 type: freebsd index: 2 end: 62333951 start: 34839 Consumers: 1. Name: mmcsd0 Mediasize: 31914983424 (30G) Sectorsize: 512 Stripesize: 4194304 Stripeoffset: 0 Mode: r2w2e7 Geom name: mmcsd0s2 modified: false state: OK fwheads: 255 fwsectors: 63 last: 62299112 first: 0 entries: 8 scheme: BSD Providers: 1. Name: mmcsd0s2a Mediasize: 31897092096 (30G) Sectorsize: 512 Stripesize: 4194304 Stripeoffset: 1114112 Mode: r1w1e2 rawtype: 7 length: 31897092096 offset: 53760 type: freebsd-ufs index: 1 end: 62299112 start: 105 Consumers: 1. Name: mmcsd0s2 Mediasize: 31897145856 (30G) Sectorsize: 512 Stripesize: 4194304 Stripeoffset: 1060352 Mode: r1w1e3 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Mar 17 23:36:42 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92D60F4ED1D for ; Sat, 17 Mar 2018 23:36:42 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 254FE73BF0 for ; Sat, 17 Mar 2018 23:36:42 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from dhcp-9621.meeting.ietf.org (dhcp-9621.meeting.ietf.org [31.133.150.33]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 6D6EF721E280D; Sun, 18 Mar 2018 00:36:37 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: arm64 panics on boot on a RPi3 From: Michael Tuexen In-Reply-To: Date: Sat, 17 Mar 2018 23:36:35 +0000 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <656FA611-2F31-4B5A-85AC-EF1F18756BBB@freebsd.org> References: <7D7EAF74-95E3-4B48-BC57-C3CE4D13501B@freebsd.org> To: Andrew Turner X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 23:36:42 -0000 > On 17. Mar 2018, at 12:02, Andrew Turner wrote: >=20 > You need to update loader.efi. A recent change to the kernel means we = can now enable the EFI runtime services when booting from U-Boot. There = is however an issue where if you try to read the time before calling = SetVirtualAddressMap it will try to call into a function out side of the = runtime map. As this isn=E2=80=99t a valid address we don=E2=80=99t = include it in the memory map so you get the panic below. Hi Andrew, updating loader.efi fixed the problem. Thank you very much! Best regards Michael >=20 > It doesn=E2=80=99t seem to be an issue on UEFI implementations derived = from EDK2. >=20 > Andrew >=20 >> On 17 Mar 2018, at 10:20, Michael Tuexen wrote: >>=20 >> Dear all, >>=20 >> FreeBSD head of today panics when booting the arm64 code on a RPi3: >>=20 >>>> FreeBSD EFI boot block >> Loader path: /boot/loader.efi >>=20 >> Initializing modules: UFS >> Probing 3 block devices.....* done >> UFS found 1 partition >> Consoles: EFI console =20 >> Command line arguments: loader.efi >> Image base: 0x39ab8008 >> EFI version: 2.05 >> EFI Firmware: Das U-boot (rev 0.00) >>=20 >> FreeBSD/arm64 EFI loader, Revision 1.1 >> (Wed Dec 6 19:13:14 CET 2017 root@bsd18.fh-muenster.de) >> EFI boot environment >> Loading /boot/defaults/loader.conf >> /boot/kernel/kernel text=3D0x8482a0 data=3D0x137018+0x71f83c = syms=3D[0x8+0x1148a0+0x8+0x106675] >> /boot/entropy size=3D0x1000 >> /boot/kernel/geom_label.ko text=3D0x2b40 text=3D0x2610 = data=3D0x10120+0xfee4 syms=3D[0x8+0x15a8+0x8+0xf73] >>=20 >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... =20 >> Using DTB provided by EFI at 0x8004000. >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2018 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 #65 r331093: Sat Mar 17 11:05:06 CET 2018 >> = tuexen@bsd10.fh-muenster.de:/usr/home/tuexen/head/sys/arm64/compile/TCP = arm64 >> FreeBSD clang version 5.0.1 (branches/release_50 319231) (based on = LLVM 5.0.1) >> VT: init without driver. >> sysctl_warn_reuse: can't re-use a leaf (kern.features.geom_label)! >> module_register: cannot register g_label from kernel; already loaded = from geom_label.ko >> Module g_label failed to register: 17 >> Starting CPU 1 (1) >> Starting CPU 2 (2) >> Starting CPU 3 (3) >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> random: unblocking device. >> MAP 39b1b000 mode 2 pages 1 >> MAP 3af86000 mode 2 pages 2 >> MAP 3f100000 mode 1 pages 1 >> random: entropy device external interface >> kbd0 at kbdmux0 >> ofwbus0: >> simplebus0: on ofwbus0 >> ofw_clkbus0: on ofwbus0 >> clk_fixed0: on ofw_clkbus0 >> clk_fixed1: on ofw_clkbus0 >> regfix0: on ofwbus0 >> regfix1: on ofwbus0 >> psci0: on ofwbus0 >> local_intc0: mem 0x40000000-0x400000ff = on simplebus0 >> intc0: mem 0x7e00b200-0x7e00b3ff irq = 16 on simplebus0 >> generic_timer0: irq 47,48,49,50 on simplebus0 >> Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality = 1000 >> Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality = 1000 >> x0: ffff0000000109e0 >> x1: ffff0000000109b0 >> x2: 4 >> x3: ffff00000043e638 >> x4: ffff00000076eb28 >> x5: 110 >> x6: ffff000000010808 >> x7: ffff000000010638 >> x8: 3af61fd0 >> x9: 0 >> x10: ffff000000993f20 >> x11: 0 >> x12: ffff0000003b3ab4 >> x13: ffff00000043e2f0 >> x14: a >> x15: 0 >> x16: 7 >> x17: ffff00000043e2f0 >> x18: ffff0000000109b0 >> x19: ffff0000000109e0 >> x20: ffff000000993000 >> x21: ffff000000b89000 >> x22: fffffd00012d9070 >> x23: 0 >> x24: fffffd00011c1d00 >> x25: fffffd00011c1c80 >> x26: fffffd00011c1cd8 >> x27: 0 >> x28: fffffd00011d0080 >> x29: ffff0000000109d0 >> sp: ffff0000000109b0 >> lr: ffff0000000fee88 >> elr: 3af61fd0 >> spsr: a00001c5 >> far: 3af61fd0 >> esr: 86000007 >> panic: data abort in critical section or under mutex >> cpuid =3D 0 >> time =3D 1 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self_wrapper+0x28 >> pc =3D 0xffff00000066ead0 lr =3D 0xffff0000000ba870 >> sp =3D 0xffff0000000103a0 fp =3D 0xffff0000000105b0 >>=20 >> db_trace_self_wrapper() at vpanic+0x19c >> pc =3D 0xffff0000000ba870 lr =3D 0xffff000000362fb0 >> sp =3D 0xffff0000000105c0 fp =3D 0xffff000000010670 >>=20 >> vpanic() at panic+0x44 >> pc =3D 0xffff000000362fb0 lr =3D 0xffff000000362e10 >> sp =3D 0xffff000000010680 fp =3D 0xffff000000010700 >>=20 >> panic() at data_abort+0x21c >> pc =3D 0xffff000000362e10 lr =3D 0xffff0000006868b8 >> sp =3D 0xffff000000010710 fp =3D 0xffff0000000107c0 >>=20 >> data_abort() at do_el1h_sync+0x11c >> pc =3D 0xffff0000006868b8 lr =3D 0xffff000000686598 >> sp =3D 0xffff0000000107d0 fp =3D 0xffff000000010800 >>=20 >> do_el1h_sync() at handle_el1h_sync+0x74 >> pc =3D 0xffff000000686598 lr =3D 0xffff000000671074 >> sp =3D 0xffff000000010810 fp =3D 0xffff000000010920 >>=20 >> handle_el1h_sync() at efi_get_time+0x38 >> pc =3D 0xffff000000671074 lr =3D 0xffff0000000fee84 >> sp =3D 0xffff000000010930 fp =3D 0xffff0000000109d0 >>=20 >> efi_get_time() at efirtc_probe+0x18 >> pc =3D 0xffff0000000fee84 lr =3D 0xffff0000000ff5b8 >> sp =3D 0xffff0000000109e0 fp =3D 0xffff000000010a00 >>=20 >> efirtc_probe() at device_probe_child+0x150 >> pc =3D 0xffff0000000ff5b8 lr =3D 0xffff000000397c1c >> sp =3D 0xffff000000010a10 fp =3D 0xffff000000010a70 >>=20 >> device_probe_child() at device_probe+0x88 >> pc =3D 0xffff000000397c1c lr =3D 0xffff0000003988ac >> sp =3D 0xffff000000010a80 fp =3D 0xffff000000010aa0 >>=20 >> device_probe() at bus_generic_new_pass+0xec >> pc =3D 0xffff0000003988ac lr =3D 0xffff00000039a78c >> sp =3D 0xffff000000010ab0 fp =3D 0xffff000000010ae0 >>=20 >> bus_generic_new_pass() at bus_generic_new_pass+0xd0 >> pc =3D 0xffff00000039a78c lr =3D 0xffff00000039a770 >> sp =3D 0xffff000000010af0 fp =3D 0xffff000000010b20 >>=20 >> bus_generic_new_pass() at root_bus_configure+0x78 >> pc =3D 0xffff00000039a770 lr =3D 0xffff00000039c700 >> sp =3D 0xffff000000010b30 fp =3D 0xffff000000010b60 >>=20 >> root_bus_configure() at mi_startup+0xc8 >> pc =3D 0xffff00000039c700 lr =3D 0xffff0000002fbbcc >> sp =3D 0xffff000000010b70 fp =3D 0xffff000000010bb0 >>=20 >> mi_startup() at virtdone+0x54 >> pc =3D 0xffff0000002fbbcc lr =3D 0xffff000000001084 >> sp =3D 0xffff000000010bc0 fp =3D 0x0000000000000000 >>=20 >> KDB: enter: panic >> [ thread pid 0 tid 100000 ] >> Stopped at 0x3af61fd0:KDB: reentering >> KDB: stack backtrace: >> db_trace_self() at db_trace_self_wrapper+0x28 >> pc =3D 0xffff00000066ead0 lr =3D 0xffff0000000ba870 >> sp =3D 0xffff00000000f990 fp =3D 0xffff00000000fba0 >>=20 >> db_trace_self_wrapper() at kdb_reenter+0x38 >> pc =3D 0xffff0000000ba870 lr =3D 0xffff0000003a778c >> sp =3D 0xffff00000000fbb0 fp =3D 0xffff00000000fbc0 >>=20 >> kdb_reenter() at do_el1h_sync+0x11c >> pc =3D 0xffff0000003a778c lr =3D 0xffff000000686598 >> sp =3D 0xffff00000000fbd0 fp =3D 0xffff00000000fc00 >>=20 >> do_el1h_sync() at handle_el1h_sync+0x74 >> pc =3D 0xffff000000686598 lr =3D 0xffff000000671074 >> sp =3D 0xffff00000000fc10 fp =3D 0xffff00000000fd20 >>=20 >> handle_el1h_sync() at db_read_bytes+0x34 >> pc =3D 0xffff000000671074 lr =3D 0xffff00000066e878 >> sp =3D 0xffff00000000fd30 fp =3D 0xffff00000000ffe0 >>=20 >> db_read_bytes() at db_get_value+0x38 >> pc =3D 0xffff00000066e878 lr =3D 0xffff0000000b69fc >> sp =3D 0xffff00000000fff0 fp =3D 0xffff000000010020 >>=20 >> db_get_value() at db_disasm_read_word+0x10 >> pc =3D 0xffff0000000b69fc lr =3D 0xffff00000066e7f4 >> sp =3D 0xffff000000010030 fp =3D 0xffff000000010030 >>=20 >> db_disasm_read_word() at disasm+0x40 >> pc =3D 0xffff00000066e7f4 lr =3D 0xffff00000066f6a0 >> sp =3D 0xffff000000010040 fp =3D 0xffff0000000100a0 >>=20 >> disasm() at db_print_loc_and_inst+0x40 >> pc =3D 0xffff00000066f6a0 lr =3D 0xffff0000000b8adc >> sp =3D 0xffff0000000100b0 fp =3D 0xffff0000000100c0 >>=20 >> db_print_loc_and_inst() at db_trap+0xd4 >> pc =3D 0xffff0000000b8adc lr =3D 0xffff0000000ba9b8 >> sp =3D 0xffff0000000100d0 fp =3D 0xffff0000000102f0 >>=20 >> db_trap() at kdb_trap+0x1c8 >> pc =3D 0xffff0000000ba9b8 lr =3D 0xffff0000003a7bdc >> sp =3D 0xffff000000010300 fp =3D 0xffff0000000103b0 >>=20 >> kdb_trap() at do_el1h_sync+0xf0 >> pc =3D 0xffff0000003a7bdc lr =3D 0xffff00000068656c >> sp =3D 0xffff0000000103c0 fp =3D 0xffff0000000103f0 >>=20 >> do_el1h_sync() at handle_el1h_sync+0x74 >> pc =3D 0xffff00000068656c lr =3D 0xffff000000671074 >> sp =3D 0xffff000000010400 fp =3D 0xffff000000010510 >>=20 >> handle_el1h_sync() at kdb_enter+0x34 >> pc =3D 0xffff000000671074 lr =3D 0xffff0000003a7280 >> sp =3D 0xffff000000010520 fp =3D 0xffff0000000105b0 >>=20 >> kdb_enter() at vpanic+0x1b8 >> pc =3D 0xffff0000003a7280 lr =3D 0xffff000000362fcc >> sp =3D 0xffff0000000105c0 fp =3D 0xffff000000010670 >>=20 >> vpanic() at panic+0x44 >> pc =3D 0xffff000000362fcc lr =3D 0xffff000000362e10 >> sp =3D 0xffff000000010680 fp =3D 0xffff000000010700 >>=20 >> panic() at data_abort+0x21c >> pc =3D 0xffff000000362e10 lr =3D 0xffff0000006868b8 >> sp =3D 0xffff000000010710 fp =3D 0xffff0000000107c0 >>=20 >> data_abort() at do_el1h_sync+0x11c >> pc =3D 0xffff0000006868b8 lr =3D 0xffff000000686598 >> sp =3D 0xffff0000000107d0 fp =3D 0xffff000000010800 >>=20 >> do_el1h_sync() at handle_el1h_sync+0x74 >> pc =3D 0xffff000000686598 lr =3D 0xffff000000671074 >> sp =3D 0xffff000000010810 fp =3D 0xffff000000010920 >>=20 >> handle_el1h_sync() at efi_get_time+0x38 >> pc =3D 0xffff000000671074 lr =3D 0xffff0000000fee84 >> sp =3D 0xffff000000010930 fp =3D 0xffff0000000109d0 >>=20 >> efi_get_time() at efirtc_probe+0x18 >> pc =3D 0xffff0000000fee84 lr =3D 0xffff0000000ff5b8 >> sp =3D 0xffff0000000109e0 fp =3D 0xffff000000010a00 >>=20 >> efirtc_probe() at device_probe_child+0x150 >> pc =3D 0xffff0000000ff5b8 lr =3D 0xffff000000397c1c >> sp =3D 0xffff000000010a10 fp =3D 0xffff000000010a70 >>=20 >> device_probe_child() at device_probe+0x88 >> pc =3D 0xffff000000397c1c lr =3D 0xffff0000003988ac >> sp =3D 0xffff000000010a80 fp =3D 0xffff000000010aa0 >>=20 >> device_probe() at bus_generic_new_pass+0xec >> pc =3D 0xffff0000003988ac lr =3D 0xffff00000039a78c >> sp =3D 0xffff000000010ab0 fp =3D 0xffff000000010ae0 >>=20 >> bus_generic_new_pass() at bus_generic_new_pass+0xd0 >> pc =3D 0xffff00000039a78c lr =3D 0xffff00000039a770 >> sp =3D 0xffff000000010af0 fp =3D 0xffff000000010b20 >>=20 >> bus_generic_new_pass() at root_bus_configure+0x78 >> pc =3D 0xffff00000039a770 lr =3D 0xffff00000039c700 >> sp =3D 0xffff000000010b30 fp =3D 0xffff000000010b60 >>=20 >> root_bus_configure() at mi_startup+0xc8 >> pc =3D 0xffff00000039c700 lr =3D 0xffff0000002fbbcc >> sp =3D 0xffff000000010b70 fp =3D 0xffff000000010bb0 >>=20 >> mi_startup() at virtdone+0x54 >> pc =3D 0xffff0000002fbbcc lr =3D 0xffff000000001084 >> sp =3D 0xffff000000010bc0 fp =3D 0x0000000000000000 >>=20 >> *** error reading from address 3af61fd0 *** >> KDB: reentering >> KDB: stack backtrace: >> db_trace_self() at db_trace_self_wrapper+0x28 >> pc =3D 0xffff00000066ead0 lr =3D 0xffff0000000ba870 >> sp =3D 0xffff00000000fdb0 fp =3D 0xffff00000000ffc0 >>=20 >> db_trace_self_wrapper() at kdb_reenter+0x38 >> pc =3D 0xffff0000000ba870 lr =3D 0xffff0000003a778c >> sp =3D 0xffff00000000ffd0 fp =3D 0xffff00000000ffe0 >>=20 >> kdb_reenter() at db_get_value+0x50 >> pc =3D 0xffff0000003a778c lr =3D 0xffff0000000b6a14 >> sp =3D 0xffff00000000fff0 fp =3D 0xffff000000010020 >>=20 >> db_get_value() at db_disasm_read_word+0x10 >> pc =3D 0xffff0000000b6a14 lr =3D 0xffff00000066e7f4 >> sp =3D 0xffff000000010030 fp =3D 0xffff000000010030 >>=20 >> db_disasm_read_word() at disasm+0x40 >> pc =3D 0xffff00000066e7f4 lr =3D 0xffff00000066f6a0 >> sp =3D 0xffff000000010040 fp =3D 0xffff0000000100a0 >>=20 >> disasm() at db_print_loc_and_inst+0x40 >> pc =3D 0xffff00000066f6a0 lr =3D 0xffff0000000b8adc >> sp =3D 0xffff0000000100b0 fp =3D 0xffff0000000100c0 >>=20 >> db_print_loc_and_inst() at db_trap+0xd4 >> pc =3D 0xffff0000000b8adc lr =3D 0xffff0000000ba9b8 >> sp =3D 0xffff0000000100d0 fp =3D 0xffff0000000102f0 >>=20 >> db_trap() at kdb_trap+0x1c8 >> pc =3D 0xffff0000000ba9b8 lr =3D 0xffff0000003a7bdc >> sp =3D 0xffff000000010300 fp =3D 0xffff0000000103b0 >>=20 >> kdb_trap() at do_el1h_sync+0xf0 >> pc =3D 0xffff0000003a7bdc lr =3D 0xffff00000068656c >> sp =3D 0xffff0000000103c0 fp =3D 0xffff0000000103f0 >>=20 >> do_el1h_sync() at handle_el1h_sync+0x74 >> pc =3D 0xffff00000068656c lr =3D 0xffff000000671074 >> sp =3D 0xffff000000010400 fp =3D 0xffff000000010510 >>=20 >> handle_el1h_sync() at kdb_enter+0x34 >> pc =3D 0xffff000000671074 lr =3D 0xffff0000003a7280 >> sp =3D 0xffff000000010520 fp =3D 0xffff0000000105b0 >>=20 >> kdb_enter() at vpanic+0x1b8 >> pc =3D 0xffff0000003a7280 lr =3D 0xffff000000362fcc >> sp =3D 0xffff0000000105c0 fp =3D 0xffff000000010670 >>=20 >> vpanic() at panic+0x44 >> pc =3D 0xffff000000362fcc lr =3D 0xffff000000362e10 >> sp =3D 0xffff000000010680 fp =3D 0xffff000000010700 >>=20 >> panic() at data_abort+0x21c >> pc =3D 0xffff000000362e10 lr =3D 0xffff0000006868b8 >> sp =3D 0xffff000000010710 fp =3D 0xffff0000000107c0 >>=20 >> data_abort() at do_el1h_sync+0x11c >> pc =3D 0xffff0000006868b8 lr =3D 0xffff000000686598 >> sp =3D 0xffff0000000107d0 fp =3D 0xffff000000010800 >>=20 >> do_el1h_sync() at handle_el1h_sync+0x74 >> pc =3D 0xffff000000686598 lr =3D 0xffff000000671074 >> sp =3D 0xffff000000010810 fp =3D 0xffff000000010920 >>=20 >> handle_el1h_sync() at efi_get_time+0x38 >> pc =3D 0xffff000000671074 lr =3D 0xffff0000000fee84 >> sp =3D 0xffff000000010930 fp =3D 0xffff0000000109d0 >>=20 >> efi_get_time() at efirtc_probe+0x18 >> pc =3D 0xffff0000000fee84 lr =3D 0xffff0000000ff5b8 >> sp =3D 0xffff0000000109e0 fp =3D 0xffff000000010a00 >>=20 >> efirtc_probe() at device_probe_child+0x150 >> pc =3D 0xffff0000000ff5b8 lr =3D 0xffff000000397c1c >> sp =3D 0xffff000000010a10 fp =3D 0xffff000000010a70 >>=20 >> device_probe_child() at device_probe+0x88 >> pc =3D 0xffff000000397c1c lr =3D 0xffff0000003988ac >> sp =3D 0xffff000000010a80 fp =3D 0xffff000000010aa0 >>=20 >> device_probe() at bus_generic_new_pass+0xec >> pc =3D 0xffff0000003988ac lr =3D 0xffff00000039a78c >> sp =3D 0xffff000000010ab0 fp =3D 0xffff000000010ae0 >>=20 >> bus_generic_new_pass() at bus_generic_new_pass+0xd0 >> pc =3D 0xffff00000039a78c lr =3D 0xffff00000039a770 >> sp =3D 0xffff000000010af0 fp =3D 0xffff000000010b20 >>=20 >> bus_generic_new_pass() at root_bus_configure+0x78 >> pc =3D 0xffff00000039a770 lr =3D 0xffff00000039c700 >> sp =3D 0xffff000000010b30 fp =3D 0xffff000000010b60 >>=20 >> root_bus_configure() at mi_startup+0xc8 >> pc =3D 0xffff00000039c700 lr =3D 0xffff0000002fbbcc >> sp =3D 0xffff000000010b70 fp =3D 0xffff000000010bb0 >>=20 >> mi_startup() at virtdone+0x54 >> pc =3D 0xffff0000002fbbcc lr =3D 0xffff000000001084 >> sp =3D 0xffff000000010bc0 fp =3D 0x0000000000000000 >>=20 >> db>=20 >>=20 >> Any idea what goes wrong? >>=20 >> Best regards >> Michael >> _______________________________________________ >> 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" >>=20 >=20