Date: Fri, 03 Jul 2020 00:04:08 +0300 From: Furkan Salman <furkan@fkardame.com> To: "freebsd-arm" <freebsd-arm@freebsd.org> Subject: Re: Add Support for Radxa RockPi E Message-ID: <173115808d3.f2327534108660.257113843983027589@fkardame.com> In-Reply-To: <CAJ1Oi8FtjDFEVi%2BgQzLySp%2BEJZ8BsgWuPWdGfQtaJbWjYgxVcg@mail.gmail.com> References: <CAGtf9xPhV%2BYmPYWhwxpzOoZwHeUK0WJFtkCgvti%2B79ux=yn2hw@mail.gmail.com> <A73DEFA8-B248-4FB7-97D8-007042EBEADD@gmail.com> <CAJ1Oi8FtjDFEVi%2BgQzLySp%2BEJZ8BsgWuPWdGfQtaJbWjYgxVcg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Team, With the help of Sergey (S199pWa1k9r), I was able to boot into RockPi E and= have both lan card detected, but one of the lan cannot detect a cable conn= ected to it which means it is always down and doesn't come up. Here is the Boot log=C2=A0https://hastebin.com/olehocidib.makefile When I connect the lan on RTL8211E (GMAC) then it can get ip address from t= he dhcp server but when I connect lan to PHY (10/100) then it is not coming= up. ifconfig can be found here=C2=A0https://hastebin.com/ecazezikih.xml=C2=A0= =C2=A0 I think gonzo will be looking into this on the weekend, but if there is any= one else who is aware of this issue then kindly guide us. Thanks. ---- On Thu, 25 Jun 2020 17:49:51 +0300 Aleksandr Rybalko <mailto:ray@freeb= sd.org> wrote ---- Hmmm, I see only GMAC (10/100/1000) and PHY(10/100) that can be configured = as connected to GMAC in=C2=A0Datasheet. =D1=87=D1=82, 25 =D1=87=D0=B5=D1=80=D0=B2. 2020 =D0=BE 02:17 Sleep Walker <= mailto:s199p.wa1k9r@gmail.com> =D0=BF=D0=B8=D1=88=D0=B5: >From TRM =E2=80=94=E2=80=94=E2=80=94 =20 There are two independent GMAC controllers named GMAC2IO and GMAC2PHY: =EF=81=AC GMAC2IO Supports 10/100/1000-Mbps data transfer rates with the R= GMII interfaces and Supports 10/100-Mbps data transfer rates with the RMII = interfaces =EF=81=AC GMAC2PHY Supports 10/100-Mbps data transfer rates with the RMII = interfaces =E2=80=94=E2=80=94=E2=80=94- =20 =20 =D0=9E=D1=82=D0=BF=D1=80=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=D0=BE =D1=81 iPad =20 > 24 =D0=B8=D1=8E=D0=BD=D1=8F 2020 =D0=B3., =D0=B2 19:29, Ganbold Tsagaank= huu <mailto:ganbold@gmail.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(= =D0=B0): >=20 > =EF=BB=BFOn Wed, Jun 24, 2020 at 10:12 PM Furkan Salman <mailto:furkan@f= kardame.com> wrote: >=20 >> Hello, >>=20 >> I was able to boot FreeBSD on Radxa RockPi E over emmc with the help of >> Sergey (sl199pwa1k9r). >> Details of the device can be found here >> https://wiki.radxa.com/RockpiE/getting_started. It have removable emmc. >>=20 >>=20 >>=20 >>=20 >>=20 >> Boot Logs: https://hastebin.com/eyokuqoyif.coffeescript >>=20 >>=20 >>=20 >> Things not working yet: >>=20 >> RK3328 onboard Lan. >>=20 >> Micro-Hdmi connector (Only used for debugging and not MP) >>=20 >> Boot from SD Card, Pin detection fails, Was able to boot into it manual= ly. >>=20 >> As per Sergey, we might need some help understanding how the Lan is >> working on rock64 board using onboard Lan driver. >>=20 >>=20 >>=20 >> Can anyone advice us on how can we add onboard lan driver. >>=20 >>=20 > Their wiki page doesn't say anything about 100M LAN in detail. Maybe it = is > better either to ask them or boot linux and see what Ethernet > chipset/controller it says in log/dmesg. >=20 > Ganbold >=20 >=20 >=20 >>=20 >>=20 >> Thanks. >> Furkan K. >> _______________________________________________ >> mailto:freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "mailto:freebsd-arm-unsubscribe@freebs= d.org" >>=20 > _______________________________________________ > mailto:freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "mailto:freebsd-arm-unsubscribe@freebsd= .org" _______________________________________________ mailto:freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "mailto:freebsd-arm-unsubscribe@freebsd.o= rg" From owner-freebsd-arm@freebsd.org Fri Jul 3 07:58:52 2020 Return-Path: <owner-freebsd-arm@freebsd.org> Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2AA5936DC33 for <freebsd-arm@mailman.nyi.freebsd.org>; Fri, 3 Jul 2020 07:58:52 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: from mail-il1-x142.google.com (mail-il1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49ynQz5Yb0z3fwj; Fri, 3 Jul 2020 07:58:51 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: by mail-il1-x142.google.com with SMTP id i18so26573961ilk.10; Fri, 03 Jul 2020 00:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=gwi6r7Y5JCzFUgWHR5Ui4fU4NmZCS0fwC//QymVyoFg=; b=mBpTTVgryK958apz3xuQXDmnLRDVASTKbr95wsTVCmkBDxl4b+p2mwl7QRFGi3jc+P 2GWBr5381LPqCXm/6hclzUoait0FMo1713yNDv1qtODcAWmP1M5BwoykS9g26bUTfWun BOueZ6zdgiY8/8avPFG0r16FUaqqx4lYGSolvhVoBwi7G5tZHPqMfSDBMZ3VbtuXgds8 Mlpnw92Geun7Kgn666QogHDNCTwsOLl7LjX1exoGcgkaU2zUTEAP9I7UcVSTNpIJbPm0 Q2jDPDbFX+a1P04nrpLrDz0Qdaso68N5ryP3ARY9OIv1Q7Rh70cKXa0cMJpd+ItG67UP kmhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=gwi6r7Y5JCzFUgWHR5Ui4fU4NmZCS0fwC//QymVyoFg=; b=kFeNaDsLYgWi59oETevgQqwSj6DN5AXZhAP93TVdwsz5grsD4Ej4SapHDz85Qtel9y 8zrg78D2z4gAnIgiuNhiAe014qeEB+9KO/P4Yp/f6TjecjgNypTiEumYpDP99/WO4dHs EIKBREyOdbAM/uz9v8EBPiriCN/ul4Lkw5yqSj292OvqxPuAi6ftOt5ExjLBK2bFnq56 nObPO+Xf12S3QEg8Cc/n8m9BMaD+noPvZ1MWeFe7A0CeeRhNeqmDzLPOnJ867icnr0Q5 KOFq4dF4bA7aV/eaSvjc0clB0V54yQs/pKaK0UNm8rDmeAX2ztO7nZ71Xf8opyfcIppN VxZg== X-Gm-Message-State: AOAM533AnNUiTZJrtf1pVnBqggig3npzMG4I48bQs+c4J2yIJkrqjQQ5 dmhB15xvvTfKQeUn4zxljpuLUh7uiSkmfPJfakvAQhtC2Kg7 X-Google-Smtp-Source: ABdhPJyaaUJTido/V14wtgQUks1ydomtPxBkgceON308EoGeiEdmstq25N32cJDlisxjoeccPw/y5jYf505wIrunHxU= X-Received: by 2002:a92:cacf:: with SMTP id m15mr15923197ilq.34.1593763128490; Fri, 03 Jul 2020 00:58:48 -0700 (PDT) MIME-Version: 1.0 References: <CAK=yUGLoM1YWX5yxsboKqaCMr2jKGgtJ0a-CVVsfeEO3SpsYLQ@mail.gmail.com> <ef01153a05887b10a443c71cb42aff6180ae7f8f.camel@freebsd.org> <CAK=yUGLvZ7uM=pTNrODnTgw6NStT4gHExsTDkrYTP_rQBV1C-A@mail.gmail.com> <28698f3e3db608dceee910a8ba62ad7b6be0769f.camel@freebsd.org> <CAK=yUG+A3n-dSHg0w1mJ141njwb4uE=oeUTab6pCMRM924Dhjw@mail.gmail.com> <f3b1ae0198d83294b46a2b93b085ad75509e8bcd.camel@freebsd.org> In-Reply-To: <f3b1ae0198d83294b46a2b93b085ad75509e8bcd.camel@freebsd.org> Reply-To: kamalp@acm.org From: "Kamal R. Prasad" <kamalpr@gmail.com> Date: Fri, 3 Jul 2020 13:28:37 +0530 Message-ID: <CAK=yUGJxr8Vryo6a52o2Zh=ov-WCBKipBcTvxkVf7bqUREpGBg@mail.gmail.com> Subject: Re: cv_wait To: Ian Lepore <ian@freebsd.org> Cc: kamalp@acm.org, freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 49ynQz5Yb0z3fwj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>; List-Post: <mailto:freebsd-arm@freebsd.org> List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=subscribe> X-List-Received-Date: Fri, 03 Jul 2020 07:58:52 -0000 i implemented your suggestion nd when system ws going down, i got this stack trace lock order reversal: (sleepable after non-sleepable) 1st 0xffff000001302990 umtxql (umtxql) @ /b/kamal/stable11/src/sys/kern/kern_umtx.c:499 2nd 0xffff000001c656a0 allproc (allproc) @ /b/kamal/stable11/src/sys/kern/kern_proc.c:399 stack backtrace: #0 0xffff0000001d54d0 at witness_debugger+0x58 #1 0xffff000000181514 at _sx_slock+0x6c #2 0xffff000000163efc at pget+0x38 #3 0xffff00000018ce54 at kern_clock_gettime+0x3cc #4 0xffff00000019c2bc at do_sem2_wait+0x494 #5 0xffff00000019cc7c at __umtx_op_sem2_wait_compat32+0x80 #6 0xffff0000002e2f90 at do_el0_sync+0x9c8 #7 0xffff0000002c8200 at handle_el0_sync+0x84 thanks -kamal On Fri, Jul 3, 2020 at 1:15 AM Ian Lepore <ian@freebsd.org> wrote: > On Fri, 2020-07-03 at 00:52 +0530, Kamal R. Prasad wrote: > > witness threw a panic saying that there is a potential deadlock. I > > dont > > have the exact msg as I changed the algo and lost the console logs. > > the common code has a mtx_lock() and mtx_unlock() to guard against > > race > > conditions. > > i just want to use a synchrnization primitive that will not hold any > > locks > > when calling the common code from the cs. > > so, pl feel free to suggest any alernativves. > > > > thanks > > -kamal > > > > Maybe an sxlock is what you're looking for. > > void function1() > { > sx_xlock(&sc->cs_lock); > common_func(); > sx_unlock(&sc->cs_lock); > } > > void function2() > { > sx_xlock(&sc->cs_lock); > common_func(); > sx_unlock(&sc->cs_lock); > } > > That would ensure that only one caller at a time is in the critical > section that calls common_func() (if it's just common_func() that > needs protecting, I'd put the sx_xlock in there). But I'm not sure how > that's different than using a standard mutex, unless your common code > was trying to sleep (or use malloc with WAIT_OK). If using a standard > mutex caused witness to warn about an unbounded sleep while holding a > mutex, then using the sxlock should fix that. > > Also, you should look at 'man locking' if you haven't already. > > -- Ian > > > > > > > On Fri, Jul 3, 2020 at 12:37 AM Ian Lepore <ian@freebsd.org> wrote: > > > > > On Fri, 2020-07-03 at 00:36 +0530, Kamal R. Prasad wrote: > > > > but if i am doing cv_wait() for the first time, should someone be > > > > calling cv_signal for it to proceed? > > > > my algo is something like this in my driver:- > > > > function1() > > > > { > > > > mtx_lock(&sc->sc_mtx); > > > > cv_wait(&sc->sc_cv); > > > > mtx_unlock(&sc->sc_mtx); > > > > .... > > > > critical section > > > > .... > > > > cv_signal(&sc->sc_cv); > > > > } > > > > > > > > function2() > > > > { > > > > mtx_lock(&sc->sc_mtx); > > > > cv_wait(&sc->sc_cv); > > > > mtx_unlock(&sc->sc_mtx); > > > > .... > > > > critical section > > > > .... > > > > cv_signal(&sc->sc_cv); > > > > } > > > > --------------------- > > > > i want to protect critical section. The critical section calls a > > > > common > > > > piece of code which has some locks. if i put in locks to guard > > > > the > > > > cs, it > > > > triggers a call to witness(). > > > > > > > > Update: i saw an implementation wherein they used a callout to > > > > periodically > > > > send a cv_signal(). i could do that but the pt of this > > > > implementation > > > > is > > > > that cs in either of these functions should not be eecuting at > > > > the > > > > same > > > > time. > > > > > > > > thanks > > > > -kamal > > > > > > > > > > A condition variable doesn't work the way you're trying to use it. > > > > > > What is the complaint from witness? What type of locks are used in > > > the > > > common code that causes a complaint? Are any of these functions > > > involved called from interrupt handlers (that also imposes > > > restrictions > > > on what kind of locking you can do)? > > > > > > -- 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" > > > > > _______________________________________________ > 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?173115808d3.f2327534108660.257113843983027589>