From owner-freebsd-arm@freebsd.org Sun Sep 24 04:32:29 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6967E1EAF2 for ; Sun, 24 Sep 2017 04:32:29 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 570F069486 for ; Sun, 24 Sep 2017 04:32:29 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id m199so4060675lfe.3 for ; Sat, 23 Sep 2017 21:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DjyrRBsMQoHMLgW58bP8SuhNS8wKuH/eOpE3OmzE3rQ=; b=GFK5aM3SYyL3exRJ+Dx2dUdX06wqruvzxh93gxhvBojqvlnhZRSjKUwz2rjvnmPuO8 b2hJJUVDcVg4+Ce0oUFwXgHzZzFID8OAy99ZEdhamOTWmI/sl7HdbK0zkmOge5CcLzzt 666cU5W2l+tgH4t0js0xVhh1eXhqeMMznM6zAid6QoWOdagmnAsZMWswd0o1HfM/yAFq +aw/8AqS2LE6/o3umOS/xLjEC3Um7DmPawQzq7ILIM72dpV2xqMretEM2B/z+8Cg9Roa vkVsHxdsX8RFfK1YBamF6hhuLsbFbPffFl7mpFKMzlSweI2I8VZ7NExO7qee++LMXP2z pA+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DjyrRBsMQoHMLgW58bP8SuhNS8wKuH/eOpE3OmzE3rQ=; b=T8KQksDOnRKLps9VvrPciKM2NSWrPamMOwE/h7em40Sh7PzKxbkHGycxdcwCP7dzPf QseXZNNjUE8PbHqgBMl/jUN0q6Enk6qAya2sQutEqMC4jx+Uy+cTeI4DkHqDNhwkf7+S LvVBY/5OyWnQsW/WRU4SfHPnooUSW5w7UOCgfFcUdlu/XrUytHmutzqIoFNNf/2YdzAZ vcqeFQ4rhwuBNHyKPev2eOBiIXs7sYhdPMr+TQVe11q9b6QJnzyzpCGgMJH5np4uEYhD SFo4TpecAraPwCV+5yRLprzeFcTu52oczBI3lEUpkDUMEugZrYG3uPFynFSYgO0nDY/q I9vA== X-Gm-Message-State: AHPjjUi0/xxyYvGmiPvAg19gMq3hfUiwdDz8NtfsDcah/L3lDFihUkd/ 5TbMMEg/u3mDtjNGmWRhOwAXQMV/xgZ1UspIx5MehA== X-Google-Smtp-Source: AOwi7QBx1LCfHtR2c55LfXPXgXJUGRrwRTrv5uuV2P9dPbjsaUWHTafBFzENkaUDyfAFmPPJT4HkOzg3AlxL1/VT/rM= X-Received: by 10.25.202.12 with SMTP id a12mr1185545lfg.54.1506227547052; Sat, 23 Sep 2017 21:32:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Sat, 23 Sep 2017 21:32:26 -0700 (PDT) In-Reply-To: References: <40EA308E-489D-4A0B-B75A-2CA5A4EC474E@theory14.net> <685d0eed3532a34f239e7ff893f817db@bakulin.de> <20170905141711.6545490.14963.31294@gmail.com> <656A5193-7389-476C-AF58-EB013E9155F3@theory14.net> From: Russell Haley Date: Sat, 23 Sep 2017 21:32:26 -0700 Message-ID: Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP? To: Chris Gordon Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 04:32:29 -0000 On Thu, Sep 7, 2017 at 12:03 AM, Russell Haley wrote= : > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221845#c3 > > I've been following the code through and wound up at > sys/arm/ti/cpsw/if_cpsw.c. cpsw_intr_rx [which] is defined on line > 1554. The function uses a macro called CPSW_RX_LOCK which is defined > on line 349. The macro contains an assert on a transmit lock > (tx.lock). I theorise the statement on line 350 is causing my > exception? I also wonder if the lock being held between lines 1561 and > 1570 is causing the delay in the bridge interface that is causing the > original posters' slow throughput. Is it necessary to hold the lock > until after the cpsw_write_4 on line 1569 or could it be performed > outside the lock? Well, for what it's worth, Debian on my BBB doesn't think much of my wifi adapter much either: [ 480.532193] INFO: task ifconfig:1369 blocked for more than 60 seconds. [ 480.539231] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 480.547647] Kernel panic - not syncing: hung_task: blocked tasks [ 480.554065] [] (unwind_backtrace+0x1/0x9c) from [] (panic+0x59/0x15c) [ 480.562746] [] (panic+0x59/0x15c) from [] (watchdog+0x19d/0x1c0) [ 480.570972] [] (watchdog+0x19d/0x1c0) from [] (kthread+0x6b/0x78) [ 480.579294] [] (kthread+0x6b/0x78) from [] (ret_from_fork+0x11/0x34) [ 480.587874] drm_kms_helper: panic occurred, switching back to text conso= le Russ > > zzz, > Russ > > On Wed, Sep 6, 2017 at 5:13 PM, Russell Haley wrot= e: >> On Wed, Sep 6, 2017 at 3:30 PM, Chris Gordon wrot= e: >>> Russ, >>> >>>> Have you monitored your system on a serial console or direct console >>>> (i.e. via hdmi/keyboard)? Is the system still responding to other >>>> commands after you run the speed test? My thought is that the really >>>> really low bandwidth belies a kernel panic on the main terminal that >>>> you are not seeing. >>> >>> I have a serial console connected the entire time along with ssh sessio= ns (via wired NIC) into the BBB. There is no panic other other messages on= the console. The devices remains responsive to user input/actions via ssh= . In a previous reply to my initial inquiry, Ilya Bakulin asked about outpu= t from "top -Sa=E2=80=9D thinking the CPU was overwhelmed. The system stay= s at >90% idle through the entire test (upload and download). I see 2-4% W= CPU for interrupts and 1-2% for USB. >> >> Good, thanks for clarifying. >> >>>> If you would like to do some further testing, you could perhaps help >>>> me answer these things: >>> >>> It won=E2=80=99t be until next week when I can look at any of these. I= =E2=80=99m one of the organizers at vBSDcon and will be at the Dev Summit a= nd conference through the weekend. If anyone is interested, I=E2=80=99m ha= ppy to bring my BBB there for debugging/testing on site. >> >> Argh! I was just in Maryland and we flew home from Dulles!!! I made >> the client push the date forward to last week so I could be home for >> Labour Day. >> >> Have fun! (sob, sob, sob). ;) >> >>>> - Can you find a command line way of measuring throughput and latency >>>> separately that can be run on a host and on the bbb? I'm sure there >>>> are lots of ways to do so. I will leave it up to you to decide and >>>> will adopt the same tests so we can compare results. >>> >>> I just have to find another device -- I have everything wired here othe= r than i-devices. I used nuttcp for testing the wired connection, so I wou= ld plan to use that for the Wifi. >> >> nuttcp. Got it, I'll start playing with it. >> >>>> - Can you run the bbb as a standard device (not an access point) and >>>> test the performance of the wlan0 interface using the method of >>>> measurement pointed above? I will do the same at some point with my >>>> wi-fi dongle. >>> >>> Yes, that should be easy to do, but will be next week before I have a c= hance. >>> >>>> Some tests I would like to do: >>>> - Get DTrace involved as a debugging tool. I have rudimentary DTrace >>>> skills but will need to consult my books on how to measure throughput >>>> and latency. There are some examples early in the DTrace book of >>>> logging system calls made by a process and I will review that again >>>> when time permits. >>>> - Run the system through the kernel debugger. I think this is going to >>>> be difficult though as pausing the kernel in the middle of TCP traffic >>>> might invalidate any results I get. I know how difficult it can be to >>>> debug threaded applications, I can't see a kernel being any easier. ;) >>> >>> I was thinking along the same lines and hampered only by lack of time a= nd specific knowledge of what to start poking (of course, this is a great w= qy to learn!). >> >> My random thought of the day is that the "down/receive" from eth0 to >> wlan0 is working somewhat correctly, but the "up/send" from wlan0 to >> eth0 is causing issues. This is coming from your throughput notes, and >> the fact I got a whole page downloaded, but received a panic when I >> was trying to request another page. My thought is to start looking at >> the send commands for wlan0 and USB. >> >>> Thanks for your help. I=E2=80=99ll get some info as soon as I can. An= ything important I=E2=80=99ll add to the bug report. >> >> Thanks for having a fun problem to play with! Good luck with the >> conference and don't worry about time, I have 3 other things that I >> started this week alone. Anyone want to test a prototype Lua database? >> lolz. >> >> Russ From owner-freebsd-arm@freebsd.org Sun Sep 24 05:10:21 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 841FDE1F40F for ; Sun, 24 Sep 2017 05:10:21 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E28B96A1C9 for ; Sun, 24 Sep 2017 05:10:20 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x22d.google.com with SMTP id m199so4087149lfe.3 for ; Sat, 23 Sep 2017 22:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=w9cYJBgG94x2+43Zt2VmKdzklhhp88i7P2fhUIVafbI=; b=t03eeQnpPpgJeY73fXUyijC4UEm3OGHnT7CywYaL0WUE4mwCEtMs/0167D1Jza4PqW f/T5Gm2BDMsHwU3LjntPwBwSUxWJDULUKmbKwRcRtB+zqm07+rIsGxY92IDLczmq5ES0 pY7cc80JU6GSjjRs2dMv1K1sOheUzstT8yt2iYNhoNaaQvRQZfQXnXa/7MYxSZMkdFQn DwuOZe75cWnTevfRkFASuBDF0Yt6OxR6ldtfkuKUx/TorCGFUTPspoyQkCK5YD9Kwf0r v46QAS4CSDMyaV9eMJSMwNAuaqBxdHBGEbpp6X9FDkB7b/DUsZiTU5g36mNrIAtt3J2x Yi4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=w9cYJBgG94x2+43Zt2VmKdzklhhp88i7P2fhUIVafbI=; b=Nfia2Z6JBjvYBhHFGZjrwUrF1S0FzCgA3JFbMDNyQWxzcr721VxZBOqqEvD0vDXvEq 9LhqwMjkS1AU8cPGuCU1Lv4PtcClmLPQ0PLuuGyHdx5mWMyZNsMZYi8uU/1OkvOcbElB W+7jqk07wri6gkRhHtagrZX8BaIZ6Tf/ihpi49X/EEJZlO5q7LzFBVqoBdK5w4kuGH6l d1F9ibaPux6fD9BWTK89U0DCsMf7EqIcaTh/X7ASOtDw32zKhg6s3OVyu5D+EATzoYw0 GAR3mM3aOblMaYQ7Witg2ieQGzvXdO7WMOrwwFXVJCUQ+PscePUcef2qgNBkFGX0Xs/g udAQ== X-Gm-Message-State: AHPjjUhgjlb3mgpg2+6ded0DmYpGsB/No5douMD3WUFb2jxO7K8paUke yiE70mHBePMBtEjnvh2TsLxvkOxodplgxKcjYOWJtw== X-Google-Smtp-Source: AOwi7QCbVlb4s5wu8ZmMG0//JFpYTammUN7I/73+YFs32cAnUzaTa1aNr9ShnC76johhc2KxH7JilcdPnW5DDpaoYnk= X-Received: by 10.25.81.85 with SMTP id f82mr1114778lfb.70.1506229818801; Sat, 23 Sep 2017 22:10:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Sat, 23 Sep 2017 22:10:17 -0700 (PDT) In-Reply-To: References: <40EA308E-489D-4A0B-B75A-2CA5A4EC474E@theory14.net> <685d0eed3532a34f239e7ff893f817db@bakulin.de> <20170905141711.6545490.14963.31294@gmail.com> <656A5193-7389-476C-AF58-EB013E9155F3@theory14.net> From: Russell Haley Date: Sat, 23 Sep 2017 22:10:17 -0700 Message-ID: Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP? To: Chris Gordon Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 05:10:21 -0000 Hi, First off, I understand my RT3052 may not be considered a well supported chipset. However, I thought I'd run a comparison on the BBB using GNU/Linux. Once I got the adapter working (RT3052) under Debian Jessie I started doing the same tests against my TrueOS amd64 machine: #FreeBSD client (wired, 100 Mbps) -> Debian server (BBB, Wifi) russellh@prescott:~% nuttcp -i 1 192.168.2.62 2.1250 MB / 1.00 sec =3D 17.7976 Mbps 3.8750 MB / 1.00 sec =3D 32.4830 Mbps 3.5000 MB / 1.00 sec =3D 29.4280 Mbps 3.0000 MB / 1.00 sec =3D 25.1649 Mbps 3.0000 MB / 1.00 sec =3D 25.1623 Mbps 2.9375 MB / 1.00 sec =3D 24.6420 Mbps 2.9375 MB / 1.00 sec =3D 24.6355 Mbps 3.3125 MB / 1.00 sec =3D 27.7635 Mbps 3.1875 MB / 1.00 sec =3D 26.7693 Mbps 1.3125 MB / 1.00 sec =3D 11.0108 Mbps 29.8267 MB / 10.39 sec =3D 24.0905 Mbps 0 %TX 18 %RX 176 host-retrans 2.04 msRTT #Debian client (BBB, Wifi) -> FreeBSD server (wired, 100 Mbps) debian@beaglebone:~$ nuttcp -i 1 -r 192.168.2.47 2.9375 MB / 1.00 sec =3D 24.6398 Mbps 3.5000 MB / 1.00 sec =3D 29.3551 Mbps 3.5000 MB / 1.00 sec =3D 29.3135 Mbps 3.7500 MB / 1.00 sec =3D 31.4984 Mbps 4.0000 MB / 1.00 sec =3D 33.5589 Mbps 3.9375 MB / 1.00 sec =3D 33.0372 Mbps 3.6875 MB / 1.00 sec =3D 30.9209 Mbps 3.6875 MB / 1.00 sec =3D 30.9398 Mbps 3.4375 MB / 1.00 sec =3D 28.8192 Mbps 3.4375 MB / 1.00 sec =3D 28.7767 Mbps 36.5883 MB / 10.15 sec =3D 30.2344 Mbps 0 %TX 20 %RX 0 host-retrans 1.31 msRTT For what it's worth, Russ On Sat, Sep 23, 2017 at 9:32 PM, Russell Haley wrote= : > On Thu, Sep 7, 2017 at 12:03 AM, Russell Haley wro= te: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221845#c3 >> >> I've been following the code through and wound up at >> sys/arm/ti/cpsw/if_cpsw.c. cpsw_intr_rx [which] is defined on line >> 1554. The function uses a macro called CPSW_RX_LOCK which is defined >> on line 349. The macro contains an assert on a transmit lock >> (tx.lock). I theorise the statement on line 350 is causing my >> exception? I also wonder if the lock being held between lines 1561 and >> 1570 is causing the delay in the bridge interface that is causing the >> original posters' slow throughput. Is it necessary to hold the lock >> until after the cpsw_write_4 on line 1569 or could it be performed >> outside the lock? > > Well, for what it's worth, Debian on my BBB doesn't think much of my > wifi adapter much either: > > [ 480.532193] INFO: task ifconfig:1369 blocked for more than 60 seconds. > [ 480.539231] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 480.547647] Kernel panic - not syncing: hung_task: blocked tasks > [ 480.554065] [] (unwind_backtrace+0x1/0x9c) from > [] (panic+0x59/0x15c) > [ 480.562746] [] (panic+0x59/0x15c) from [] > (watchdog+0x19d/0x1c0) > [ 480.570972] [] (watchdog+0x19d/0x1c0) from [] > (kthread+0x6b/0x78) > [ 480.579294] [] (kthread+0x6b/0x78) from [] > (ret_from_fork+0x11/0x34) > [ 480.587874] drm_kms_helper: panic occurred, switching back to text con= sole > > Russ > >> >> zzz, >> Russ >> >> On Wed, Sep 6, 2017 at 5:13 PM, Russell Haley wro= te: >>> On Wed, Sep 6, 2017 at 3:30 PM, Chris Gordon wro= te: >>>> Russ, >>>> >>>>> Have you monitored your system on a serial console or direct console >>>>> (i.e. via hdmi/keyboard)? Is the system still responding to other >>>>> commands after you run the speed test? My thought is that the really >>>>> really low bandwidth belies a kernel panic on the main terminal that >>>>> you are not seeing. >>>> >>>> I have a serial console connected the entire time along with ssh sessi= ons (via wired NIC) into the BBB. There is no panic other other messages o= n the console. The devices remains responsive to user input/actions via ss= h. In a previous reply to my initial inquiry, Ilya Bakulin asked about outp= ut from "top -Sa=E2=80=9D thinking the CPU was overwhelmed. The system sta= ys at >90% idle through the entire test (upload and download). I see 2-4% = WCPU for interrupts and 1-2% for USB. >>> >>> Good, thanks for clarifying. >>> >>>>> If you would like to do some further testing, you could perhaps help >>>>> me answer these things: >>>> >>>> It won=E2=80=99t be until next week when I can look at any of these. = I=E2=80=99m one of the organizers at vBSDcon and will be at the Dev Summit = and conference through the weekend. If anyone is interested, I=E2=80=99m h= appy to bring my BBB there for debugging/testing on site. >>> >>> Argh! I was just in Maryland and we flew home from Dulles!!! I made >>> the client push the date forward to last week so I could be home for >>> Labour Day. >>> >>> Have fun! (sob, sob, sob). ;) >>> >>>>> - Can you find a command line way of measuring throughput and latency >>>>> separately that can be run on a host and on the bbb? I'm sure there >>>>> are lots of ways to do so. I will leave it up to you to decide and >>>>> will adopt the same tests so we can compare results. >>>> >>>> I just have to find another device -- I have everything wired here oth= er than i-devices. I used nuttcp for testing the wired connection, so I wo= uld plan to use that for the Wifi. >>> >>> nuttcp. Got it, I'll start playing with it. >>> >>>>> - Can you run the bbb as a standard device (not an access point) and >>>>> test the performance of the wlan0 interface using the method of >>>>> measurement pointed above? I will do the same at some point with my >>>>> wi-fi dongle. >>>> >>>> Yes, that should be easy to do, but will be next week before I have a = chance. >>>> >>>>> Some tests I would like to do: >>>>> - Get DTrace involved as a debugging tool. I have rudimentary DTrace >>>>> skills but will need to consult my books on how to measure throughput >>>>> and latency. There are some examples early in the DTrace book of >>>>> logging system calls made by a process and I will review that again >>>>> when time permits. >>>>> - Run the system through the kernel debugger. I think this is going t= o >>>>> be difficult though as pausing the kernel in the middle of TCP traffi= c >>>>> might invalidate any results I get. I know how difficult it can be to >>>>> debug threaded applications, I can't see a kernel being any easier. ;= ) >>>> >>>> I was thinking along the same lines and hampered only by lack of time = and specific knowledge of what to start poking (of course, this is a great = wqy to learn!). >>> >>> My random thought of the day is that the "down/receive" from eth0 to >>> wlan0 is working somewhat correctly, but the "up/send" from wlan0 to >>> eth0 is causing issues. This is coming from your throughput notes, and >>> the fact I got a whole page downloaded, but received a panic when I >>> was trying to request another page. My thought is to start looking at >>> the send commands for wlan0 and USB. >>> >>>> Thanks for your help. I=E2=80=99ll get some info as soon as I can. A= nything important I=E2=80=99ll add to the bug report. >>> >>> Thanks for having a fun problem to play with! Good luck with the >>> conference and don't worry about time, I have 3 other things that I >>> started this week alone. Anyone want to test a prototype Lua database? >>> lolz. >>> >>> Russ From owner-freebsd-arm@freebsd.org Sun Sep 24 20:29:50 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E55F9E006F0 for ; Sun, 24 Sep 2017 20:29:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-74.reflexion.net [208.70.210.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A8D922007 for ; Sun, 24 Sep 2017 20:29:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20065 invoked from network); 24 Sep 2017 20:29:42 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 24 Sep 2017 20:29:42 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 24 Sep 2017 16:29:42 -0400 (EDT) Received: (qmail 11075 invoked from network); 24 Sep 2017 20:29:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Sep 2017 20:29:42 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id C27E4EC770C; Sun, 24 Sep 2017 13:29:41 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r323676 and ports -r450478 audio/liba52 for arm.armv6 (cortex-a7): unresolvable R_ARM_MOVW_ABS_NC relocation against symbol `__stderrp@@FBSD_1.0' Message-Id: Date: Sun, 24 Sep 2017 13:29:40 -0700 To: FreeBSD Toolchain , freebsd-arm X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 20:29:51 -0000 My prodriere amd64 -> armv6 (cortex-a7) cross build of some ports based based on /usr/ports/ -r450478 and head -r323676 got: (cd . && ln -s parse.o parse.lo) /bin/sh ../libtool --mode=3Dlink /nxb-bin/usr/bin/cc -pipe = -mcpu=3Dcortex-a7 -g -fno-strict-aliasing -O2 -pipe = -fomit-frame-pointer -prefer-non-pic -o liba52.la -rpath = /usr/local/lib -no-undefined bitstream.lo imdct.lo bit_allocate.lo = parse.lo downmix.lo -lm=20 rm -fr .libs/liba52.la .libs/liba52.* .libs/liba52.* /nxb-bin/usr/bin/cc -shared bitstream.lo imdct.lo bit_allocate.lo = parse.lo downmix.lo -lm -Wl,-soname -Wl,liba52.so.0 -o = .libs/liba52.so.0.0.0 /nxb-bin/usr/bin/ld: imdct.lo(.text+0x890): unresolvable = R_ARM_MOVW_ABS_NC relocation against symbol `__stderrp@@FBSD_1.0' /nxb-bin/usr/bin/ld: final link failed: Nonrepresentable section on = output cc: error: linker command failed with exit code 1 (use -v to see = invocation) gmake[2]: *** [Makefile:196: liba52.la] Error 1 gmake[2]: Leaving directory = '/wrkdirs/usr/ports/audio/liba52/work/a52dec-0.7.4/liba52' gmake[1]: *** [Makefile:152: all-recursive] Error 1 gmake[1]: Leaving directory = '/wrkdirs/usr/ports/audio/liba52/work/a52dec-0.7.4' =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/audio/liba52 =3D>> Cleaning up wrkdir =3D=3D=3D> Cleaning for liba52-0.7.4_3 build of audio/liba52 | liba52-0.7.4_3 ended at Sun Sep 24 02:28:37 PDT = 2017 build time: 00:01:15 !!! build failure encountered !!! I was updating from an earlier version of /usr/ports (-r449363 ?). Note: audio/liba52 was indirectly built by something else requiring it. Ultimately it traces back to my trying to build x11/lumina explicitly and it in turn needing the likes of audio/gstreamer1-plugins-a52dec via multimedia/gstreamer1-plugins-core . # uname -apKU FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT r323676M amd64 = amd64 1200044 1200044 # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 450478 Last Changed Rev: 450478 # diff /usr/local/etc/poudriere.conf = /usr/local/etc/poudriere.conf.sample 13d12 < ZPOOL=3DzrFBSDx64C 31,32c30 < #FREEBSD_HOST=3D_PROTO_://_CHANGE_THIS_ < FREEBSD_HOST=3Dftp://ftp.freebsd.org --- > FREEBSD_HOST=3D_PROTO_://_CHANGE_THIS_ 168d165 < SAVE_WRKDIR=3Dyes 195d191 < ALLOW_MAKE_JOBS=3Dyes 201d196 < ALLOW_MAKE_JOBS_PACKAGES=3D"pkg ccache py* gcc* llvm* ghc* *webkit* = *office* chromium* iridium* mongodb*" 258d252 < BUILDER_HOSTNAME=3DAzrFBSDx64CjailVariant 270d263 < BUILD_AS_NON_ROOT=3Dno (Actually I changed the BUILDER_HOSTNAME since the build.) # more /usr/local/etc/poudriere.d/make.conf WANT_QT_VERBOSE_CONFIGURE=3D1 # DEFAULT_VERSIONS+=3Dperl5=3D5.24 gcc=3D7 # # =46rom a local /usr/ports/Mk/bsd.port.mk extension: ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=3D # .if ${.CURDIR:M*/devel/llvm*} #WITH_DEBUG=3D .elif ${.CURDIR:M*/www/qt5-webkit*} #WITH_DEBUG=3D .else WITH_DEBUG=3D .endif MALLOC_PRODUCTION=3D # more /usr/local/etc/poudriere.d/zrFBSDx64CjailArmV7-make.conf CFLAGS+=3D -mcpu=3Dcortex-a7 CXXFLAGS+=3D -mcpu=3Dcortex-a7 CPPFLAGS+=3D -mcpu=3Dcortex-a7 # svnlite status /usr/ports/=20 M /usr/ports/Mk/bsd.port.mk M /usr/ports/base/gcc/Makefile M /usr/ports/base/gcc/distinfo M /usr/ports/base/gcc/pkg-plist M /usr/ports/devel/libunwind/Makefile M /usr/ports/sysutils/cdrdao/Makefile (Yes: poudriere's build is based on that.) # svnlite diff /usr/ports/Mk/bsd.port.mk Index: /usr/ports/Mk/bsd.port.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/ports/Mk/bsd.port.mk (revision 450478) +++ /usr/ports/Mk/bsd.port.mk (working copy) @@ -1130,12 +1130,12 @@ =20 # Get the operating system type .if !defined(OPSYS) -OPSYS!=3D ${UNAME} -s +OPSYS!=3D echo FreeBSD .endif _EXPORTED_VARS+=3D OPSYS =20 .if !defined(_OSRELEASE) -_OSRELEASE!=3D ${UNAME} -r +_OSRELEASE!=3D echo 12.0-CURRENT .endif _EXPORTED_VARS+=3D _OSRELEASE =20 @@ -1651,7 +1651,11 @@ STRIP_CMD=3D ${TRUE} .endif DEBUG_FLAGS?=3D -g +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG) +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} +.else CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} +.endif .if defined(INSTALL_TARGET) INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} .endif (I've had problems with the ${UNAME} notation ending up with empty string results. Thus my forcing the FreeBSD and 12.0-CURRENT that are listed. But the real point of the above is the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG use.) The poudriere jail was built via: poudriere jail -c -j zrFBSDx64CjailArmV7 -a arm.armv6 -x -m null -M = /usr/obj/DESTDIRs/clang-armv7-installworld-poud -S /usr/src -v = 12.0-CURRENT but in order to do this I've updated by adding a build_native_xtools to an FCT assignment . . . /usr/local/share/poudriere/jail.sh : null) JAILFS=3Dnone FCT=3Dbuild_native_xtools ;; The bulk build was started with: # poudriere bulk -j zrFBSDx64CjailArmV7 -w -f /root/armv7-origins.txt [00:00:00] Cross-building ports for arm.armv6 on amd64 requires QEMU [00:00:00] Creating the reference jail... done [00:00:04] Mounting system devices for zrFBSDx64CjailArmV7-default [00:00:04] Mounting ports/packages/distfiles [00:00:04] Stashing existing package repository [00:00:04] Mounting packages from: = /usr/local/poudriere/data/packages/zrFBSDx64CjailArmV7-default [00:00:04] Copying /var/db/ports from: = /usr/local/etc/poudriere.d/options [00:00:04] Setting up native-xtools environment in jail... done [00:00:04] Raising MAX_EXECUTION_TIME and NOHANG_TIME for QEMU [00:00:04] Copying latest version of the emulator from: = /usr/local/bin/qemu-arm-static [00:00:04] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf [00:00:04] Appending to make.conf: = /usr/local/etc/poudriere.d/zrFBSDx64CjailArmV7-make.conf /etc/resolv.conf -> = /usr/local/poudriere/data/.m/zrFBSDx64CjailArmV7-default/ref/etc/resolv.co= nf [00:00:04] Starting jail zrFBSDx64CjailArmV7-default [00:00:04] Logs: = /usr/local/poudriere/data/logs/bulk/zrFBSDx64CjailArmV7-default/2017-09-24= _02h20m59s [00:00:04] Loading MOVED [00:00:04] Ports supports: DEPENDS_ARGS SELECTED_OPTIONS [00:00:04] Gathering ports metadata [00:00:06] Calculating ports order and dependencies [00:00:06] Sanity checking the repository [00:00:06] Checking packages for incremental rebuild needs [00:00:08] Deleting stale symlinks... done [00:00:08] Deleting empty directories... done [00:00:08] Cleaning the build queue [00:00:08] Sanity checking build queue [00:00:08] Processing PRIORITY_BOOST [00:00:08] Balancing pool [00:00:08] Recording filesystem state for prepkg... done [00:00:08] Building 146 packages using 14 builders [00:00:08] Starting/Cloning builders . . . # more /root/armv7-origins.txt archivers/unzip archivers/zip benchmarks/bonnie benchmarks/bonnie++ benchmarks/iorate benchmarks/iozone benchmarks/randomio devel/dwarfdump devel/gdb devel/git-lite devel/kyua devel/patch devel/xtoolchain-llvm50 ftp/wget lang/gcc7 net/rsync ports-mgmt/bsdadminscripts2 ports-mgmt/pkg ports-mgmt/portlint ports-mgmt/portmaster ports-mgmt/poudriere-devel security/sudo sysutils/DTraceToolkit sysutils/bsdadminscripts sysutils/stress sysutils/u-boot-rpi2 sysutils/u-boot-sinovoip-bpi-m3 x11/lumina x11/xorg-minimal x11/xterm =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Sep 24 22:07:12 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 643C6E02615 for ; Sun, 24 Sep 2017 22:07:12 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 212A263DD7 for ; Sun, 24 Sep 2017 22:07:11 +0000 (UTC) (envelope-from brett@lariat.net) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id QAA05638; Sun, 24 Sep 2017 16:07:01 -0600 (MDT) Message-Id: <201709242207.QAA05638@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 24 Sep 2017 16:06:57 -0600 To: Marcin Wojtas , Russell Haley From: Brett Glass Subject: Re: ARM board recommendations with true GigE ports Cc: freebsd-arm In-Reply-To: References: <201709222206.QAA21968@mail.lariat.net> <07D27DD7-2434-4A2E-91CE-A05D12BBAC2A@netgate.com> <201709230004.SAA22590@mail.lariat.net> <4E771B56-D588-468E-AB60-35DB4DB31318@netgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 22:07:12 -0000 So, how would I obtain an image for the Solidrun "ClearFog" board (whose specs say it uses the Marvell ARMADA 88F628 SoC)? Is it supported by any of the snapshots of 11.1-RELEASE or 12.0-CURRENT? Or would I have to set up a development system to cross-compile? If there's no SD/MMC driver (as suggested by some of the messages earlier in the thread), what media would I use to boot the system and as mass storage? Is there better support for the "Macchiatobin" board, whose specs say it uses a "Marvell AMADA 8040"? --Brett Glass From owner-freebsd-arm@freebsd.org Mon Sep 25 00:07:44 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0D15E04DDC for ; Mon, 25 Sep 2017 00:07:44 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) (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 582306715D for ; Mon, 25 Sep 2017 00:07:43 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from [127.0.0.1] (torsrv1.snydernet.net [178.17.170.164]) (authenticated bits=0) by feynman.konjz.org (8.14.7/8.14.4) with ESMTP id v8P0wIh7079231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 24 Sep 2017 20:58:24 -0400 (EDT) (envelope-from george@ceetonetechnology.com) To: "freebsd-arm@freebsd.org" From: George Rosamond Subject: PocketBeagle released Message-ID: <2c7ff0a0-ec0b-aa07-5559-cf128586fe93@ceetonetechnology.com> Date: Mon, 25 Sep 2017 00:07:00 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 00:07:44 -0000 At NYC MakerFaire and spoke to one of the founders. He was very pleased on the continued *BSD focus on it. The PocketBeagle was released on Thursday (https://beagleboard.org/pocket/) with a similar chipset to the regular BeagleBones. It should work fine outside of a newer version of UBoot. None were available for sale, but there is free overnight delivery and they only cost ~$25. Side note: I'm surprised to hear how many they sell a month. I mentioned that having a small armv7 board that was consistent in its chipset, like with the BBBlack, makes porting efforts much easier to handle. If anyone devs want to speak with him one-on-one, ping me offline. He would likely assist on any level. g From owner-freebsd-arm@freebsd.org Mon Sep 25 06:59:59 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EACCE0C6C4; Mon, 25 Sep 2017 06:59:59 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 D26B070A4E; Mon, 25 Sep 2017 06:59:58 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: by mail-pf0-x231.google.com with SMTP id l188so3357753pfc.6; Sun, 24 Sep 2017 23:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=n5xYih4qjyOCnhg940T7Cr3r3tYWhzOkRzp0vlmz6Hk=; b=dxgP4Z/Qb7bOZ/EHSpGGNb6eKcHc7D7izIcrUR8hVpWDXaUCZptfshPyd8rAS8JVNh zRCM19mBL6b+qJjF7gIn85PdWAS2k9qO4769mD9TCr3ng9rPnZjMNjXXrNOFWZ5o7jdY bRAby1yaNJ/e3TZPStj5w+j7otlY+/SiD4stZkiMfMptuZYIKncEGMuO3icuwWBkdzgE Bsgs6AHLZC6H7x7zona/XhRP68EDqG7nMvirMBj/uaS2qUnlDdEAsSA7pIbrbfW3bYCQ AZplDFiiEf4U3EIUYDvJc9sWcyx9MV/aZqh2YTYuzFgJihvIrcpFtAzuyYHTd8XpZsUz SWnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=n5xYih4qjyOCnhg940T7Cr3r3tYWhzOkRzp0vlmz6Hk=; b=oLLNAwG+IE5SVjBSnmDVlsM8yP73Yg1CaRokKcwYnbxHigjiTghJKOdoIIO1MPb2NC uPEGRZCDilUCJ7l4LJh4k3egpgTK2H1b6wtr82hvc8VqdYyZ4YEkbTuOU/03Mukl5eEM 9mGqEEsgNmdy7qrMYe4V9RMLVYXVmqKQ74453t9MlOUKk1WAXdVn+kMhGl8SAydDqGrS aFcopzVWXt8AHLYgIEUFIf7eBcJRZnRJYWTEWWmoYldaXsbckeLbKVHZCuTgUihU7Y9h wtaJ82bhTagS2xLJdS7n6iZq7E6nc9SGNGYIKy3L3MsWC5RTI26mKdQ7TxFcFMXKYFKE C5Wg== X-Gm-Message-State: AHPjjUjxfpCpNNgnd440U3sxjrV+Jy/y5/vuDQ5E2lbO0sry6gTcVX8+ T5IOW1iX6c7XLt+o1GPJOC2IhVfHozyLU4UDkme9+eCi X-Google-Smtp-Source: AOwi7QDm21uSNfxXfOuJr/VlyItVXZh+aeAOtiBTSqLJKJ9BBxHNjnjqB3L3nbAkXZbwiJbDGPCUb6cgIyCYm14nbks= X-Received: by 10.99.63.135 with SMTP id m129mr6876286pga.207.1506322798358; Sun, 24 Sep 2017 23:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.168.1 with HTTP; Sun, 24 Sep 2017 23:59:18 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Mika=C3=ABl_Urankar?= Date: Mon, 25 Sep 2017 08:59:18 +0200 Message-ID: Subject: Re: head -r323676 and ports -r450478 audio/liba52 for arm.armv6 (cortex-a7): unresolvable R_ARM_MOVW_ABS_NC relocation against symbol `__stderrp@@FBSD_1.0' To: Mark Millard Cc: FreeBSD Toolchain , freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 06:59:59 -0000 2017-09-24 22:29 GMT+02:00 Mark Millard : > My prodriere amd64 -> armv6 (cortex-a7) cross build of > some ports based based on /usr/ports/ -r450478 and > head -r323676 got: > > (cd . && ln -s parse.o parse.lo) > /bin/sh ../libtool --mode=3Dlink /nxb-bin/usr/bin/cc -pipe -mcpu=3Dcorte= x-a7 -g -fno-strict-aliasing -O2 -pipe -fomit-frame-pointer -prefer-non-= pic -o liba52.la -rpath /usr/local/lib -no-undefined bitstream.lo imdct.lo= bit_allocate.lo parse.lo downmix.lo -lm > rm -fr .libs/liba52.la .libs/liba52.* .libs/liba52.* > /nxb-bin/usr/bin/cc -shared bitstream.lo imdct.lo bit_allocate.lo parse.= lo downmix.lo -lm -Wl,-soname -Wl,liba52.so.0 -o .libs/liba52.so.0.0.0 > /nxb-bin/usr/bin/ld: imdct.lo(.text+0x890): unresolvable R_ARM_MOVW_ABS_N= C relocation against symbol `__stderrp@@FBSD_1.0' > /nxb-bin/usr/bin/ld: final link failed: Nonrepresentable section on outpu= t > cc: error: linker command failed with exit code 1 (use -v to see invocati= on) > gmake[2]: *** [Makefile:196: liba52.la] Error 1 > gmake[2]: Leaving directory '/wrkdirs/usr/ports/audio/liba52/work/a52dec-= 0.7.4/liba52' > gmake[1]: *** [Makefile:152: all-recursive] Error 1 > gmake[1]: Leaving directory '/wrkdirs/usr/ports/audio/liba52/work/a52dec-= 0.7.4' > =3D=3D=3D> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failur= e to > the maintainer. > *** Error code 1 It seems similar to this bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215974 From owner-freebsd-arm@freebsd.org Mon Sep 25 10:58:53 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE6C8E10794; Mon, 25 Sep 2017 10:58:53 +0000 (UTC) (envelope-from dariusmihaim@gmail.com) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 9101876371; Mon, 25 Sep 2017 10:58:53 +0000 (UTC) (envelope-from dariusmihaim@gmail.com) Received: by mail-qt0-x22b.google.com with SMTP id q8so6376806qtb.5; Mon, 25 Sep 2017 03:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=QbuED/bRZHe/fZslbCvd/nUupxTpzWqZfiB/XWKkYCY=; b=ikI6uFLWC2IMXxgPQyL1SqswG1GKGLKwefnqpotExlkvhv8z6nUQecblkXmQNqIz6X 3tbl6Ol/rI2806v99asEMXqpQ2o1A1f25KxgU7On9kaZbINyQ5SJBkBpi4k6drb3Ntgz Tmu+bjv0QywxN9ZlyhLia23WmCg6OgQWapIfKFB4inF0VsdR7biG+RPwATkG/9WwWomS +067zK9DcYUCS0BsCWm1Iu0Kl1yayJnAbVYE+bH6zz59xjw+JG5fxv3HAmf3r64NwG6E oiepAhOD/HVYVmmLEu5RMkPgev1+4eMY5g/FQ822ktqHz2/H1DOSZs5vsvOxMik3olzX It7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QbuED/bRZHe/fZslbCvd/nUupxTpzWqZfiB/XWKkYCY=; b=DMm8omvd7uV462mzbtl+QAX3pkmaqJinBz5ZmnFDyPG5QUUPaIKZ2/nC/Dk5UngFL5 SexwEt8vK+rjisMK6T/Naint2VJrnF+BKH1B5G6Dw/B/8WBaWIBwG2IhZZZI7AcBo7nB p3Ro1rzb8ZoxDAeIUBqvUqmKMMJE4Va1XEfmi7GEdVLLaL81aKMVaDdzaM+OZZEapL7h cWdeDhLspIPlOhdkHpCY71FyfErrmXEHmW+U0xiCs4VsNalX8K5MZ7vi2kOPg6jPvjWU 29d6/PNzoxDL41/4Es6Dxgh8CABe0NB9yiVspXuBIkwzHBeW3sX9j6f4ecDRkbiSZbs8 8/Ww== X-Gm-Message-State: AHPjjUjufy8Qio7YwIq1Uzl5Y8e8PmPWbldzKdNuBGdH7XdnJI9ilzdg oOWM2JIekFe6b0eZKZqL7pwFNUO1b05hV2/FWEYPgA== X-Google-Smtp-Source: AOwi7QBwbmLv7kzyaueYJCKMMoyKCRMdaKfKp6aO0gTdQCWUrMkhABvfecSPDjlwdHDERoIYpcjGVfYJdYzvZR4WsO0= X-Received: by 10.200.34.167 with SMTP id f36mr10188498qta.173.1506337132522; Mon, 25 Sep 2017 03:58:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.47.171 with HTTP; Mon, 25 Sep 2017 03:58:52 -0700 (PDT) From: Darius Mihai Date: Mon, 25 Sep 2017 13:58:52 +0300 Message-ID: Subject: Cross-compiling socat To: freebsd-virtualization@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:58:54 -0000 Hello all, I am currently implementing the VirtIO devices for bhyve on ARM, more specifically the VirtIO-console device. However, I am stuck since I need to use 'socat' on the host, but cross-compiling always fails (the ports do not seem to have a straight-forward make system for cross-compiling as far as I could tell). I have tried using `./configure --host=amd64 --build=armv6 CC=arm-none-eabi-gcc`, in the 'work/socat-1.7.3.2' directory, but this doesn't seem to work. If anyone could provide any insight, it would be greatly appreciated. Have a nice day, Darius From owner-freebsd-arm@freebsd.org Tue Sep 26 03:40:05 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 735B6E2DDDC for ; Tue, 26 Sep 2017 03:40:05 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 42F307492B for ; Tue, 26 Sep 2017 03:40:04 +0000 (UTC) (envelope-from brett@lariat.net) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id VAA16701 for ; Mon, 25 Sep 2017 21:39:55 -0600 (MDT) Message-Id: <201709260339.VAA16701@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 25 Sep 2017 21:39:38 -0600 To: freebsd-arm@freebsd.org From: Brett Glass Subject: CUBOX snapshots working? Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 03:40:05 -0000 While waiting for the new SolidRun board I just ordered to come in, I decided to tinker with one of their older products: a CUBOX I2U-300-D. I downloaded the latest CUBOX snapshot (12.0 r323729), burned it onto an SD card, dropped the card into the box, plugged in an HDMI monitor, and watched the onboard serial port as I applied power. This is what I saw (on the serial port; the monitor stayed blank): U-Boot SPL 2017.07 (Sep 19 2017 - 23:14:46) Trying to boot from MMC1 U-Boot 2017.07 (Sep 19 2017 - 23:14:46 +0000) CPU: Freescale i.MX6D rev1.2 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 14C Reset cause: POR Board: MX6 Cubox-i DRAM: 1 GiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 ## Error: "boot¦md_mmc0" not defined ## Error: "boot¦md_usb0" not defined ## Error: "boot¦md_pxe" not defined ## Error: "boot¦md_dhcp" not defined ...and of course it didn't boot. Without the HDMI monitor plugged in, it failed with different errors, but still did not boot. What's the last good snapshot? --Brett Glass From owner-freebsd-arm@freebsd.org Tue Sep 26 04:38:36 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD236E2EA44 for ; Tue, 26 Sep 2017 04:38:36 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 58E4875C4D for ; Tue, 26 Sep 2017 04:38:36 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-wr0-x231.google.com with SMTP id k20so11285423wre.4 for ; Mon, 25 Sep 2017 21:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=voDwFx2kC9j0vLv5Ff6knWbMS36pNDd10mxLzMYvH7I=; b=his3iKvyXpCV3EPqgUd6x06pPt6HgAd+Gf8EBh+kABwry9KjHk54zEICO+IDU/yUEB 4//cAmZ90r46TEZZ/dZoCGcIlqNdRnOU2v27kMTQFTHx/+YawD4SnfTSDyniBfHZjCE1 oNogNlYYc5Fu7RlqlD8LbhGV0fleYxfyLopWgt7K9dTXWou/DbU1N3L5C002Irfb84Jj v8UcXd9brshBA1GkMUTUP4nEfTpPbA8WiAh74xawdLN1OEEZw2v3HFYnmZ8L/i/bnkAO gNJw8V8stIk+QjNAy91j5BPjz2zyFHJXZzyu70m3RSbP9Wq6YOS+BbDHt20FZYauOkMi FRqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=voDwFx2kC9j0vLv5Ff6knWbMS36pNDd10mxLzMYvH7I=; b=gXKmrzCg7E8YZlkzsNYoFk5+3du+yxaMLq+cW82Z7qYiq1exJIXPJEgAdZ0Yo+7ixn x86QeMc9vkBbnCsUtgXqSF7KtXhId5FqG8HAamtfEy8xrEO484ifoLOJqHiaRC3H0d6E 7M/p90WF0k8yDtuBo89jkcvqB8lhuthOjTbjIrQQhec8ajrX2+rgTRmI2SD3m2B0K5UK h5ZaN1Ehui85yIGxYWg5rv9FHya4/B0IDVlUTnufTZzcIkV2u1JqTuo/xlawlQDnBOZ2 hh/w8F9sm/MrFYLKzWdSynEgWPNM7lyPCkb7kiqlLVMb68VpUIzJKR8+KIK0lNSVFJcC bVCA== X-Gm-Message-State: AHPjjUjtKQYp+WRS21zOB2pjpUT3bN2eUmovVCDpgqHW9slGqYDw66LD 4fft0Ny9jt+x7tjZ316mRjZQnsbCKdeqLygkZ3xMqw== X-Google-Smtp-Source: AOwi7QDKqju52IaLnNcC+7jR71Z4+D8Y8LtptjAzW38bCH5MdDqHOaEDZq7EAOXpdBh40QNhNs8AmqNe1N6XZvzWNRo= X-Received: by 10.46.9.150 with SMTP id 144mr3496223ljj.30.1506400714191; Mon, 25 Sep 2017 21:38:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Mon, 25 Sep 2017 21:38:33 -0700 (PDT) From: Russell Haley Date: Mon, 25 Sep 2017 21:38:33 -0700 Message-ID: Subject: Why does this compile? To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 04:38:36 -0000 Hi, I'm trying to compile the new dotnet core 2.0 and I've run into a C problem I don't understand. Since I ran the code to check it on my arm board, I'm going to ask here (the most knowledgeable fbsd C people I could ask). The cmake file is trying to test for a linux struct in_pktinfo: check_c_source_compiles( " #include <${SOCKET_INCLUDES}> int main() { struct in_pktinfo; return 0; } " HAVE_IN_PKTINFO) SOCKET_INCLUDES resolves to netinet/in.h so the final source is: #include int main() { struct in_pktinfo; return 0; } This compiles on FreeBSD current and apparently on 11 too. That's a bad thing because it's supposed to fail. I checked in.h and there is no struct for in_pktinfo. Not surprisingly, if I remove the include altogether, it still compiles. I assume then that the original author made a mistake? My C is too weak and most of my searches don't turn up anything close to what I'm looking for. Any suggestions would be awesome. :) Thanks, Russ From owner-freebsd-arm@freebsd.org Tue Sep 26 04:55:45 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03456E2EE91 for ; Tue, 26 Sep 2017 04:55:45 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [207.172.210.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AEDF2762C4 for ; Tue, 26 Sep 2017 04:55:44 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:470:1f07:15ff::1f] (haymarket.m5p.com [IPv6:2001:470:1f07:15ff::1f]) (authenticated bits=0) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTPSA id v8Q4tIg1033977 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 26 Sep 2017 00:55:24 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: Why does this compile? To: freebsd-arm@freebsd.org References: From: George Mitchell Message-ID: <2b4d4179-9bda-c4ab-95af-5200463600cb@m5p.com> Date: Tue, 26 Sep 2017 00:55:11 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="chU1Pmv4FMIEBLRtL4DLfkWQ19nHDOQdt" X-Spam-Status: No, score=0.2 required=10.0 tests=HELO_MISC_IP, RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mattapan.m5p.com X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mailhost.m5p.com [IPv6:2001:470:1f07:15ff::f7]); Tue, 26 Sep 2017 00:55:24 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 04:55:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --chU1Pmv4FMIEBLRtL4DLfkWQ19nHDOQdt Content-Type: multipart/mixed; boundary="97LRdo9QePb0oTx6t3RmG0uqkkASoxVsT"; protected-headers="v1" From: George Mitchell To: freebsd-arm@freebsd.org Message-ID: <2b4d4179-9bda-c4ab-95af-5200463600cb@m5p.com> Subject: Re: Why does this compile? References: In-Reply-To: --97LRdo9QePb0oTx6t3RmG0uqkkASoxVsT Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 09/26/17 00:38, Russell Haley wrote: > [...] > #include >=20 > int main() > { > struct in_pktinfo; > return 0; > } > [...] This is a perfectly valid forward declaration of a struct type. In most normal cases, you would follow this up with something that contains a pointer to a thing of that type, and later a full declaration of the type. As it stands, though, it's simply a statement to the compiler that you are possibly using (and fully declaring) the structure type later on in your program. -- George --97LRdo9QePb0oTx6t3RmG0uqkkASoxVsT-- --chU1Pmv4FMIEBLRtL4DLfkWQ19nHDOQdt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAlnJ3bYACgkQwRES3m+p 4fnZww//bc8w36PcQw0KJeZ6a8DjSGuJ6bhNEJ7wT17Eb8+68mk2re5No8yYPXc0 LbvM1BSYlNbk3nyhgfVo5exGC22B2rqzQu4Qgr/bNc7J8z0yNGJIwS0UorKy6P02 yHCVwVLoPRMjoD/jdYCNd+j5qJ0lVnvcny39uGg1y2o4KsCRG6L+IwmPGLyvwViP iJBcGuewmxc2BU0U+gxrq3Cw9uZTo5YYDBrc1hmre5S7pwBF94LgrFuFQVVGWOxH GQAtBE4lEVsfjnahFgixbisA3cPlmFRjdBNW22kOg0H7F92ixHRbSYwLLHjZB3pN NBR7BDlqWF5EfjhjJiz/jolFanta8XKB1QxuT1uDxPx48BnvuTpDwuYLkNJXObxE TMbnldrRso2Bj4fAWNNyiFF6v/Jt4wH3TfrrzqM6D1J8DK/adiUrdSYPVIBIVMTf uvp+kRidaS6DIywLeQexCZXgacgB6Kzy0DLWtS64k/jAYVkb57wU89t2bb4T86JL FiZFx901j5KZiWX3BZaI9bNzB6+1ppnkUZmxZeguxjXNLEqZOFDH4fXP0TjX76XA fIDmo1dlx/KuSgEmChduQAPjx9/dKFOkifqgYPkThNCH2wgNV+0qQ47+Ajrod+RX KC/6GdRyxhN53T3FQ+WyPfyTL2+9QgpIe19Xs4zsa24zhXK9WIE= =dpHX -----END PGP SIGNATURE----- --chU1Pmv4FMIEBLRtL4DLfkWQ19nHDOQdt-- From owner-freebsd-arm@freebsd.org Tue Sep 26 04:59:09 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 337D3E2EF54 for ; Tue, 26 Sep 2017 04:59:09 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail03.adl2.internode.on.net (ipmail03.adl2.internode.on.net [150.101.137.141]) by mx1.freebsd.org (Postfix) with ESMTP id 0DA0F76430 for ; Tue, 26 Sep 2017 04:59:07 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from unknown (HELO midget.dons.net.au) ([118.211.110.227]) by ipmail03.adl2.internode.on.net with ESMTP; 26 Sep 2017 14:23:55 +0930 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.1/8.14.9) with ESMTPS id v8Q4rYoK087529 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 26 Sep 2017 14:23:51 +0930 (CST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.1/8.14.9/Submit) id v8Q4h2Ne080872 for ; Tue, 26 Sep 2017 14:13:02 +0930 (CST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [10.176.138.114] (ns.dons.net.au [10.0.2.1]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id v8Q4guHh080868; Tue, 26 Sep 2017 14:13:02 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Why does this compile? From: "O'Connor, Daniel" In-Reply-To: Date: Tue, 26 Sep 2017 14:12:56 +0930 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <43AA1F17-397E-489F-967B-FB69C7E3BF5D@dons.net.au> References: To: Russell Haley X-Mailer: Apple Mail (2.3273) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.0 X-Scanned-By: MIMEDefang 2.75 on 10.0.2.1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 04:59:09 -0000 > On 26 Sep 2017, at 14:08, Russell Haley wrote: > This compiles on FreeBSD current and apparently on 11 too. That's a > bad thing because it's supposed to fail. I checked in.h and there is > no struct for in_pktinfo. Not surprisingly, if I remove the include > altogether, it still compiles. > > I assume then that the original author made a mistake? My C is too > weak and most of my searches don't turn up anything close to what I'm > looking for. > > Any suggestions would be awesome. :) Change the test to.. check_c_source_compiles( " #include <${SOCKET_INCLUDES}> int main() { struct in_pktinfo teststruct; return 0; } " HAVE_IN_PKTINFO) i.e. the original test is broken and will always compile (as you discovered). -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-arm@freebsd.org Tue Sep 26 05:02:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C0E9E2F0F5 for ; Tue, 26 Sep 2017 05:02:06 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id EA4BE765B5 for ; Tue, 26 Sep 2017 05:02:05 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id BB745156E523; Mon, 25 Sep 2017 21:54:26 -0700 (PDT) From: Bakul Shah To: Russell Haley cc: freebsd-arm Subject: Re: Why does this compile? In-reply-to: Your message of "Mon, 25 Sep 2017 21:38:33 -0700." References: Comments: In-reply-to Russell Haley message dated "Mon, 25 Sep 2017 21:38:33 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18903.1506401624.1@bitblocks.com> Date: Mon, 25 Sep 2017 21:54:26 -0700 Message-Id: <20170926045441.BB745156E523@mail.bitblocks.com> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 05:02:06 -0000 On Mon, 25 Sep 2017 21:38:33 -0700 Russell Haley wrote: Russell Haley writes: > > int main() > { > struct in_pktinfo; > return 0; > } > > This compiles on FreeBSD current and apparently on 11 too. That's a > bad thing because it's supposed to fail. I checked in.h and there is > no struct for in_pktinfo. Not surprisingly, if I remove the include > altogether, it still compiles. > > I assume then that the original author made a mistake? My C is too > weak and most of my searches don't turn up anything close to what I'm > looking for. > > Any suggestions would be awesome. :) C allows struct forward references. Mainly so that you can declare pointers to them (and the actual struct defn may be in another file). As long as you don't dereference such a ptr in the first file, the cmompiler won't throw a fit. If you want to generate an error, create a variable in main(): struct in_pktinfo foo; From owner-freebsd-arm@freebsd.org Tue Sep 26 05:03:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7746E2F184 for ; Tue, 26 Sep 2017 05:03:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-57.reflexion.net [208.70.210.57]) (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 8A1017678C for ; Tue, 26 Sep 2017 05:03:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27223 invoked from network); 26 Sep 2017 04:56:43 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 26 Sep 2017 04:56:43 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 26 Sep 2017 00:56:43 -0400 (EDT) Received: (qmail 24698 invoked from network); 26 Sep 2017 04:56:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Sep 2017 04:56:43 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 9B38CEC9186; Mon, 25 Sep 2017 21:56:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Why does this compile? From: Mark Millard In-Reply-To: Date: Mon, 25 Sep 2017 21:56:41 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: References: To: Russell Haley X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 05:03:24 -0000 On 2017-Sep-25, at 9:38 PM, Russell Haley wrote: > I'm trying to compile the new dotnet core 2.0 and I've run into a C > problem I don't understand. Since I ran the code to check it on my arm > board, I'm going to ask here (the most knowledgeable fbsd C people I > could ask). > > The cmake file is trying to test for a linux struct in_pktinfo: > > check_c_source_compiles( > " > #include <${SOCKET_INCLUDES}> > int main() > { > struct in_pktinfo; > return 0; > } > " > HAVE_IN_PKTINFO) > > SOCKET_INCLUDES resolves to netinet/in.h so the final source is: > > #include > > int main() > { > struct in_pktinfo; > return 0; > } > > This compiles on FreeBSD current and apparently on 11 too. That's a > bad thing because it's supposed to fail. I checked in.h and there is > no struct for in_pktinfo. Not surprisingly, if I remove the include > altogether, it still compiles. struct in_pktinfo; declares but does not define the struct type. Not even the size is known --but nothing is done that needs to use even the size. By contrast the below would need the definition of the struct type in question: #include int main() { struct in_pktinfo struct_instance; return 0; } > I assume then that the original author made a mistake? My C is too > weak and most of my searches don't turn up anything close to what I'm > looking for. The program needs to have something that requires seeing the definition of the type, such as needing its size. > Any suggestions would be awesome. :) check_c_source_compiles( " #include <${SOCKET_INCLUDES}> int main() { struct in_pktinfo struct_instance; return 0; } " HAVE_IN_PKTINFO) === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Sep 26 05:37:07 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7801E2FAF9; Tue, 26 Sep 2017 05:37:07 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8B8C7756C; Tue, 26 Sep 2017 05:37:07 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id v8Q5b1W2051411 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Sep 2017 22:37:01 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id v8Q5b1vD051410; Mon, 25 Sep 2017 22:37:01 -0700 (PDT) (envelope-from jmg) Date: Mon, 25 Sep 2017 22:37:01 -0700 From: John-Mark Gurney To: Darius Mihai Cc: freebsd-virtualization@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Cross-compiling socat Message-ID: <20170926053701.GT64616@funkthat.com> Mail-Followup-To: Darius Mihai , freebsd-virtualization@freebsd.org, freebsd-arm@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 25 Sep 2017 22:37:01 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 05:37:08 -0000 Darius Mihai wrote this message on Mon, Sep 25, 2017 at 13:58 +0300: > I am currently implementing the VirtIO devices for bhyve on ARM, more > specifically the VirtIO-console device. > > However, I am stuck since I need to use 'socat' on the host, but > cross-compiling always fails (the ports do not seem to have a > straight-forward make system for cross-compiling as far as I could tell). > I have tried using `./configure --host=amd64 --build=armv6 > CC=arm-none-eabi-gcc`, > in the 'work/socat-1.7.3.2' directory, but this doesn't seem to work. > > If anyone could provide any insight, it would be greatly appreciated. You shoudl be able to do a toolchain TARGET_ARCH=armv6 to build a cross build environment, and then you can run make buildenv to launch a shell to build socat in this environment... I've done it this way in the past, though I forget if it needs a complete buildworld to work, or if toolchain is enough.. There also appears to be the xdev-build and xdev-install which I think install them into the current environment which you can use... Though I'm not sure if the libraries and other things are built as I've only used it once a long time ago.. Hope this helps. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Tue Sep 26 05:42:53 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7762E2FE34; Tue, 26 Sep 2017 05:42:53 +0000 (UTC) (envelope-from dariusmihaim@gmail.com) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0DCB77A57; Tue, 26 Sep 2017 05:42:53 +0000 (UTC) (envelope-from dariusmihaim@gmail.com) Received: by mail-qt0-x236.google.com with SMTP id b1so9247432qtc.4; Mon, 25 Sep 2017 22:42:53 -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; bh=u8WG4Mk3OeAy4U6AF7RxJV9yqyA+X5st8rOaY/su/r4=; b=EjqhKKRjHFgte74r216W4HK/nEEMA9xQRYmNy/i0Fo1tH4jRgIcEMkzoqGearXaHao 5YLTNoZc2Wf1cwcH5FtnwlhqXutB0FJGkwf4FXqM/gXP4eGgxt4dgZum9O/ciUqOjRvO mUch26Z/px+KyocpuysRnfFjDTnSmEY52CUJNVhKGRfOu3NG7v3vu9wfBjcX4pZs9iao kEFqdmRMKxGwH0ginOFgeQygTcE640QvjDKotmCVC374jzbGneyRY6+AqzpBsuwGwmOP fLNQ8gyhRC0sosxQ8TqbSJdsm+trbRFUgtm3VahgimJ8WX7MFikO5Eo4Inn//xL/S+iF Ui1g== 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; bh=u8WG4Mk3OeAy4U6AF7RxJV9yqyA+X5st8rOaY/su/r4=; b=MitahxA7OEwaiuFrf+Pgqfi6YNPQINnknVH65E6UjiMyph6XMilCdBaEPmr6kWzcrY JAiWyplSCO/lXNmtGzCBdvCdQzPHpORntvRHQ9uwL6v3vtAltHP9shfWsRyU4QKMP3x0 fZFShLtaUjb/KLR7+JCvTs2ts7eXXPeEdPrBUISTk4tVSVuHE1USHbswgXY41muhiXTq f8YUAxqyyXhMN4I5LkAhBBrT7QTD6npw1v4AsawF8oWZc9p6hibfMA6FZOK4NMmhehYI HKehwNJ37ZODxwIgqzRhSsZ+0HKkqrRJ5DIM4RDlevu/q1uh4A4E5lPQlB87mIWLSfmY KAOg== X-Gm-Message-State: AHPjjUhI/bkhF/Yy1f6HNZNvaj6dwJHTzEz6nOeEeYL2ZZuWr5vhXLHi M+1iB5x4yXYZjZb/7nzMr2fURKVA53VdRSVWZSMBOw== X-Google-Smtp-Source: AOwi7QBL2h3S6rGTe4TbThHkmLTLhp24qXrn3DA37aG9lVllC/xjaZjJ+bx8A8UsdOYjxbuF92YjVlw69uLgV0Y0F1I= X-Received: by 10.200.34.167 with SMTP id f36mr14151869qta.173.1506404572558; Mon, 25 Sep 2017 22:42:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.47.171 with HTTP; Mon, 25 Sep 2017 22:42:52 -0700 (PDT) Received: by 10.200.47.171 with HTTP; Mon, 25 Sep 2017 22:42:52 -0700 (PDT) In-Reply-To: <20170926053701.GT64616@funkthat.com> References: <20170926053701.GT64616@funkthat.com> From: Darius Mihai Date: Tue, 26 Sep 2017 08:42:52 +0300 Message-ID: Subject: Re: Cross-compiling socat To: freebsd-virtualization@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 05:42:54 -0000 Hello, Thank you for the advice. For socat I have downloaded the precompiled version available on pkg.freebsd.org, but I will use your method, should the need for another ported binary arise. Have a great day, Darius On Sep 26, 2017 8:37 AM, "John-Mark Gurney" wrote: > Darius Mihai wrote this message on Mon, Sep 25, 2017 at 13:58 +0300: > > I am currently implementing the VirtIO devices for bhyve on ARM, more > > specifically the VirtIO-console device. > > > > However, I am stuck since I need to use 'socat' on the host, but > > cross-compiling always fails (the ports do not seem to have a > > straight-forward make system for cross-compiling as far as I could tell). > > I have tried using `./configure --host=amd64 --build=armv6 > > CC=arm-none-eabi-gcc`, > > in the 'work/socat-1.7.3.2' directory, but this doesn't seem to work. > > > > If anyone could provide any insight, it would be greatly appreciated. > > You shoudl be able to do a toolchain TARGET_ARCH=armv6 to build a cross > build environment, and then you can run make buildenv to launch a shell > to build socat in this environment... I've done it this way in the past, > though I forget if it needs a complete buildworld to work, or if toolchain > is enough.. > > There also appears to be the xdev-build and xdev-install which I think > install them into the current environment which you can use... Though I'm > not sure if the libraries and other things are built as I've only used > it once a long time ago.. > > Hope this helps. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > From owner-freebsd-arm@freebsd.org Tue Sep 26 05:45:43 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05984E2FFD3 for ; Tue, 26 Sep 2017 05:45:43 +0000 (UTC) (envelope-from russ.haley@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 8F5F577CBF for ; Tue, 26 Sep 2017 05:45:42 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-wr0-x234.google.com with SMTP id a43so11467469wrc.0 for ; Mon, 25 Sep 2017 22:45:42 -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=JBVWTqBJJQFymuZ/Cf8Zj+gee7Jtake6X5UMWOCz6vU=; b=jo8Ah04R9/nlc0vKZCBBaJIZIYkB1IHWHiOjNRDtI/9i/A6wVFEUxQ+T2bpkaT98+x ETbY2WPimiV1sofWfH3RNKSP2uVnX/ytfnE4hgKzxeLXRx0S4KiDDi8Xs17sMcVxBVzh m/2otDnyhK53Qzteg8xauYUUFui75ie8cqfga5CPEz7K7P3BmkgqBRGldAqaYdz4f7yZ c9OUe92+1iRk3CwtHDohmqG2w+bm+LQKunO2n3sapIFwF6uMufTUt58YauodG1ZY20LZ +MwZeeFuwDjYIhwHuepRoZNLFyQQtHKFJDFbAuqTyFX9dl5TTYWZ379gf/4yJwaDPL2d kong== 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=JBVWTqBJJQFymuZ/Cf8Zj+gee7Jtake6X5UMWOCz6vU=; b=ljfpmfxgcynnVss57gEZo5+OREeGL1ApkxOQcia1jMmUWZesyR/B7UurvGAwGHbziP tYAtLvncp4569fGYT7KCViyQSE44AqDkwQlnOVRSXGnrYWlyMgAFEoUqwwWgnQ6eD9Kw +PgqDlaswUT6P/hDBhFZ9stJawrGrBUHEvrQobA58vSxTL0tNIv/dR9p2nvmzlaqzXBr xfA7PgyUzk4dCkbJRUvKNuohEkET2z9Mgels47t9EcVoBWqLKQbfCNwG+And9s5sPZCk 2NK0Md+PxnKhzIwxain2zpqXxynjSQeD8LVzRcXc9ki2LouPwLvdv23YeL1Vkpu4HY5J 2NuQ== X-Gm-Message-State: AHPjjUhjuw7XWBprGkGyryQ8MfzSO3fMDj8bgn53zw+hDpkQqFqNV8df XGFlplJKkyycZ6ox0ZIu+v/z2HyDPAOsWT1USIAfMbKV X-Google-Smtp-Source: AOwi7QAHTzrVJbW1bl88zK/Ciggnk2fUfiv8hLHIHvxwYMi/yfV/9cve85jWc5WCBFCcn7VvJ/0CjNAw+m+Sik8afVA= X-Received: by 10.46.29.5 with SMTP id d5mr3617493ljd.97.1506404741151; Mon, 25 Sep 2017 22:45:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Mon, 25 Sep 2017 22:45:40 -0700 (PDT) In-Reply-To: References: From: Russell Haley Date: Mon, 25 Sep 2017 22:45:40 -0700 Message-ID: Subject: Re: Why does this compile? To: Mark Millard Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 05:45:43 -0000 You guys are awesome. Thanks so much! Russ On Mon, Sep 25, 2017 at 9:56 PM, Mark Millard wrote: > On 2017-Sep-25, at 9:38 PM, Russell Haley wrote: > >> I'm trying to compile the new dotnet core 2.0 and I've run into a C >> problem I don't understand. Since I ran the code to check it on my arm >> board, I'm going to ask here (the most knowledgeable fbsd C people I >> could ask). >> >> The cmake file is trying to test for a linux struct in_pktinfo: >> >> check_c_source_compiles( >> " >> #include <${SOCKET_INCLUDES}> >> int main() >> { >> struct in_pktinfo; >> return 0; >> } >> " >> HAVE_IN_PKTINFO) >> >> SOCKET_INCLUDES resolves to netinet/in.h so the final source is: >> >> #include >> >> int main() >> { >> struct in_pktinfo; >> return 0; >> } >> >> This compiles on FreeBSD current and apparently on 11 too. That's a >> bad thing because it's supposed to fail. I checked in.h and there is >> no struct for in_pktinfo. Not surprisingly, if I remove the include >> altogether, it still compiles. > > struct in_pktinfo; > > declares but does not define the struct type. Not even > the size is known --but nothing is done that needs > to use even the size. > > By contrast the below would need the definition > of the struct type in question: > > #include > > int main() > { > struct in_pktinfo struct_instance; > return 0; > } > >> I assume then that the original author made a mistake? My C is too >> weak and most of my searches don't turn up anything close to what I'm >> looking for. > > The program needs to have something that requires > seeing the definition of the type, such as needing > its size. > >> Any suggestions would be awesome. :) > > check_c_source_compiles( > " > #include <${SOCKET_INCLUDES}> > int main() > { > struct in_pktinfo struct_instance; > return 0; > } > " > HAVE_IN_PKTINFO) > > > === > Mark Millard > markmi at dsl-only.net > From owner-freebsd-arm@freebsd.org Tue Sep 26 14:27:15 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B575FE0D1B4 for ; Tue, 26 Sep 2017 14:27:15 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from nov-007-i577.relay.mailchannels.net (nov-007-i577.relay.mailchannels.net [46.232.183.131]) (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 59B1667C00 for ; Tue, 26 Sep 2017 14:27:13 +0000 (UTC) (envelope-from ian@freebsd.org) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 44FEE5C1D3A for ; Tue, 26 Sep 2017 14:21:21 +0000 (UTC) Received: from outbound1a.eu.mailhop.org (unknown [100.96.147.57]) (Authenticated sender: duocircle) by relay.mailchannels.net (Postfix) with ESMTPA id 269355C1848 for ; Tue, 26 Sep 2017 14:21:19 +0000 (UTC) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [172.20.67.103]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.9.14); Tue, 26 Sep 2017 14:21:21 +0000 X-MC-Relay: Forwarding X-MailChannels-SenderId: _forwarded-from|73.78.92.27 X-MailChannels-Auth-Id: duocircle X-Glossy-Zesty: 250675fc474f9ff0_1506435680673_1544152468 X-MC-Loop-Signature: 1506435680673:952194870 X-MC-Ingress-Time: 1506435680672 X-MHO-User: f4a222b1-a2c5-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id f4a222b1-a2c5-11e7-a893-25625093991c; Tue, 26 Sep 2017 14:21:16 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8QELDcv001208; Tue, 26 Sep 2017 08:21:14 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506435673.73082.129.camel@freebsd.org> Subject: Re: CUBOX snapshots working? From: Ian Lepore To: Brett Glass , freebsd-arm@freebsd.org Date: Tue, 26 Sep 2017 08:21:13 -0600 In-Reply-To: <201709260339.VAA16701@mail.lariat.net> References: <201709260339.VAA16701@mail.lariat.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 14:27:15 -0000 On Mon, 2017-09-25 at 21:39 -0600, Brett Glass wrote: > While waiting for the new SolidRun board I just ordered to come in,=A0 > I decided to tinker with one of their older products: a CUBOX=A0 > I2U-300-D. I downloaded the latest CUBOX snapshot (12.0 r323729),=A0 > burned it onto an SD card, dropped the card into the box, plugged=A0 > in an HDMI monitor, and watched the onboard serial port as I=A0 > applied power. This is what I saw (on the serial port; the monitor=A0 > stayed blank): >=20 > U-Boot SPL 2017.07 (Sep 19 2017 - 23:14:46) > Trying to boot from MMC1 >=20 >=20 > U-Boot 2017.07 (Sep 19 2017 - 23:14:46 +0000) >=20 > CPU:=A0=A0=A0Freescale i.MX6D rev1.2 996 MHz (running at 792 MHz) > CPU:=A0=A0=A0Extended Commercial temperature grade (-20C to 105C) at 14= C > Reset cause: POR > Board: MX6 Cubox-i > DRAM:=A0=A01 GiB > MMC:=A0=A0=A0FSL_SDHC: 0 > *** Warning - bad CRC, using default environment >=20 > No panel detected: default to HDMI > Display: HDMI (1024x768) > In:=A0=A0=A0=A0serial > Out:=A0=A0=A0serial > Err:=A0=A0=A0serial > Net:=A0=A0=A0FEC > Hit any key to stop autoboot:=A0=A00 > ## Error: "boot=A6md_mmc0" not defined > ## Error: "boot=A6md_usb0" not defined > ## Error: "boot=A6md_pxe" not defined > ## Error: "boot=A6md_dhcp" not defined >=20 > ...and of course it didn't boot. Without the HDMI monitor plugged=A0 > in, it failed with different errors, but still did not boot. >=20 > What's the last good snapshot? >=20 > --Brett Glass I just DLed and booted that snapshot on my Cubox-4i without any problems. =A0As near as I can tell, the only difference is you've got the dual-core chip and mine has the quad. The same u-boot should work for both. =A0At least, that was the case when using the vendor-provided u-boot; the images are now built from mainline u-boot. =A0The output you provided does show that it detected the right kind of chip and amount of ram, so I think it should support both flavors of cubox. -- Ian From owner-freebsd-arm@freebsd.org Tue Sep 26 17:43:25 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 885C7E11D36 for ; Tue, 26 Sep 2017 17:43:25 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 4E26F6EEC0; Tue, 26 Sep 2017 17:43:24 +0000 (UTC) (envelope-from brett@lariat.net) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id LAA21422; Tue, 26 Sep 2017 11:32:29 -0600 (MDT) Message-Id: <201709261732.LAA21422@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Sep 2017 11:32:21 -0600 To: Ian Lepore , freebsd-arm@freebsd.org From: Brett Glass Subject: Re: CUBOX snapshots working? In-Reply-To: <1506435673.73082.129.camel@freebsd.org> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 17:43:25 -0000 One would think that sauce for the goose would be sauce for the gander. But is this particular Cubox now useless with FreeBSD? And if so, why? It is not an unusual model. The Cubox does work if I flash their "Ignition" startup software (which is used to bootstrap by downloading various OS images) to the same Micro SD card. --Brett Glass At 08:21 AM 9/26/2017, Ian Lepore wrote: >I just DLed and booted that snapshot on my Cubox-4i without any >problems. As near as I can tell, the only difference is you've got the >dual-core chip and mine has the quad. > >The same u-boot should work for both. At least, that was the case when >using the vendor-provided u-boot; the images are now built from >mainline u-boot. The output you provided does show that it detected >the right kind of chip and amount of ram, so I think it should support >both flavors of cubox. > >-- Ian From owner-freebsd-arm@freebsd.org Tue Sep 26 18:04:51 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E7C1E127BC for ; Tue, 26 Sep 2017 18:04:51 +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 983EF6FC2D; Tue, 26 Sep 2017 18:04:50 +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 c2f8b32b; Tue, 26 Sep 2017 20:04:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=UisIo37r4z9/rytGOky1H7SRZks=; b=kKfUrDwYuLooktcCjdXbO3RXxzSd xCd6BRNMl2/RanD6mGFF0YzqLE5G9JCral+VaU4vTNSZ5xvRMN8ApokZ1JYf9sga 59FiZsypZl1VNgzchvR5pvbdKobTRwbYViPdAuNG7bMTBoMb4mePKe45VE+c9lX/ I1WF/CDe2SURg/0= 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=SWGvOIcJJqlABHZWpmnVnKyOxNICm40AxD83aUmdwyWaQUZDBmwItLuk 6EuaXMDMFMHGPij+eYJF6mOsfzxJ6NSRShwMDVa7ayVbyVENJx3xFy7saLVC6jcR R4qwxtRPKcs3h9WlH+Z0GvX8ienBu/6waf0ZzXDTglKoiFTFUlc= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 70dfe1b4 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 26 Sep 2017 20:04:47 +0200 (CEST) Date: Tue, 26 Sep 2017 20:04:46 +0200 From: Emmanuel Vadot To: Brett Glass Cc: Ian Lepore , freebsd-arm@freebsd.org Subject: Re: CUBOX snapshots working? Message-Id: <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> In-Reply-To: <201709261732.LAA21422@mail.lariat.net> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 18:04:51 -0000 On Tue, 26 Sep 2017 11:32:21 -0600 Brett Glass wrote: > One would think that sauce for the goose would be sauce for the > gander. But is this particular Cubox now useless with FreeBSD? > And if so, why? It is not an unusual model. The Cubox does work > if I flash their "Ignition" startup software (which is used to > bootstrap by downloading various OS images) to the same > Micro SD card. > > --Brett Glass The problem isn't FreeBSD related, it's U-Boot related. You could test build mainline u-boot just to confirm that it isn't something due to our ports. > At 08:21 AM 9/26/2017, Ian Lepore wrote: > > >I just DLed and booted that snapshot on my Cubox-4i without any > >problems. As near as I can tell, the only difference is you've got the > >dual-core chip and mine has the quad. > > > >The same u-boot should work for both. At least, that was the case when > >using the vendor-provided u-boot; the images are now built from > >mainline u-boot. The output you provided does show that it detected > >the right kind of chip and amount of ram, so I think it should support > >both flavors of cubox. > > > >-- 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" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Sep 26 18:08:51 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 231E4E12AF9 for ; Tue, 26 Sep 2017 18:08:51 +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 6DDA87003C; Tue, 26 Sep 2017 18:08:49 +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 b33d9708; Tue, 26 Sep 2017 20:08:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=rfwP7aTIOSQlIV315l+DCL/UILY=; b=OXASg1QquV3odYxhUkBjLQM47rZo O97otrO4R992aAfTyHgQWMmRwiki6wFQBFVQAm2jtoSBbBDoWsGFOmkWflOm9QxW ig0FHqedkLK1CzkD7guZVxiEzz9XtU2ugdzsp6ViaRNs7U1XYCAmendLD98JB2tn xbEfPkYBVYrQe4Q= 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=KJes3XYvaoqN8SDtM9F63syl3fvUM64Y1iOuXck572s232+NmvbAXCKU 78XugAzdItuIjQoU73yTQ8MR6Yej+0FDD1b0omQccjFOJUndxZdS4z/Tkft5jP0A 3yrnzX3AB62DhCkk59sz+YERbyMGPM5n7r7Hvni9YrfXHyoaT5s= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id e70e8b7e TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 26 Sep 2017 20:08:47 +0200 (CEST) Date: Tue, 26 Sep 2017 20:08:46 +0200 From: Emmanuel Vadot To: Yoshiro MIHIRA Cc: jmcneill@freebsd.org, freebsd-arm Subject: Re: [FreeBSD] update todo list on Wiki-arm-Allwinner Message-Id: <20170926200846.55ca1efdf29223502a580953@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 18:08:51 -0000 Hello, On Fri, 22 Sep 2017 21:59:04 +0000 Yoshiro MIHIRA wrote: > Hi, all. > > Latest Crypto engine is listed on TODO list at Wiki arm Allwinner page. > > However, andrew added armv8crypto(driver for the AES accelerator on ARM > CPUs). It's not the same. ARMv8 (the ISA) have crypto related instruction, the wiki is talking about the crypto accelerator in the SoC. I honestly don't know if for ARMv8 this would be needed, iirc the mainline linux developper said that using the instruction for AES is faster. For ARMv7 SoC (like H3) I think that this would be good to add. > So I would like to update and add Crypto line on [[Supported > devices/Legend] at Wiki page. > Currently YES(r308921) is only for A64. > > openssl speed aes-256-cbc > "PINE64 without crypto engine" aes-256 cbc 20817.02k > 22166.74k 22629.38k 22734.17k 22754.10k > /usr/bin/openssl speed -engine cryptodev -evp aes-256-cbc > "PINE64 with crypto engine" aes-256-cbc 88225.27k > 207383.62k 308516.25k 360612.50k 380447.40k > > Yours > Yoshiro MIHIRA > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Sep 26 18:11:09 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9957E12D91 for ; Tue, 26 Sep 2017 18:11:09 +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 298E770249 for ; Tue, 26 Sep 2017 18:11:08 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 067ebb42; Tue, 26 Sep 2017 20:11:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=Rba0aajsBnlT1Wb7L/h6jbSEW08=; b=JhoxW/EB7jeuY8dOj/l/trzeqPZl au8WrZaEQnWnxYWMemEoFmmzN0f3HJi4SRZJWDIM8sa2SxhKhfH5UrKj4S4Lfei8 q33dm8mj3nd0q8NdDUkUVpPKH/0aJQ4+WRcM0V0FNdnvr4B2FBmzVYNBpLm64NYN slKBMslDplgN6dI= 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=hDj1QhA9xJ62vrwU/3Mb6UPTgdBXlpIWiAfMTW54s43U66l3wxvQr5Ja YaZprqg+TyAsjvnXOajTyPpzuKV40McCdKrUFH9uIaPENSvb8XRUsOBATpG0mt1e ejaUmBSphXzt0i5iNysFkADpEHuUy15oKF58rusvJ5hCCNwkpDw= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 602c30c4 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 26 Sep 2017 20:11:05 +0200 (CEST) Date: Tue, 26 Sep 2017 20:11:04 +0200 From: Emmanuel Vadot To: Mark Millard Cc: =?ISO-8859-1?Q?=3F=3F?= , "freebsd-arm@freebsd.org" Subject: Re: how to build GENERIC kernel for orange pi Message-Id: <20170926201104.a937b45e09f41eac62fc7f05@bidouilliste.com> In-Reply-To: <945AE03C-69A9-4ABD-98EB-78CF3A599D63@dsl-only.net> References: <20170914134321.9873e02f3d9937e0a6fe4b46@bidouilliste.com> <945AE03C-69A9-4ABD-98EB-78CF3A599D63@dsl-only.net> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 18:11:09 -0000 On Wed, 20 Sep 2017 01:00:02 -0700 Mark Millard wrote: >=20 > On 2017-Sep-20, at 12:32 AM, ?? wrote: >=20 > > Hi everybody, > >=20 > > According to https://www.bsdcan.org/2017/schedule/events/833.en.html, > > seem need a specific source to compile GENERIC arm kernel?(if that's > > true,where could I download those specific sources?) > > I fetch source from here > > fetch http://ftp.freebsd.org/pub/FreeBSD/releases/i386/11.1-RELEASE/ > >=20 > > make TARGET=3Darm TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null __MAKE_CONF= =3D/dev/null > > buildworld <---ok > >=20 > > make TARGET=3Darm TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null __MAKE_CONF= =3D/dev/null > > KERNCONF=3DALLWINNER buildkernel <--ok > >=20 > > but > > make TARGET=3Darm TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null __MAKE_CONF= =3D/dev/null > > KERNCONF=3DGENERIC buildkernel > > make[1]: "/opt/11stable/usr/src/Makefile.inc1" line 158: SYSTEM_COMPILE= R: > > Determined that CC=3Dcc matches the source tree. Not bootstrapping a > > cross-compiler. > > ERROR: Missing kernel configuration file(s) (GENERIC). > > *** Error code 1 > >=20 > > Stop. > > make[1]: stopped in /opt/11stable/usr/src > > *** Error code 1 > >=20 > > Stop. > > make: stopped in /opt/11stable/usr/src >=20 > https://svnweb.freebsd.org/base/release/11.1.0/sys/arm/conf/ >=20 > does not have a GENERIC configuration file. Nor does: >=20 > https://svnweb.freebsd.org/base/stable/11/sys/arm/conf/ >=20 > GENERIC for TARGET_ARCH=3Darmv6 is newer and is only in/for: >=20 > https://svnweb.freebsd.org/base/head/ >=20 > so far. I do not know if it will ever be merged back to > stable/11 or not. Some bits could be merged but for Allwinner we cannot as we changed some clock api and we cannot break api on stable release. Also this would require DTS merge and this would be a pain to handle. > > my compile environment > > uname -v > > FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 04:10:47 UTC 2017 > > root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC > >=20 > > Unto > >=20 > > thanks help > >=20 > > 2017-09-14 19:43 GMT+08:00 Emmanuel Vadot : > >=20 > >> On Thu, 14 Sep 2017 14:45:28 +0800 > >> ?? wrote: > >>=20 > >>> Date: Sun, 25 Jun 2017 13:21:06 +0200 > >>> From: Emmanuel Vadot > >>> To: Johnny Sorocil > >>> Cc: freebsd-arm@freebsd.org > >>>=20 > >>>> Steps to reproduce: > >>>> rm -rf /usr/obj > >>>> make -j4 TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null __MAKE_CONF=3D/dev/= null > >>>> buildworld > >>>> make -j4 TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null __MAKE_CONF=3D/dev/= null > >>>> KERNCONF=3DALLWINNER buildkernel > >>>> make -j4 TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null __MAKE_CONF=3D/dev/= null > >>>> KERNCONF=3DALLWINNER DESTDIR=3D/mnt/sd2/ installkernel > >>>> make -j4 TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null __MAKE_CONF=3D/dev/= null > >>>> KERNCONF=3DALLWINNER DESTDIR=3D/mnt/sd2/ installworld > >>>=20 > >>> You should use the GENERIC kernel, I'll remove ALLWINNER as it's not > >>> needed anymore. >=20 > I think that the above reply was implicitly referencing > head (12) only for GENERIC, not even stable/11 . So > source code based on: >=20 > https://svnweb.freebsd.org/base/head/ >=20 > >>> ------------------------------------------------------------ > >> --------------------- > >>> But I use GENERIC kernel config get errors below > >>>=20 > >>> #make TARGET_ARCH=3Darmv6 SRCCONF=3D/dev/null __MAKE_CONF=3D/dev/null > >>> KERNCONF=3DGENERIC buildkernel > >>>=20 > >>> make[1]: "/usr/src/Makefile.inc1" line 158: SYSTEM_COMPILER: Determin= ed > >>> that CC=3Dcc matches the source tree. Not bootstrapping a cross-comp= iler. > >>> ERROR: Missing kernel configuration file(s) (GENERIC). > >>> *** Error code 1 > >>>=20 > >>> Stop. > >>> make[1]: stopped in /usr/src > >>> *** Error code 1 > >>>=20 > >>> Stop. > >>> make: stopped in /usr/src > >>>=20 > >>> Thanks help. > >>=20 > >> Hello, > >>=20 > >> You need to set TARGET=3Darm too. > >> The real target for armv6 is arm.armv6. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Sep 26 18:22:07 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 675A1E153DE for ; Tue, 26 Sep 2017 18:22:07 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from nov-007-i577.relay.mailchannels.net (nov-007-i577.relay.mailchannels.net [46.232.183.131]) (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 078DE70B34 for ; Tue, 26 Sep 2017 18:22:04 +0000 (UTC) (envelope-from ian@freebsd.org) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2725C20752D for ; Tue, 26 Sep 2017 18:22:00 +0000 (UTC) Received: from outbound1a.eu.mailhop.org (unknown [100.96.147.85]) (Authenticated sender: duocircle) by relay.mailchannels.net (Postfix) with ESMTPA id 922F9207878 for ; Tue, 26 Sep 2017 18:21:59 +0000 (UTC) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [172.20.55.158]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.9.14); Tue, 26 Sep 2017 18:22:00 +0000 X-MC-Relay: Forwarding X-MailChannels-SenderId: _forwarded-from|73.78.92.27 X-MailChannels-Auth-Id: duocircle X-Spicy-Decisive: 19bd40563d222e7c_1506450120006_3568330493 X-MC-Loop-Signature: 1506450120006:4163123015 X-MC-Ingress-Time: 1506450120005 X-MHO-User: 92ef91b8-a2e7-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 92ef91b8-a2e7-11e7-a893-25625093991c; Tue, 26 Sep 2017 18:21:55 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8QILrCp001654; Tue, 26 Sep 2017 12:21:53 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506450112.73082.143.camel@freebsd.org> Subject: Re: CUBOX snapshots working? From: Ian Lepore To: Emmanuel Vadot , Brett Glass Cc: freebsd-arm@freebsd.org Date: Tue, 26 Sep 2017 12:21:52 -0600 In-Reply-To: <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.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: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 18:22:07 -0000 On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > On Tue, 26 Sep 2017 11:32:21 -0600 > Brett Glass wrote: >=20 > >=20 > > One would think that sauce for the goose would be sauce for the > > gander. But is this particular Cubox now useless with FreeBSD? > > And if so, why? It is not an unusual model. The Cubox does work > > if I flash their "Ignition" startup software (which is used to > > bootstrap by downloading various OS images) to the same > > Micro SD card. > >=20 > > --Brett Glass > =A0The problem isn't FreeBSD related, it's U-Boot related. >=20 > =A0You could test build mainline u-boot just to confirm that it isn't > something due to our ports. >=20 If we used to provide working cubox images and we don't anymore, it's hard to call that anything but a freebsd problem. You seem to be implying that this is another problem caused by switching from vendor-specific to mainline uboot. =A0I'm not sure that's the case here, but if it is, be clear: =A0It is purely a freebsd problem, because it was purely our choice (not mine) to switch from something that worked to something that doesn't. -- Ian > >=20 > > At 08:21 AM 9/26/2017, Ian Lepore wrote: > >=20 > > >=20 > > > I just DLed and booted that snapshot on my Cubox-4i without any > > > problems.=A0=A0As near as I can tell, the only difference is you've > > > got the > > > dual-core chip and mine has the quad. > > >=20 > > > The same u-boot should work for both.=A0=A0At least, that was the > > > case when > > > using the vendor-provided u-boot; the images are now built from > > > mainline u-boot.=A0=A0The output you provided does show that it > > > detected > > > the right kind of chip and amount of ram, so I think it should > > > support > > > both flavors of cubox. > > >=20 > > > -- 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.o > > rg" >=20 From owner-freebsd-arm@freebsd.org Tue Sep 26 18:46:29 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC5D9E15CE5 for ; Tue, 26 Sep 2017 18:46:29 +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 1747D71866; Tue, 26 Sep 2017 18:46:28 +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 572575be; Tue, 26 Sep 2017 20:46:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=87Ea6ICqqHmpUjMyE1GqeQH9Ugo=; b=Viy1CNQXfYQ7Co8ToignGmaAMzci YOPNawPbvUBy+S9f7zPr+MxjUdmmw01MCUUAYJNjQ94MF/9kM6pVzL4AGw40ApWZ N+F1CHIUk+E8X763aP7c4Cstk8efpB8rJ2sqWB4t08Nn7oIHMJ33u571vSazAE8t IMTE4Vc8PMOD54o= 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=jIaQCqhtgYRkq+7mCQ58MDY374/ps3g3Vc7KSPRXnOA9udQmqH9ocZgw LFZyaGF9t5uQjTSGFAgs2q7hXU0PSFqn+59ZqSgfIDaVUD4qNb/rmQZ0oq1y0rwx aTF/T4m2v5C282qACUG0JsOs8thd06rR7PxzSIMQhHsKoSAl1RM= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 96d616e5 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 26 Sep 2017 20:46:26 +0200 (CEST) Date: Tue, 26 Sep 2017 20:46:22 +0200 From: Emmanuel Vadot To: Ian Lepore Cc: Brett Glass , freebsd-arm@freebsd.org Subject: Re: CUBOX snapshots working? Message-Id: <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> In-Reply-To: <1506450112.73082.143.camel@freebsd.org> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> X-Mailer: Sylpheed 3.6.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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 18:46:30 -0000 On Tue, 26 Sep 2017 12:21:52 -0600 Ian Lepore wrote: > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > > On Tue, 26 Sep 2017 11:32:21 -0600 > > Brett Glass wrote: > >=20 > > >=20 > > > One would think that sauce for the goose would be sauce for the > > > gander. But is this particular Cubox now useless with FreeBSD? > > > And if so, why? It is not an unusual model. The Cubox does work > > > if I flash their "Ignition" startup software (which is used to > > > bootstrap by downloading various OS images) to the same > > > Micro SD card. > > >=20 > > > --Brett Glass > > =A0The problem isn't FreeBSD related, it's U-Boot related. > >=20 > > =A0You could test build mainline u-boot just to confirm that it isn't > > something due to our ports. > >=20 >=20 > If we used to provide working cubox images and we don't anymore, it's > hard to call that anything but a freebsd problem. There is working cubox images, the last one is from yesterday. You even say yourself that you did test it and that it worked. Do we even know if the snapshot worked for this board ? Brett, could you test the 11.0 release for example ? (I don't remember if for 11.1 we already switch u-boot or not). > You seem to be implying that this is another problem caused by > switching from vendor-specific to mainline uboot. =A0I'm not sure that's > the case here, but if it is, be clear: =A0It is purely a freebsd problem, > because it was purely our choice (not mine) to switch from something > that worked to something that doesn't. >=20 > -- Ian Yes, maybe switching to mainline for IMX boards was a premature one, I honestly don't have IMX board and don't know which way we should take. All I can say is that for TI and Allwinner board, mainline U-Boot is better (at least the support is the same). If you want to switch back to vendor u-boot for IMX board fell free to do so (as long as you don't change the other SoC U-Boot). > > >=20 > > > At 08:21 AM 9/26/2017, Ian Lepore wrote: > > >=20 > > > >=20 > > > > I just DLed and booted that snapshot on my Cubox-4i without any > > > > problems.=A0=A0As near as I can tell, the only difference is you've > > > > got the > > > > dual-core chip and mine has the quad. > > > >=20 > > > > The same u-boot should work for both.=A0=A0At least, that was the > > > > case when > > > > using the vendor-provided u-boot; the images are now built from > > > > mainline u-boot.=A0=A0The output you provided does show that it > > > > detected > > > > the right kind of chip and amount of ram, so I think it should > > > > support > > > > both flavors of cubox. > > > >=20 > > > > -- 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.o > > > rg" > >=20 --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Sep 26 18:56:52 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1FCEE15FF2 for ; Tue, 26 Sep 2017 18:56:52 +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 D482971D1B for ; Tue, 26 Sep 2017 18:56:52 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 659d8787-a2ec-11e7-b50b-53dc5ecda239 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 659d8787-a2ec-11e7-b50b-53dc5ecda239; Tue, 26 Sep 2017 18:56:26 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8QIuijD001716; Tue, 26 Sep 2017 12:56:44 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506452204.73082.147.camel@freebsd.org> Subject: Re: CUBOX snapshots working? From: Ian Lepore To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org Date: Tue, 26 Sep 2017 12:56:44 -0600 In-Reply-To: <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 18:56:53 -0000 On Tue, 2017-09-26 at 20:46 +0200, Emmanuel Vadot wrote: > On Tue, 26 Sep 2017 12:21:52 -0600 > Ian Lepore wrote: > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > > Brett Glass wrote: > > > > > > > > > > > > > > > One would think that sauce for the goose would be sauce for the > > > > gander. But is this particular Cubox now useless with FreeBSD? > > > > And if so, why? It is not an unusual model. The Cubox does work > > > > if I flash their "Ignition" startup software (which is used to > > > > bootstrap by downloading various OS images) to the same > > > > Micro SD card. > > > > > > > > --Brett Glass > > >  The problem isn't FreeBSD related, it's U-Boot related. > > > > > >  You could test build mainline u-boot just to confirm that it > > > isn't > > > something due to our ports. > > > > > If we used to provide working cubox images and we don't anymore, > > it's > > hard to call that anything but a freebsd problem. >  There is working cubox images, the last one is from yesterday. >  You even say yourself that you did test it and that it worked. >  Do we even know if the snapshot worked for this board ? >  Brett, could you test the 11.0 release for example ? (I don't > remember > if for 11.1 we already switch u-boot or not). > > > > > You seem to be implying that this is another problem caused by > > switching from vendor-specific to mainline uboot.  I'm not sure > > that's > > the case here, but if it is, be clear:  It is purely a freebsd > > problem, > > because it was purely our choice (not mine) to switch from > > something > > that worked to something that doesn't. > > > > -- Ian >  Yes, maybe switching to mainline for IMX boards was a premature one, > I > honestly don't have IMX board and don't know which way we should > take. > All I can say is that for TI and Allwinner board, mainline U-Boot is > better (at least the support is the same). If you want to switch back > to vendor u-boot for IMX board fell free to do so (as long as you > don't > change the other SoC U-Boot). > No, the mainline uboot for TI is NOT better.  It cannot netboot, and that is a regression from the previous version, which worked just fine. -- Ian > > > > > > > > > > > > > > > > > At 08:21 AM 9/26/2017, Ian Lepore wrote: > > > > > > > > > > > > > > > > > > > I just DLed and booted that snapshot on my Cubox-4i without > > > > > any > > > > > problems.  As near as I can tell, the only difference is > > > > > you've > > > > > got the > > > > > dual-core chip and mine has the quad. > > > > > > > > > > The same u-boot should work for both.  At least, that was the > > > > > case when > > > > > using the vendor-provided u-boot; the images are now built > > > > > from > > > > > mainline u-boot.  The output you provided does show that it > > > > > detected > > > > > the right kind of chip and amount of ram, so I think it > > > > > should > > > > > support > > > > > both flavors of cubox. > > > > > > > > > > -- Ian > > > > _______________________________________________ > > > > freebsd-arm@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freeb > > > > sd.o > > > > rg" > From owner-freebsd-arm@freebsd.org Tue Sep 26 20:39:44 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5503E20E45 for ; Tue, 26 Sep 2017 20:39:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-79.reflexion.net [208.70.210.79]) (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 9893675704 for ; Tue, 26 Sep 2017 20:39:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14589 invoked from network); 26 Sep 2017 20:33:02 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Sep 2017 20:33:02 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 26 Sep 2017 16:33:02 -0400 (EDT) Received: (qmail 17976 invoked from network); 26 Sep 2017 20:33:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Sep 2017 20:33:02 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 831D1EC8559; Tue, 26 Sep 2017 13:33:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: CUBOX snapshots working? From: Mark Millard In-Reply-To: <1506452204.73082.147.camel@freebsd.org> Date: Tue, 26 Sep 2017 13:33:00 -0700 Cc: Emmanuel Vadot , freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <1AA5D8DD-17C5-4F12-AD44-2EB8491B2BA5@dsl-only.net> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506452204.73082.147.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 20:39:44 -0000 On 2017-Sep-26, at 11:56 AM, Ian Lepore wrote: > On Tue, 2017-09-26 at 20:46 +0200, Emmanuel Vadot wrote: >> On Tue, 26 Sep 2017 12:21:52 -0600 >> Ian Lepore wrote: >> >>> >>> On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: >>>> >>>> On Tue, 26 Sep 2017 11:32:21 -0600 >>>> Brett Glass wrote: >>>> >>>>> >>>>> >>>>> One would think that sauce for the goose would be sauce for the >>>>> gander. But is this particular Cubox now useless with FreeBSD? >>>>> And if so, why? It is not an unusual model. The Cubox does work >>>>> if I flash their "Ignition" startup software (which is used to >>>>> bootstrap by downloading various OS images) to the same >>>>> Micro SD card. >>>>> >>>>> --Brett Glass >>>> The problem isn't FreeBSD related, it's U-Boot related. >>>> >>>> You could test build mainline u-boot just to confirm that it >>>> isn't >>>> something due to our ports. >>>> >>> If we used to provide working cubox images and we don't anymore, >>> it's >>> hard to call that anything but a freebsd problem. >> There is working cubox images, the last one is from yesterday. >> You even say yourself that you did test it and that it worked. >> Do we even know if the snapshot worked for this board ? >> Brett, could you test the 11.0 release for example ? (I don't >> remember >> if for 11.1 we already switch u-boot or not). >> >>> >>> You seem to be implying that this is another problem caused by >>> switching from vendor-specific to mainline uboot. I'm not sure >>> that's >>> the case here, but if it is, be clear: It is purely a freebsd >>> problem, >>> because it was purely our choice (not mine) to switch from >>> something >>> that worked to something that doesn't. >>> >>> -- Ian >> Yes, maybe switching to mainline for IMX boards was a premature one, >> I >> honestly don't have IMX board and don't know which way we should >> take. >> All I can say is that for TI and Allwinner board, mainline U-Boot is >> better (at least the support is the same). If you want to switch back >> to vendor u-boot for IMX board fell free to do so (as long as you >> don't >> change the other SoC U-Boot). >> > > No, the mainline uboot for TI is NOT better. It cannot netboot, and > that is a regression from the previous version, which worked just fine. A64 (or at least Pine64+ 2GB) also has regressed, at least temporarily. But as far as I can tell the intent is for a temporarily status, not an indefinitely long one. I'd guess other examples might also have such an intent. (But I do not know one way or the other.) A64 status (skip if do not care): I found and reported a fix for the non-debug kernel boot hangup for A64 (or at least the Pine64+ 2GB I had access to to test): Index: /usr/src/sys/arm64/arm64/mp_machdep.c =================================================================== --- /usr/src/sys/arm64/arm64/mp_machdep.c (revision 323246) +++ /usr/src/sys/arm64/arm64/mp_machdep.c (working copy) @@ -236,7 +236,9 @@ atomic_store_rel_int(&aps_ready, 1); /* Wake up the other CPUs */ - __asm __volatile("sev"); + __asm __volatile( + "dsb ish \n" + "sev \n"); printf("Release APs\n"); I added this patch to bugzilla 222234. (There could be a more optimal dsb variant than ish. But this was sufficient in the context that I could test.) I also added one for the other use of sev instruction that I found: Index: /usr/src/sys/arm64/arm64/identcpu.c =================================================================== --- /usr/src/sys/arm64/arm64/identcpu.c (revision 323676) +++ /usr/src/sys/arm64/arm64/identcpu.c (working copy) @@ -1109,6 +1109,9 @@ /* Wake up the other CPUs */ atomic_store_rel_int(&ident_lock, 0); - __asm __volatile("sev" ::: "memory"); + __asm __volatile( + "dsb ish \n" + "sev \n" + ::: "memory"); } } It looks like A64 just got a bunch of USB updates, including a fix and ECHI related material. (I do not know if ECHI is now generally operable yet.) This was another area that had regressed but has been worked on. At this point I do not know if the reported: Failed assertion: "nstime_compare(&decay->epoch, &time) <= 0" is a general problem or not. The times involved seems to trace back through use of binuptime and into soc specific code from my quick look around. It did not seem to trace back to an adjustable time. (If so: no worry about ntpd misbehavior.) === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Sep 26 21:07:32 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 488C1E21BB6 for ; Tue, 26 Sep 2017 21:07:32 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD27376818; Tue, 26 Sep 2017 21:07:31 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id c80so5804046lfh.0; Tue, 26 Sep 2017 14:07:31 -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=heQ9xIr7LvseFPvbaTquXfvINXRaKaX+jvY/zCPx5qA=; b=FOdqUdQTNKq3cdGZK1abWBl1PmMVP38crk0smE/LYBPT3INucIkeOa9SujhBIvYkIX L6xzpKCd+QdZq20ISkzkZd7A8p1kX5WPdpErwTMx/kDE567P4+SxG2Vfi2jktZb07fiO rXEP+35DX2CPMxvFmb6DQ3+22I2iCaMCqUqGJR3WmanE6+6gYQgPuKhr9h78TsjmZ+0w 2r+jh5QBFYmkP0f6mMUilgYoo1Hw52n0d+RwRKYOnyGW6xgP/noicACYQgXYm/woN7wy I2j15nKvDYS/xPwWo1IULuqL86I8ziwHoguNrEItYUlxlYLPwHprrxX8cMoLGxfwosNf Ajdw== 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=heQ9xIr7LvseFPvbaTquXfvINXRaKaX+jvY/zCPx5qA=; b=KpH/wy6dE8Mz9EjoLpr5/eTG1+Wnrk0nQ3kigRWXz2UAyG0e7qoPCIkrcbFVxpRKCS y3ciAPge5J5YV/O7yGzVH6OypODsFsv8KQS6hozt68wR3TLPKmtHigRJKQTUHygfvURP 8/eouPQpvJ5EnPBcgAAV5YJzNwLFQ/LpxnVpXTNtL6OjNCi1uImMrFhTZFh5I4bKpx26 NK9LZlbl40WsTF4wtWsXqDsxOFFBL5PcVVV6zSdwA5/nTMIx5/os/i5BiIW9uDMFuZFr GzTnVQi8j330luumxT6qzsCIMY2VOJ7T4VZiqdYHqh2mG4zxYk99SwjMFAWVjXqtJTpc cTWA== X-Gm-Message-State: AHPjjUjzNRVfUEyp2uyB5Wi7WoX0/K/HAK1UKF5LZSoMGFOK0Yki5TFk OX3GX5vuQTooQn0YkDi6kCMUEhLrLcwRysBBxi+XKAj1 X-Google-Smtp-Source: AOwi7QBYKzqHfOKIf5KLuX+8cMCNOgDpagzmZLYyQTdeC3MMmFgZ7a5yHcTwBd7+ccpJX1RbiwVxEZkMNeYxNm7JoV4= X-Received: by 10.25.81.85 with SMTP id f82mr3771369lfb.70.1506460049913; Tue, 26 Sep 2017 14:07:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Tue, 26 Sep 2017 14:07:29 -0700 (PDT) In-Reply-To: <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> From: Russell Haley Date: Tue, 26 Sep 2017 14:07:29 -0700 Message-ID: Subject: Re: CUBOX snapshots working? To: Emmanuel Vadot Cc: Ian Lepore , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 21:07:32 -0000 On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot wrote: > On Tue, 26 Sep 2017 12:21:52 -0600 > Ian Lepore wrote: > >> On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: >> > On Tue, 26 Sep 2017 11:32:21 -0600 >> > Brett Glass wrote: >> > >> > > >> > > One would think that sauce for the goose would be sauce for the >> > > gander. But is this particular Cubox now useless with FreeBSD? >> > > And if so, why? It is not an unusual model. The Cubox does work >> > > if I flash their "Ignition" startup software (which is used to >> > > bootstrap by downloading various OS images) to the same >> > > Micro SD card. >> > > >> > > --Brett Glass >> > The problem isn't FreeBSD related, it's U-Boot related. >> > >> > You could test build mainline u-boot just to confirm that it isn't >> > something due to our ports. >> > >> >> If we used to provide working cubox images and we don't anymore, it's >> hard to call that anything but a freebsd problem. > > There is working cubox images, the last one is from yesterday. > You even say yourself that you did test it and that it worked. > Do we even know if the snapshot worked for this board ? > Brett, could you test the 11.0 release for example ? (I don't remember > if for 11.1 we already switch u-boot or not). I believe the change is in the u-boot port itself. However, I don't think it's a u-boot problem (IMHO), it's a u-boot build configuration problem. There are different board variants with different hardware layout. u-boot has code for it, but our build does not account for. Unless the scripts that build the 11.1 image use a different revision of the u-boot port, wouldn't it just use the current 2017.7 base? I'm trying to figure out how to generate a u-boot with the correct SPL portion of u-boot. One could pull the SolidRun u-boot repo, or go find the ports commit before the changeover and see if we can generate the correct SPL. I looked at Mainline u-boot and there is a board directory for solid run. https://github.com/u-boot/u-boot/blob/master/board/solidrun/mx6cuboxi/mx6cuboxi.c seems to support multiple memory configurations based on defines, so this should just be a configuration problem. We clearly need to start supporting the lower spec'd SolidRun boards because this has come up a couple of times now since the changeover. It should be just a matter of creating a port that does the same thing but generates the correct SPL file? My SOM is a i2eX so I can't be too much help (and I've also over volunteered myself!). Russ >> You seem to be implying that this is another problem caused by >> switching from vendor-specific to mainline uboot. I'm not sure that's >> the case here, but if it is, be clear: It is purely a freebsd problem, >> because it was purely our choice (not mine) to switch from something >> that worked to something that doesn't. >> >> -- Ian > > Yes, maybe switching to mainline for IMX boards was a premature one, I > honestly don't have IMX board and don't know which way we should take. > All I can say is that for TI and Allwinner board, mainline U-Boot is > better (at least the support is the same). If you want to switch back > to vendor u-boot for IMX board fell free to do so (as long as you don't > change the other SoC U-Boot). >> > > >> > > At 08:21 AM 9/26/2017, Ian Lepore wrote: >> > > >> > > > >> > > > I just DLed and booted that snapshot on my Cubox-4i without any >> > > > problems. As near as I can tell, the only difference is you've >> > > > got the >> > > > dual-core chip and mine has the quad. >> > > > >> > > > The same u-boot should work for both. At least, that was the >> > > > case when >> > > > using the vendor-provided u-boot; the images are now built from >> > > > mainline u-boot. The output you provided does show that it >> > > > detected >> > > > the right kind of chip and amount of ram, so I think it should >> > > > support >> > > > both flavors of cubox. >> > > > >> > > > -- 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.o >> > > rg" >> > > > > -- > Emmanuel Vadot > _______________________________________________ > 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 Sep 26 21:40:58 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77F7FE22A63 for ; Tue, 26 Sep 2017 21:40:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44A4C77BB5 for ; Tue, 26 Sep 2017 21:40:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id d16so14046366ioj.3 for ; Tue, 26 Sep 2017 14:40:58 -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=M2nKBndrgkkfLgBcFIBZKqLYyEUMQkxukOt34dxqk4k=; b=YVoybXyOiY3vKYdHC5Yj+pOMWw7GVnkCBzx3c0hL9mouVEIG2TrU63elR8GGlFRgJ8 5NNgzihRPUlA1mxReo0wfoYnbTnVvGFwCuz0ErZE3VPANWJCLlHSLTs6jHi+V8VWD2tp sxCta9z/CCB9jt1x4G44U8SijTwKM1zxGjng4jB2mny77NB3UQ5lT4KipWOLZCNXV/+l qv3X2hZ8Q6RjBcWJvza13RvpBc5SEbXerkGPPqmYcskk3+DvHN8PQKWIAMGxikVBB8Xd 84npBtKhsAY/ogFM0tWXB/u6QFEeJDle5SdZYbClqjbj68dXsNQ1rHesh7gvMovHv14S 9pQg== 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=M2nKBndrgkkfLgBcFIBZKqLYyEUMQkxukOt34dxqk4k=; b=r4vvGfHc09418Qbxj39QQHWg+5Ps2pk3Eb2xZMBP7V20z7wPDgd5pGPrXiBgempR2r +AVlAy9rE70ZQ0IVeVyu51B8NwunPjrcuUm+0akhZf/L3s6J/d75ccR1l4dq28Jzjuyo Y29+Q6FHOyPPKmkOx05s2WE5JxHa68a+Kb05+tQ4LLKmD3rMfUq/XwarS082HjcUioR2 JOPkL3JgUKIgt1AjgRH1M8KLGKk2fOUxihY4gFrTHsp3Gj8ADVyTG1qDvbqQ1RzKCIQU 80ukl/90ucLJhEvo00jGdXMbOm+xs5y6t1GUgD4/yaf4h45zcIwAKCpiGFMIQMjlnepN StSg== X-Gm-Message-State: AHPjjUiIiVlWOV7yWY0Dj3D1gpj5X+DuikzbcerH+iBkDsxw5Sd8LQxx eVo7q+nHqdtD8uyQXTpFQLDKH4lOzSUytAsUIp225Q== X-Google-Smtp-Source: AOwi7QB3fs4tuzrn76I6/NTWx6M6G0VixGj0TEguHEN2KbY43NXjWnzgBoYxIwzjbcuoeejSn7X1HEbeE0Rtw8/LSko= X-Received: by 10.107.185.7 with SMTP id j7mr17332628iof.221.1506462057467; Tue, 26 Sep 2017 14:40:57 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Tue, 26 Sep 2017 14:40:56 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:81a8:68cb:54aa:c497] In-Reply-To: References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> From: Warner Losh Date: Tue, 26 Sep 2017 15:40:56 -0600 X-Google-Sender-Auth: LXFhyUQXgcJvmZrfji0szfvSmcc Message-ID: Subject: Re: CUBOX snapshots working? To: Russell Haley Cc: Emmanuel Vadot , freebsd-arm , Ian Lepore Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 21:40:58 -0000 On Tue, Sep 26, 2017 at 3:07 PM, Russell Haley wrote: > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot > wrote: > > On Tue, 26 Sep 2017 12:21:52 -0600 > > Ian Lepore wrote: > > > >> On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > >> > On Tue, 26 Sep 2017 11:32:21 -0600 > >> > Brett Glass wrote: > >> > > >> > > > >> > > One would think that sauce for the goose would be sauce for the > >> > > gander. But is this particular Cubox now useless with FreeBSD? > >> > > And if so, why? It is not an unusual model. The Cubox does work > >> > > if I flash their "Ignition" startup software (which is used to > >> > > bootstrap by downloading various OS images) to the same > >> > > Micro SD card. > >> > > > >> > > --Brett Glass > >> > The problem isn't FreeBSD related, it's U-Boot related. > >> > > >> > You could test build mainline u-boot just to confirm that it isn't > >> > something due to our ports. > >> > > >> > >> If we used to provide working cubox images and we don't anymore, it's > >> hard to call that anything but a freebsd problem. > > > > There is working cubox images, the last one is from yesterday. > > You even say yourself that you did test it and that it worked. > > Do we even know if the snapshot worked for this board ? > > Brett, could you test the 11.0 release for example ? (I don't remember > > if for 11.1 we already switch u-boot or not). > > I believe the change is in the u-boot port itself. However, I don't > think it's a u-boot problem (IMHO), it's a u-boot build configuration > problem. There are different board variants with different hardware > layout. u-boot has code for it, but our build does not account for. > Unless the scripts that build the 11.1 image use a different revision > of the u-boot port, wouldn't it just use the current 2017.7 base? > > I'm trying to figure out how to generate a u-boot with the correct SPL > portion of u-boot. One could pull the SolidRun u-boot repo, or go find > the ports commit before the changeover and see if we can generate the > correct SPL. > > I looked at Mainline u-boot and there is a board directory for solid run. > https://github.com/u-boot/u-boot/blob/master/board/ > solidrun/mx6cuboxi/mx6cuboxi.c > seems to support multiple memory configurations based on defines, so > this should just be a configuration problem. > > We clearly need to start supporting the lower spec'd SolidRun boards > because this has come up a couple of times now since the changeover. > It should be just a matter of creating a port that does the same thing > but generates the correct SPL file? My SOM is a i2eX so I can't be too > much help (and I've also over volunteered myself!). > Creating a new port is like 4 lines long. Generally, you can't mix and match boards and expect u-boot for one board to work with another. This sounds like that's the case (where we support one board, and people are incorrectly using it for others which is causing problems). I'm happy to integrate a new port, or even write one if you can give me the specific configuration that's needed. Warner > Russ > > >> You seem to be implying that this is another problem caused by > >> switching from vendor-specific to mainline uboot. I'm not sure that's > >> the case here, but if it is, be clear: It is purely a freebsd problem, > >> because it was purely our choice (not mine) to switch from something > >> that worked to something that doesn't. > >> > >> -- Ian > > > > Yes, maybe switching to mainline for IMX boards was a premature one, I > > honestly don't have IMX board and don't know which way we should take. > > All I can say is that for TI and Allwinner board, mainline U-Boot is > > better (at least the support is the same). If you want to switch back > > to vendor u-boot for IMX board fell free to do so (as long as you don't > > change the other SoC U-Boot). > > >> > > > >> > > At 08:21 AM 9/26/2017, Ian Lepore wrote: > >> > > > >> > > > > >> > > > I just DLed and booted that snapshot on my Cubox-4i without any > >> > > > problems. As near as I can tell, the only difference is you've > >> > > > got the > >> > > > dual-core chip and mine has the quad. > >> > > > > >> > > > The same u-boot should work for both. At least, that was the > >> > > > case when > >> > > > using the vendor-provided u-boot; the images are now built from > >> > > > mainline u-boot. The output you provided does show that it > >> > > > detected > >> > > > the right kind of chip and amount of ram, so I think it should > >> > > > support > >> > > > both flavors of cubox. > >> > > > > >> > > > -- 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.o > >> > > rg" > >> > > > > > > > -- > > Emmanuel Vadot > > _______________________________________________ > > 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 Tue Sep 26 21:42:43 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77A41E22CB5 for ; Tue, 26 Sep 2017 21:42:43 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from crab.apple.relay.mailchannels.net (crab.apple.relay.mailchannels.net [23.83.208.42]) (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 302AC7C0DE for ; Tue, 26 Sep 2017 21:42:42 +0000 (UTC) (envelope-from ian@freebsd.org) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 849258A709B for ; Tue, 26 Sep 2017 21:17:42 +0000 (UTC) Received: from outbound1a.eu.mailhop.org (unknown [100.96.146.250]) (Authenticated sender: duocircle) by relay.mailchannels.net (Postfix) with ESMTPA id DFF3A8A88C7 for ; Tue, 26 Sep 2017 21:17:41 +0000 (UTC) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [172.20.104.49]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.9.14); Tue, 26 Sep 2017 21:17:42 +0000 X-MC-Relay: Forwarding X-MailChannels-SenderId: _forwarded-from|73.78.92.27 X-MailChannels-Auth-Id: duocircle X-Plucky-Sponge: 77efe4191cc90469_1506460662357_2787366007 X-MC-Loop-Signature: 1506460662357:2416921812 X-MC-Ingress-Time: 1506460662357 X-MHO-User: 1dcdd18d-a300-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 1dcdd18d-a300-11e7-a893-25625093991c; Tue, 26 Sep 2017 21:17:37 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8QLHXbi001963; Tue, 26 Sep 2017 15:17:33 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506460653.73082.156.camel@freebsd.org> Subject: Re: CUBOX snapshots working? From: Ian Lepore To: Russell Haley , Emmanuel Vadot Cc: freebsd-arm Date: Tue, 26 Sep 2017 15:17:33 -0600 In-Reply-To: References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.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: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 21:42:43 -0000 On Tue, 2017-09-26 at 14:07 -0700, Russell Haley wrote: > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot om> wrote: > >=20 > > On Tue, 26 Sep 2017 12:21:52 -0600 > > Ian Lepore wrote: > >=20 > > >=20 > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > > > >=20 > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > > > Brett Glass wrote: > > > >=20 > > > > >=20 > > > > >=20 > > > > > One would think that sauce for the goose would be sauce for > > > > > the > > > > > gander. But is this particular Cubox now useless with > > > > > FreeBSD? > > > > > And if so, why? It is not an unusual model. The Cubox does > > > > > work > > > > > if I flash their "Ignition" startup software (which is used > > > > > to > > > > > bootstrap by downloading various OS images) to the same > > > > > Micro SD card. > > > > >=20 > > > > > --Brett Glass > > > > =A0The problem isn't FreeBSD related, it's U-Boot related. > > > >=20 > > > > =A0You could test build mainline u-boot just to confirm that it > > > > isn't > > > > something due to our ports. > > > >=20 > > > If we used to provide working cubox images and we don't anymore, > > > it's > > > hard to call that anything but a freebsd problem. > > =A0There is working cubox images, the last one is from yesterday. > > =A0You even say yourself that you did test it and that it worked. > > =A0Do we even know if the snapshot worked for this board ? > > =A0Brett, could you test the 11.0 release for example ? (I don't > > remember > > if for 11.1 we already switch u-boot or not). > I believe the change is in the u-boot port itself. However, I don't > think it's a u-boot problem (IMHO), it's a u-boot build configuration > problem. There are different board variants with different hardware > layout. u-boot has code for it, but our build does not account for. > Unless the scripts that build the 11.1 image use a different revision > of the u-boot port, wouldn't it just use the current 2017.7 base? >=20 > I'm trying to figure out how to generate a u-boot with the correct > SPL > portion of u-boot. One could pull the SolidRun u-boot repo, or go > find > the ports commit before the changeover and see if we can generate the > correct SPL. >=20 > I looked at Mainline u-boot and there is a board directory for solid > run. > https://github.com/u-boot/u-boot/blob/master/board/solidrun/mx6cuboxi > /mx6cuboxi.c > seems to support multiple memory configurations based on defines, so > this should just be a configuration problem. >=20 > We clearly need to start supporting the lower spec'd SolidRun boards > because this has come up a couple of times now since the changeover. > It should be just a matter of creating a port that does the same > thing > but generates the correct SPL file? My SOM is a i2eX so I can't be > too > much help (and I've also over volunteered myself!). >=20 > Russ >=20 The old imx6 uboot ports generated a single copy of uboot that would boot dual and quad-core versions of both hummingboard and cubox systems. =A0If the new uboot works only on quad core, that's another regression. =A0It might be possible to extract the u-boot.imx file from a freebsd 10 image to get back to the old one. Ooops. =A0Except it appears those no longer exist. -- Ian From owner-freebsd-arm@freebsd.org Tue Sep 26 22:45:49 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0F67E2466E for ; Tue, 26 Sep 2017 22:45:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B364D7E4BE for ; Tue, 26 Sep 2017 22:45:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id n69so14158321ioi.5 for ; Tue, 26 Sep 2017 15:45:49 -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=ubE2VeE2rXyQeGHRHwgWk2L1KTLMuGi7wBkPRLufq64=; b=yCNk87n5d75w7Wqh3enRsUBhHmjw8D3Z1cd2GhgAcx/YH2r1PaqrrkyJyu4kr8AgTL S6/oBioDvrSgdM6pOrV/n8XI7JCzOzhhhJiyh2MDW/TXRYwqq06zUSg4jRuGiuSwTf0Q DjH82GHuDfQgpup09RNT2Dd0z12ihXW9H26lDQ7p9Brvgl79AGlu1NPdc9xveThdmeNX ZI2acvF9533vbeZP8bh2XJwohIHpj0w4MQwnN4MQ3UhOWJVPZiBXB2O5ASmLpidpR14P IgqYgR6kBoXROgRb5U0t5cYC0yip7U+xThj9oipk0Pig8sWupcO0AVSW69ibHaM5tWpt dZug== 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=ubE2VeE2rXyQeGHRHwgWk2L1KTLMuGi7wBkPRLufq64=; b=iFCliQkIcRHCPAj3Gc9Pu12gnLoLwpDb3lekWz3Lk09Kc/H/+kb6YDJ2HWGnqG2PNf l0Gfsh0Q3FuWao8JUAB7FqqN+28E4RwIe4rru3nQsIdI1BzY/ZphCRz/XlrxFSQFC61p BakfWkNY0t9IVrohzjfN/Ee89yRWqmWnt1O+eSi8saSPOlP32a0kfR3Ffk1rX6f1PzYI YpU3OwGChfUMG/ud51JXww7djXfyM2Pcr7o/lgjtuozlcHswLG5GUeqgNBbGnIOrgVg/ tCb+GOYtZ6YKMwtDqt7xgqwEIHlx2PDERccURNJ9sW0PWGdmwzlcS6sA3k9+U9rXhOx0 ibmw== X-Gm-Message-State: AHPjjUhsZUsqtLAgyEqJdDgZTKeIIX9ZucO+K0uxLTD92ktcsTJa8ZVj uPUNWXn2zFfVX8kXHCag4sje0wnqnXDkj5VnPc16LA== X-Google-Smtp-Source: AOwi7QBtxyckXSE4PxAapdxypJzOYXpBLsknD+xjjPfkrK8xcKpy2MkOUlgJE85pRnUka1+VYTBPHE63jkcZPm8G1cs= X-Received: by 10.107.185.7 with SMTP id j7mr17572277iof.221.1506465949112; Tue, 26 Sep 2017 15:45:49 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Tue, 26 Sep 2017 15:45:48 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <1506460653.73082.156.camel@freebsd.org> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> From: Warner Losh Date: Tue, 26 Sep 2017 16:45:48 -0600 X-Google-Sender-Auth: yRRahXWzkLrHLVituZmTT2tNWd0 Message-ID: Subject: Re: CUBOX snapshots working? To: Ian Lepore Cc: Russell Haley , Emmanuel Vadot , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 22:45:50 -0000 On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore wrote: > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley wrote: > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot > om> wrote: > > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > > > Ian Lepore wrote: > > > > > > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > > > > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > > > > Brett Glass wrote: > > > > > > > > > > > > > > > > > > > > > > > One would think that sauce for the goose would be sauce for > > > > > > the > > > > > > gander. But is this particular Cubox now useless with > > > > > > FreeBSD? > > > > > > And if so, why? It is not an unusual model. The Cubox does > > > > > > work > > > > > > if I flash their "Ignition" startup software (which is used > > > > > > to > > > > > > bootstrap by downloading various OS images) to the same > > > > > > Micro SD card. > > > > > > > > > > > > --Brett Glass > > > > > The problem isn't FreeBSD related, it's U-Boot related. > > > > > > > > > > You could test build mainline u-boot just to confirm that it > > > > > isn't > > > > > something due to our ports. > > > > > > > > > If we used to provide working cubox images and we don't anymore, > > > > it's > > > > hard to call that anything but a freebsd problem. > > > There is working cubox images, the last one is from yesterday. > > > You even say yourself that you did test it and that it worked. > > > Do we even know if the snapshot worked for this board ? > > > Brett, could you test the 11.0 release for example ? (I don't > > > remember > > > if for 11.1 we already switch u-boot or not). > > I believe the change is in the u-boot port itself. However, I don't > > think it's a u-boot problem (IMHO), it's a u-boot build configuration > > problem. There are different board variants with different hardware > > layout. u-boot has code for it, but our build does not account for. > > Unless the scripts that build the 11.1 image use a different revision > > of the u-boot port, wouldn't it just use the current 2017.7 base? > > > > I'm trying to figure out how to generate a u-boot with the correct > > SPL > > portion of u-boot. One could pull the SolidRun u-boot repo, or go > > find > > the ports commit before the changeover and see if we can generate the > > correct SPL. > > > > I looked at Mainline u-boot and there is a board directory for solid > > run. > > https://github.com/u-boot/u-boot/blob/master/board/solidrun/mx6cuboxi > > /mx6cuboxi.c > > seems to support multiple memory configurations based on defines, so > > this should just be a configuration problem. > > > > We clearly need to start supporting the lower spec'd SolidRun boards > > because this has come up a couple of times now since the changeover. > > It should be just a matter of creating a port that does the same > > thing > > but generates the correct SPL file? My SOM is a i2eX so I can't be > > too > > much help (and I've also over volunteered myself!). > > > > Russ > > > > The old imx6 uboot ports generated a single copy of uboot that would > boot dual and quad-core versions of both hummingboard and cubox > systems. If the new uboot works only on quad core, that's another > regression. It might be possible to extract the u-boot.imx file from a > freebsd 10 image to get back to the old one. > > Ooops. Except it appears those no longer exist. Is this a loss of functionality when the changes were upstreamed? Is it a bad configuration on our part? Any idea what might be going on or how to fix it? Warner From owner-freebsd-arm@freebsd.org Tue Sep 26 23:03:39 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13B6AE24CA5 for ; Tue, 26 Sep 2017 23:03:39 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from crab.apple.relay.mailchannels.net (crab.apple.relay.mailchannels.net [23.83.208.42]) (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 BEF427EE7A for ; Tue, 26 Sep 2017 23:03:38 +0000 (UTC) (envelope-from ian@freebsd.org) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id F2A7F107E9E for ; Tue, 26 Sep 2017 22:55:36 +0000 (UTC) Received: from outbound1a.eu.mailhop.org (unknown [100.96.140.210]) (Authenticated sender: duocircle) by relay.mailchannels.net (Postfix) with ESMTPA id 5E292108334 for ; Tue, 26 Sep 2017 22:55:36 +0000 (UTC) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [172.20.66.218]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.9.14); Tue, 26 Sep 2017 22:55:36 +0000 X-MC-Relay: Forwarding X-MailChannels-SenderId: _forwarded-from|73.78.92.27 X-MailChannels-Auth-Id: duocircle X-Irritate-Industry: 6a47e422036f9b0b_1506466536773_824302234 X-MC-Loop-Signature: 1506466536773:1292388998 X-MC-Ingress-Time: 1506466536773 X-MHO-User: cbae7dd5-a30d-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id cbae7dd5-a30d-11e7-a893-25625093991c; Tue, 26 Sep 2017 22:55:31 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8QMtSYn002148; Tue, 26 Sep 2017 16:55:29 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506466528.73082.172.camel@freebsd.org> Subject: Re: CUBOX snapshots working? From: Ian Lepore To: Warner Losh Cc: freebsd-arm Date: Tue, 26 Sep 2017 16:55:28 -0600 In-Reply-To: References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> 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: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 23:03:39 -0000 On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote: > On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore wrote: >=20 > >=20 > > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley wrote: > > >=20 > > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot > > te.c > > > om> wrote: > > > >=20 > > > >=20 > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > > > > Ian Lepore wrote: > > > >=20 > > > > >=20 > > > > >=20 > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > > > > > >=20 > > > > > >=20 > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > > > > > Brett Glass wrote: > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > One would think that sauce for the goose would be sauce > > > > > > > for > > > > > > > the > > > > > > > gander. But is this particular Cubox now useless with > > > > > > > FreeBSD? > > > > > > > And if so, why? It is not an unusual model. The Cubox > > > > > > > does > > > > > > > work > > > > > > > if I flash their "Ignition" startup software (which is > > > > > > > used > > > > > > > to > > > > > > > bootstrap by downloading various OS images) to the same > > > > > > > Micro SD card. > > > > > > >=20 > > > > > > > --Brett Glass > > > > > > =A0The problem isn't FreeBSD related, it's U-Boot related. > > > > > >=20 > > > > > > =A0You could test build mainline u-boot just to confirm that > > > > > > it > > > > > > isn't > > > > > > something due to our ports. > > > > > >=20 > > > > > If we used to provide working cubox images and we don't > > > > > anymore, > > > > > it's > > > > > hard to call that anything but a freebsd problem. > > > > =A0There is working cubox images, the last one is from yesterday. > > > > =A0You even say yourself that you did test it and that it worked. > > > > =A0Do we even know if the snapshot worked for this board ? > > > > =A0Brett, could you test the 11.0 release for example ? (I don't > > > > remember > > > > if for 11.1 we already switch u-boot or not). > > > I believe the change is in the u-boot port itself. However, I > > > don't > > > think it's a u-boot problem (IMHO), it's a u-boot build > > > configuration > > > problem. There are different board variants with different > > > hardware > > > layout. u-boot has code for it, but our build does not account > > > for. > > > Unless the scripts that build the 11.1 image use a different > > > revision > > > of the u-boot port, wouldn't it just use the current 2017.7 base? > > >=20 > > > I'm trying to figure out how to generate a u-boot with the > > > correct > > > SPL > > > portion of u-boot. One could pull the SolidRun u-boot repo, or go > > > find > > > the ports commit before the changeover and see if we can generate > > > the > > > correct SPL. > > >=20 > > > I looked at Mainline u-boot and there is a board directory for > > > solid > > > run. > > > https://github.com/u-boot/u-boot/blob/master/board/solidrun/mx6cu > > > boxi > > > /mx6cuboxi.c > > > seems to support multiple memory configurations based on defines, > > > so > > > this should just be a configuration problem. > > >=20 > > > We clearly need to start supporting the lower spec'd SolidRun > > > boards > > > because this has come up a couple of times now since the > > > changeover. > > > It should be just a matter of creating a port that does the same > > > thing > > > but generates the correct SPL file? My SOM is a i2eX so I can't > > > be > > > too > > > much help (and I've also over volunteered myself!). > > >=20 > > > Russ > > >=20 > > The old imx6 uboot ports generated a single copy of uboot that > > would > > boot dual and quad-core versions of both hummingboard and cubox > > systems.=A0=A0If the new uboot works only on quad core, that's anothe= r > > regression.=A0=A0It might be possible to extract the u-boot.imx file > > from a > > freebsd 10 image to get back to the old one. > >=20 > > Ooops.=A0=A0Except it appears those no longer exist. >=20 > Is this a loss of functionality when the changes were upstreamed? Is > it a > bad configuration on our part? Any idea what might be going on or how > to > fix it? The vendor uboot worked well. =A0The generic mainline, apparently not so much. =A0It may indicate that the vendor didn't upstream everything. =A0I haven't worked much with the new imx6 uboot packages because for me they're completely unusable because they lack support for netbooting. =A0(If you feel tempted to say something about efi and netbooting, please provide links to how-to documentation at the very least, and an example that works for armv6 would be even better.) -- Ian From owner-freebsd-arm@freebsd.org Tue Sep 26 23:05:43 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F142E24D53 for ; Tue, 26 Sep 2017 23:05:43 +0000 (UTC) (envelope-from wlosh@bsdimp.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 D4D497EF11 for ; Tue, 26 Sep 2017 23:05:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22c.google.com with SMTP id d192so9603288itd.1 for ; Tue, 26 Sep 2017 16:05: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=0cITd6YkJTYzlLZdrfVDdt+oxKM+kv8KlvDeoEaStgM=; b=K4KqiXJUEDeBRAQqNpeuTrODuca8Mu4/TGdiMDuXQTtSR94P+F3ck+O120rdkoGD0g 5bA0I/NPh0K2MLFDS45mEY4OA0e9hbG8T0iq5hAmCdveAwj7dWoQXPnGvSurfkI1icqw SFMhJVxkyhvZKCcMO82SGSQ+DmE31YVpRhrG9a/Xdls6Rgucgl5divH08vCuyAr2uQMo NkLceBP2yUc8Dw6+PSIKm0vb3XGokRX4XMKn8oa3WXM3eN/eOS3rYO0lb4lxbLFkWBW9 RmDthzTN9cTYnmgC7OvoEKTC/yr/nQ1AnzlDX/Pr1+A2iqEj6oMUs4wNxGlT/eLya4yr n80A== 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=0cITd6YkJTYzlLZdrfVDdt+oxKM+kv8KlvDeoEaStgM=; b=FhLYkSAdpw9X462A80MDoSSYNadEmxwRq8aB4pdYHgMGGGLUEZmVumQyQarPxMGN4l a56LWIIwjnkE6MjKC7GfLJHK8q3TPr2mBIAbBFkkvkl3LEYCax1JzL0+G4YcaBtymu5r b43Q93HaM6mtb5FA8wnX6aNo0O+w2wjW/vJcizA1jhUU+yMjhW/R/eL+6JgrsZu8AEi0 CgNltSf6/ktmUjKZc11YsfHfz9JLL8BzU6AtBgCxfCAC3R3K0/e6Umf2wTDSgPZWoVE0 rdV0pbjr4qf5kIq4mK3uDQTlpAue3nZe4PEJ8uiKsIW6nliFqsCrsDFGddcL0G+h1vHB 91Tw== X-Gm-Message-State: AHPjjUhxgSPVBA3aZCoiwil7xpJCSlyPbF5lRgfJs8RHWyPPOro4wS7x ps0gIT44Zbes5AM6YRsHkY3M/xs5M1UdObOlLYjxQA== X-Google-Smtp-Source: AOwi7QBAp7tUYpNfvB8K9Ubo7DSXdhRW/1G1/BGvBiSFpTce87OMp1/C129vmdA+SaeGc8d7znbS+GjN31xym1gx+pU= X-Received: by 10.36.6.18 with SMTP id 18mr9059513itv.15.1506467142141; Tue, 26 Sep 2017 16:05:42 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Tue, 26 Sep 2017 16:05:40 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <1506466528.73082.172.camel@freebsd.org> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> From: Warner Losh Date: Tue, 26 Sep 2017 17:05:40 -0600 X-Google-Sender-Auth: R77Y7cpka2BW_Lep1f9iUOJgt30 Message-ID: Subject: Re: CUBOX snapshots working? To: Ian Lepore Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 23:05:43 -0000 On Tue, Sep 26, 2017 at 4:55 PM, Ian Lepore wrote: > On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote: > > On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore wrote: > > > > > > > > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley wrote: > > > > > > > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot > > > te.c > > > > om> wrote: > > > > > > > > > > > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > > > > > Ian Lepore wrote: > > > > > > > > > > > > > > > > > > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > > > > > > > > > > > > > > > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > > > > > > Brett Glass wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One would think that sauce for the goose would be sauce > > > > > > > > for > > > > > > > > the > > > > > > > > gander. But is this particular Cubox now useless with > > > > > > > > FreeBSD? > > > > > > > > And if so, why? It is not an unusual model. The Cubox > > > > > > > > does > > > > > > > > work > > > > > > > > if I flash their "Ignition" startup software (which is > > > > > > > > used > > > > > > > > to > > > > > > > > bootstrap by downloading various OS images) to the same > > > > > > > > Micro SD card. > > > > > > > > > > > > > > > > --Brett Glass > > > > > > > The problem isn't FreeBSD related, it's U-Boot related. > > > > > > > > > > > > > > You could test build mainline u-boot just to confirm that > > > > > > > it > > > > > > > isn't > > > > > > > something due to our ports. > > > > > > > > > > > > > If we used to provide working cubox images and we don't > > > > > > anymore, > > > > > > it's > > > > > > hard to call that anything but a freebsd problem. > > > > > There is working cubox images, the last one is from yesterday. > > > > > You even say yourself that you did test it and that it worked. > > > > > Do we even know if the snapshot worked for this board ? > > > > > Brett, could you test the 11.0 release for example ? (I don't > > > > > remember > > > > > if for 11.1 we already switch u-boot or not). > > > > I believe the change is in the u-boot port itself. However, I > > > > don't > > > > think it's a u-boot problem (IMHO), it's a u-boot build > > > > configuration > > > > problem. There are different board variants with different > > > > hardware > > > > layout. u-boot has code for it, but our build does not account > > > > for. > > > > Unless the scripts that build the 11.1 image use a different > > > > revision > > > > of the u-boot port, wouldn't it just use the current 2017.7 base? > > > > > > > > I'm trying to figure out how to generate a u-boot with the > > > > correct > > > > SPL > > > > portion of u-boot. One could pull the SolidRun u-boot repo, or go > > > > find > > > > the ports commit before the changeover and see if we can generate > > > > the > > > > correct SPL. > > > > > > > > I looked at Mainline u-boot and there is a board directory for > > > > solid > > > > run. > > > > https://github.com/u-boot/u-boot/blob/master/board/solidrun/mx6cu > > > > boxi > > > > /mx6cuboxi.c > > > > seems to support multiple memory configurations based on defines, > > > > so > > > > this should just be a configuration problem. > > > > > > > > We clearly need to start supporting the lower spec'd SolidRun > > > > boards > > > > because this has come up a couple of times now since the > > > > changeover. > > > > It should be just a matter of creating a port that does the same > > > > thing > > > > but generates the correct SPL file? My SOM is a i2eX so I can't > > > > be > > > > too > > > > much help (and I've also over volunteered myself!). > > > > > > > > Russ > > > > > > > The old imx6 uboot ports generated a single copy of uboot that > > > would > > > boot dual and quad-core versions of both hummingboard and cubox > > > systems. If the new uboot works only on quad core, that's another > > > regression. It might be possible to extract the u-boot.imx file > > > from a > > > freebsd 10 image to get back to the old one. > > > > > > Ooops. Except it appears those no longer exist. > > > > Is this a loss of functionality when the changes were upstreamed? Is > > it a > > bad configuration on our part? Any idea what might be going on or how > > to > > fix it? > > The vendor uboot worked well. The generic mainline, apparently not so > much. It may indicate that the vendor didn't upstream everything. I > haven't worked much with the new imx6 uboot packages because for me > they're completely unusable because they lack support for netbooting. > (If you feel tempted to say something about efi and netbooting, please > provide links to how-to documentation at the very least, and an example > that works for armv6 would be even better.) > I didn't think that we were enabling EFI + armv6 on anything yet by default... Can't help you there. Warner From owner-freebsd-arm@freebsd.org Wed Sep 27 01:45:30 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C605BE28136 for ; Wed, 27 Sep 2017 01:45:30 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh605-vm0.bullet.mail.ssk.yahoo.co.jp (nh605-vm0.bullet.mail.ssk.yahoo.co.jp [182.22.90.73]) by mx1.freebsd.org (Postfix) with SMTP id 673AA837FD for ; Wed, 27 Sep 2017 01:45:30 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [182.22.66.106] by nh605.bullet.mail.ssk.yahoo.co.jp with NNFMP; 27 Sep 2017 01:42:15 -0000 Received: from [182.22.91.131] by t604.bullet.mail.ssk.yahoo.co.jp with NNFMP; 27 Sep 2017 01:42:15 -0000 Received: from [127.0.0.1] by omp604.mail.ssk.yahoo.co.jp with NNFMP; 27 Sep 2017 01:42:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 641319.56749.bm@omp604.mail.ssk.yahoo.co.jp Received: (qmail 45024 invoked by uid 60001); 27 Sep 2017 01:42:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1506476535; bh=QKA1nXTX4JAN7uhzoJFMR2LlzX19QD5vD+1vtqA9M88=; 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=kKcx4/ZqZe2B5ZVwafit9AjfvZjNEEqedkatQUDDmQtkI7g7xP0aYXLdQsGmfEIbBvyHCG3KtLzu+pqq/ozASqy+FDPQMoJSfeRM4f7N5TbYBGNPmS74uG9/mp7OpTDPcpNv3IqQkp0N6v+xJMyYuxU9Bo0Cy7fASm6WIZ2Tsxo= 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=lBuln/d4lEPoIzd83pnDYpytxQE+fvWreTA4hVnjW0vSy/9SVIhPtK6sAieAs5vmBzja7JP6uWemvu6yfaOj/ds/vKzH/AHyOD1T/IhsobE6UX/ZKN6JrIvNun1cFtIxhUawSLEghfMr3/Jqk9EeIbHUt0HGwjqqP796pMwyP64=; Message-ID: <323129.32331.qm@web101720.mail.ssk.yahoo.co.jp> X-YMail-OSG: _fQbKSsVM1kKjwORBxBK9kjzDcqLM8Ar.6mUZzLnOTLfKtFS3dz8aQ45NdXwp8GoHmPRqILZ_HK2_yuAIHnsrymL3c9CL_iLAFIJLLIa2FFDPA7Vm847pJ1k56iVNjwhB3yy2mWJWkzw_2m9QWhCQeNwRh3q4E3mtv883yoxNFE6yyAbHoVT0qWr8ejFOHOI2j14xUJtg2_3URTdXwWptBOeNXGTXDW9SWNFtbg_9E3oYQ0OevjZjtm6PhMVP4y59OAhcUPZ5UZdqTIpCNRRBuNNolCgyp9XWohwuS11K0bsvopemS7Qis6noLkdEF1N298TCirbAXFkpHb1gYFtteVKsLwoT4nI.DyJCYh40syENswZXTaWdPVjBXKcYzZhohxlGVngjiz5STNGtii3fkLYTMUGXq9XfhVJECzcDQzDtzUTi2nTlua_qfQv6HBCg2BYR8XBpE7O8WIhRNRnNmYm6TxqUawG.Yujwmd_42sWaCQpmxBdAgpQSc8jb3i1SB3zcVMJwN1L6lbJd2CUj2DhW.LRhDBVnJmieOtfRl.GN6fb_E6OsJTj2WXaB7HHCYKor0JHGUY2OZkfFmeTssRVi8rzi34Froy4JEQyoZs- Received: from [210.20.200.168] by web101720.mail.ssk.yahoo.co.jp via HTTP; Wed, 27 Sep 2017 10:42:14 JST X-Mailer: YahooMailWebService/0.8.111_73 X-YMail-JAS: fG2wkLgVM1mwJlz23eXLA0SLo7.Xp5VXNxfH_8CJvib6MhBmwVs8xGu3ERbufcx1XKJqND8USEnDxTAIcMXgQH6HJ7ylMteVEHoodgXj0D2PYjbLIUGOaPoNy54d.9.WuukV References: <509836.65470.qm@web101704.mail.ssk.yahoo.co.jp> <818825.27559.qm@web101705.mail.ssk.yahoo.co.jp> Date: Wed, 27 Sep 2017 10:42:14 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Re: Hang up at boot on armv5t To: "freebsd-arm@freebsd.org" In-Reply-To: <818825.27559.qm@web101705.mail.ssk.yahoo.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 01:45:30 -0000 Hi.=0A=0AI still investigate this problem.=0A=0AI found other problem.=0A= =0AThis commit make panic on armv5t(RT1310).=0A=0Acommit 1db0a229476afafe06= f2bc9749f6738e6cc6d047=0AAuthor: markj =0ADate: =A0 Thu = Sep 7 21:43:39 2017 +0000=0A=0Ahttps://gist.github.com/yamori813/dc37400859= 96af505d6694461751706f=0A=0A=0AHiroki Mori=0A=0A=0A----- Original Message -= ----=0A> From: Mori Hiroki =0A> To: Warner Losh =0A> Cc: "freebsd-arm@freebsd.org" =0A= > Date: 2017/9/19, Tue 15:27=0A> Subject: Re: Hang up at boot on armv5t=0A>= =0A> Hi=0A> =0A> ----- Original Message -----=0A>> From: Warner Losh =0A>> To: Mori Hiroki =0A>> Cc: "freebsd= -arm@freebsd.org" =0A>> Date: 2017/9/19, Tue 00:32= =0A>> Subject: Re: Hang up at boot on armv5t=0A>> =0A>> =0A>> =0A>> =0A>> = =0A>> =0A>> On Mon, Sep 18, 2017 at 12:59 AM, Mori Hiroki =0A> wrote:=0A>> =0A>> Hi=0A>>> =0A>>> Now head is hung up at boot o= n armv5t.=A0=0A>>> =0A>>> KDB: debugger backends: ddb=0A>>> KDB: current ba= ckend: ddb=0A>>> Copyright (c) 1992-2017 The FreeBSD Project.=0A>>> Copyrig= ht (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994=0A>>> =A0= =A0 =A0 =A0 The Regents of the University of California. All rights =0A> r= eserved.=0A>>> FreeBSD is a registered trademark of The FreeBSD Foundation.= =0A>>> FreeBSD 12.0-CURRENT #2 a3dbcdd(zrouter)-dirty: Mon Sep 11 18:04:22 = JST =0A> 2017=0A>>> =A0 =A0 hiroki@microserver:/storage/ home/hiroki/obj/st= orage/home/ =0A> hiroki/zrouter/tmp/=0A>>> arm.arm/storage/home/hiroki/ fre= ebsd/sys/Buffalo_WZR2-G300N arm=0A>>> FreeBSD clang version 5.0.0 (tags/REL= EASE_500/final 312559) (based on =0A> LLVM 5.0.0=0A>>> svn)=0A>>> =0A>>> La= st month build is fine.=0A>>> =0A>>> https://gist.github.com/ yamori813/ 88= 224f1c96c9c592fb611b12a15e4a b5=0A>> =0A>> =0A>> You might want to do a bin= ary search between the working and broken builds =0A> to see where it break= s. Without that, it's hard to make progress.=0A>> =0A>> =0A>> Warner=A0=0A>= =0A> =0A> This is RT1310 build by sys/arm/ralink.=0A> =0A> I get debug log= by VERBOSE_SYSINIT.=0A> =0A> =0A> Copyright (c) 1992-2017 The FreeBSD Proj= ect.=0A> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993= , 1994=0A> =A0 =A0 =A0 =A0 The Regents of the University of California. All= rights reserved.=0A> FreeBSD is a registered trademark of The FreeBSD Foun= dation.=0A> FreeBSD 12.0-CURRENT #1 a3dbcdd(zrouter)-dirty: Tue Sep 19 15:0= 3:43 JST 2017=0A> =A0 =A0 hiroki@microserver:/storage/home/hiroki/obj/stora= ge/home/hiroki/zrouter/tmp/=0A> arm.arm/storage/home/hiroki/freebsd/sys/Buf= falo_WZR2-G300N arm=0A> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final= 312559) (based on LLVM 5.0.0=0A> svn)=0A> subsystem 1000000=0A> =A0=A0 0xc= 01c1674(0)... done.=0A> =A0=A0 0xc01d3a0c(0)... done.=0A> subsystem 1800000= =0A> =A0=A0 0xc00b9cb4(0)... done.=0A> =A0=A0 0xc0097fc4(0)... done.=0A> = =A0=A0 0xc0097c00(0xc0280580)...=A0=0A> =0A> I checked last address by objd= ump -D.=0A> =0A> c0097c00 :=0A> c0280580 :=0A> =0A> Wh= at is wrong ?=0A> =0A> I use git repository on build. If I change git branc= h then arm platform is build =0A> take=0A> =0A> =A06 hour by my server. It = is very hard debugging.=A0=0A> =0A> Hiroki Mori=0A> =0A> __________________= _____________________________=0A> freebsd-arm@freebsd.org mailing list=0A> = https://lists.freebsd.org/mailman/listinfo/freebsd-arm=0A> To unsubscribe, = send any mail to "freebsd-arm-unsubscribe@freebsd.org"=0A> From owner-freebsd-arm@freebsd.org Wed Sep 27 03:55:55 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12CC5E29DE5 for ; Wed, 27 Sep 2017 03:55:55 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh501-vm4.bullet.mail.kks.yahoo.co.jp (nh501-vm4.bullet.mail.kks.yahoo.co.jp [183.79.56.134]) by mx1.freebsd.org (Postfix) with SMTP id 8529E1D87 for ; Wed, 27 Sep 2017 03:55:54 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.140] by nh501.bullet.mail.kks.yahoo.co.jp with NNFMP; 27 Sep 2017 03:55:46 -0000 Received: from [183.79.100.137] by t503.bullet.mail.kks.yahoo.co.jp with NNFMP; 27 Sep 2017 03:55:46 -0000 Received: from [127.0.0.1] by omp506.mail.kks.yahoo.co.jp with NNFMP; 27 Sep 2017 03:55:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 588498.99211.bm@omp506.mail.kks.yahoo.co.jp Received: (qmail 49743 invoked by uid 60001); 27 Sep 2017 03:55:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1506484546; bh=3Tdxhn7Ke/1ACAZ3xuUXXp++OmM1S2hOCimawv3rshU=; 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=G+Y+IgnCsH+S0Yu9xrRrEvqQH2V5RQjL8OGvo1bMaxk9nKZ6ZcW8z95hWwC3m64DKy6OEk0zuGojMRE4DGb/3ACYED40eUHceuhhsU63E+Fkw0TL0/duXucYPe2dIsvuPb7k/apW7vSMn+RxsnLKWRNO5zi2fFM8t+mblqlGu4I= 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=rta5v+OJGG7bCjHSQV7bJr+8fY38JLvqbJqZcOmPjsuehmhgIvOMY0IM/mI8vyMlCgGnDQFZ5E2SOgZ9U583tbBRRPnbTcO+AICqYl4Q1QO13/stmQiABMwsY9UMWZvwHdcXPkrK6hi/bSYf0cTZ2UWsovYUg7G4WFbIIhjG/R4=; Message-ID: <317452.45869.qm@web101717.mail.ssk.yahoo.co.jp> X-YMail-OSG: 1YcEJ2kVM1mdihHozsaS1TGKw91AVXwQyUd97MQDLODpoF.1u3Ln1KbLWoddoXYXTSq_jeY_I7yysAkn8oMdrxf6cGZyCLZy.F.cqZJ9NVOuVbr8CWBlDu22fvCWMUHvA4ZAAVn9T5.mQRjMf5VLP0t3cMVdn8DFd2gMZ5M9qJXbcmT.AqFW5HQQDYqwhH.TScej0XH6_MKLjHYEuT7c1y.RqFwHZdWyjbGNn5GiS7GTtgCEb3cPUOnuF7r7E9Wt2mSf7JEr0u4Fa_.OWKU.X3DbyXBn.PN9gbAoWSXXoJVr8frs06mivAg2I7ApeYrjpJTCFlYZbJyjocB9GOZxFYvplnW7LeBbg.UTOt3oTPm8z8KQbEepBSzvhjtdtNhT.VFB.9nUaG1IATacl2x..h2opTJbhi3.mqNnso8RS57aIxaZ6_WcBxs9zun6aHiydswk8GHXbmj8bzt6ql975zaOzmKnD9zn0lT3I.JFl9H74g50ZeQhVRPYKV0xwpuGDnQv8wozH3Qi6aJs6SDUEVQr4p4ceQI7Od9z3Vi6FuSfdXEce6dSbNwJ9kyAFCo6bKGnLzBxgX2D7kNKbifLbDgFNxB0Ppfi4U8j3hwqf8.3LWEJ3WlFKqWup3aMKHGSmGHKi06WayW6zIAWYMVxu21J Received: from [210.20.200.168] by web101717.mail.ssk.yahoo.co.jp via HTTP; Wed, 27 Sep 2017 12:55:45 JST X-Mailer: YahooMailWebService/0.8.111_73 X-YMail-JAS: DkFQb6sVM1lAuYxaccU_6f2x5dK0u4yfTwOf57aGyyIc3C8pYjsU0.VLdcQ_SWplbvzwWaAM1c9i8tq3abAtgh5RyZWW_0uopiUMviWeqQPQ0lkWp3Rc4qjDWpqNhnkX6i3X References: <509836.65470.qm@web101704.mail.ssk.yahoo.co.jp> <818825.27559.qm@web101705.mail.ssk.yahoo.co.jp> <323129.32331.qm@web101720.mail.ssk.yahoo.co.jp> Date: Wed, 27 Sep 2017 12:55:45 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Re: Hang up at boot on armv5t To: "freebsd-arm@freebsd.org" In-Reply-To: <323129.32331.qm@web101720.mail.ssk.yahoo.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 03:55:55 -0000 Hi.=0A=0AI found out hang up problem cause of this commit.=0A=0Acommit 20b4= bc44be9bc985b74f8d5a01a24e302e2a44ff=0AAuthor: mjg =0ADate= : =A0 Fri Sep 8 20:09:14 2017 +0000=0A=0AHow to fix these commit ?=0A=0AHir= oki Mori=0A=0A=0A----- Original Message -----=0A> From: Mori Hiroki =0A> To: "freebsd-arm@freebsd.org" =0A> Cc: =0A> Date: 2017/9/27, Wed 10:42=0A> Subject: Re: Hang up at boot = on armv5t=0A> =0A> Hi.=0A> =0A> I still investigate this problem.=0A> =0A> = I found other problem.=0A> =0A> This commit make panic on armv5t(RT1310).= =0A> =0A> commit 1db0a229476afafe06f2bc9749f6738e6cc6d047=0A> Author: markj= =0A> Date: =A0 Thu Sep 7 21:43:39 2017 +0000=0A> =0A> h= ttps://gist.github.com/yamori813/dc3740085996af505d6694461751706f=0A> =0A> = =0A> Hiroki Mori=0A> =0A> =0A> ----- Original Message -----=0A>> From: Mor= i Hiroki =0A>> To: Warner Losh =0A>= > Cc: "freebsd-arm@freebsd.org" =0A>> Date: 2017= /9/19, Tue 15:27=0A>> Subject: Re: Hang up at boot on armv5t=0A>> =0A>> H= i=0A>> =0A>> ----- Original Message -----=0A>>> From: Warner Losh =0A>>> To: Mori Hiroki =0A>>> Cc: "freeb= sd-arm@freebsd.org" =0A>>> Date: 2017/9/19, Tue 0= 0:32=0A>>> Subject: Re: Hang up at boot on armv5t=0A>>> =0A>>> =0A>>> =0A>= >> =0A>>> =0A>>> =0A>>> On Mon, Sep 18, 2017 at 12:59 AM, Mori Hiroki =0A>= =0A>> wrote:=0A>>> =0A>>> Hi=0A>>>> =0A>>>> Now= head is hung up at boot on armv5t.=A0=0A>>>> =0A>>>> KDB: debugger backen= ds: ddb=0A>>>> KDB: current backend: ddb=0A>>>> Copyright (c) 1992-2017 T= he FreeBSD Project.=0A>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 198= 9, 1991, 1992, 1993, =0A> 1994=0A>>>> =A0 =A0 =A0 =A0 The Regents of the U= niversity of California. All rights =0A>> reserved.=0A>>>> FreeBSD is a r= egistered trademark of The FreeBSD Foundation.=0A>>>> FreeBSD 12.0-CURRENT= #2 a3dbcdd(zrouter)-dirty: Mon Sep 11 18:04:22 =0A> JST =0A>> 2017=0A>>>>= =A0 =A0 hiroki@microserver:/storage/ home/hiroki/obj/storage/home/ =0A>> = hiroki/zrouter/tmp/=0A>>>> arm.arm/storage/home/hiroki/ freebsd/sys/Buffa= lo_WZR2-G300N arm=0A>>>> FreeBSD clang version 5.0.0 (tags/RELEASE_500/fin= al 312559) (based =0A> on =0A>> LLVM 5.0.0=0A>>>> svn)=0A>>>> =0A>>>> La= st month build is fine.=0A>>>> =0A>>>> https://gist.github.com/ yamori813/= 88224f1c96c9c592fb611b12a15e4a =0A> b5=0A>>> =0A>>> =0A>>> You might want= to do a binary search between the working and broken =0A> builds =0A>> to= see where it breaks. Without that, it's hard to make progress.=0A>>> =0A>>= > =0A>>> Warner=A0=0A>> =0A>> =0A>> This is RT1310 build by sys/arm/ralin= k.=0A>> =0A>> I get debug log by VERBOSE_SYSINIT.=0A>> =0A>> =0A>> Copyri= ght (c) 1992-2017 The FreeBSD Project.=0A>> Copyright (c) 1979, 1980, 1983= , 1986, 1988, 1989, 1991, 1992, 1993, 1994=0A>> =A0 =A0 =A0 =A0 The Regent= s of the University of California. All rights reserved.=0A>> FreeBSD is a = registered trademark of The FreeBSD Foundation.=0A>> FreeBSD 12.0-CURRENT = #1 a3dbcdd(zrouter)-dirty: Tue Sep 19 15:03:43 JST =0A> 2017=0A>> =A0 =A0 = =0A> hiroki@microserver:/storage/home/hiroki/obj/storage/home/hiroki/zroute= r/tmp/=0A>> arm.arm/storage/home/hiroki/freebsd/sys/Buffalo_WZR2-G300N arm= =0A>> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based o= n LLVM =0A> 5.0.0=0A>> svn)=0A>> subsystem 1000000=0A>> =A0=A0 0xc01c167= 4(0)... done.=0A>> =A0=A0 0xc01d3a0c(0)... done.=0A>> subsystem 1800000= =0A>> =A0=A0 0xc00b9cb4(0)... done.=0A>> =A0=A0 0xc0097fc4(0)... done.=0A= >> =A0=A0 0xc0097c00(0xc0280580)...=A0=0A>> =0A>> I checked last address = by objdump -D.=0A>> =0A>> c0097c00 :=0A>> c0280580 := =0A>> =0A>> What is wrong ?=0A>> =0A>> I use git repository on build. If = I change git branch then arm platform is =0A> build =0A>> take=0A>> =0A>> = =A06 hour by my server. It is very hard debugging.=A0=0A>> =0A>> Hiroki M= ori=0A>> =0A>> _______________________________________________=0A>> freeb= sd-arm@freebsd.org mailing list=0A>> https://lists.freebsd.org/mailman/lis= tinfo/freebsd-arm=0A>> To unsubscribe, send any mail to =0A> "freebsd-arm-= unsubscribe@freebsd.org"=0A>> =0A> ________________________________________= _______=0A> freebsd-arm@freebsd.org mailing list=0A> https://lists.freebsd.= org/mailman/listinfo/freebsd-arm=0A> To unsubscribe, send any mail to "free= bsd-arm-unsubscribe@freebsd.org"=0A> From owner-freebsd-arm@freebsd.org Wed Sep 27 04:01:54 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C6A3E29F71 for ; Wed, 27 Sep 2017 04:01:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EA24203E for ; Wed, 27 Sep 2017 04:01:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id d16so14570664ioj.3 for ; Tue, 26 Sep 2017 21:01:54 -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=bJtjx3aZzX6sg9Y+zoFIEXwOhnpGduJGZIt2DHfg85Y=; b=IKOytLxWtZibVD4IhLYqXnJyCXkTv4baCMHcUuTRrSHuiQd5r1mNMqi3yT1it1rIYX ApyRgfHavJTG+TGfzBnTsFlw375Cwht07uzJNM3rnzHasyXX7/LBtUMiX3PXTZNg0JbI DmkP7WY8v0/puqCaVHzw43cKUCvkXcuFFNIs+pnJHDD9C5NnBoOmwyHZ3w9c53Uewh3s 4oRJVhC6x5QmxCwOkPUym1jReuaPH5sD7PHujaCOT4Daw61VHqW3v6XKmj4HpQcoe5Qj bplj67raTv+9+ts+hQyoCeZp8PBKzImsBPyvLMSiyguWq3r1S4c/e6UGJO//ZP6TsfQf hVtA== 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=bJtjx3aZzX6sg9Y+zoFIEXwOhnpGduJGZIt2DHfg85Y=; b=ocxiqZMGfvwgX4B/7OFxwnmdYEXgXpTFUh/OIPaDfC27u7SXC7d0lkeoj8N3b0mETm rEBm2FIp6kBu3DjDhgwhlR4Pr9Qtupl1HiE6OmH2S8zwWBzkJqeJ+z0tRBKn5Zb9Y924 b7meWgz90DEm9ogLZFnk4QYmJ+OvC1fs3Az4r1NN2dDDntFILmUIXsuOwlGUMNkhCxHP NDZ7fvPoECc5fuKGMC7WgutaJP4H4YzrZ22fm1SqVavbhCyGugYeqnLvXFpST+dGbLFs Bd4c0xr9w18tsJD/XAz1mRHhOiOQF4xe+Pw5SJUBPmV0IYSkmAEDqoQjYBDWP/yH32F2 Re0g== X-Gm-Message-State: AMCzsaVNRpWEFrGsGgdxSwMD6AYsBRCAIJBriYhGezCzoom8ao43Aw/Q ZC6L/4+qYt8VnTUoMEY51G4Hh1EmuqMHKMDFt8n30A== X-Google-Smtp-Source: AOwi7QBFMchU/ES8vBGhLrkSIKt44nAxvpwM6O0EgUsauvAJngs/z4Vf3Uim11qex/vLhr1dkuZ6+exvSXLg8hERYDs= X-Received: by 10.107.7.161 with SMTP id g33mr89001ioi.169.1506484913230; Tue, 26 Sep 2017 21:01:53 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Tue, 26 Sep 2017 21:01:52 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <317452.45869.qm@web101717.mail.ssk.yahoo.co.jp> References: <509836.65470.qm@web101704.mail.ssk.yahoo.co.jp> <818825.27559.qm@web101705.mail.ssk.yahoo.co.jp> <323129.32331.qm@web101720.mail.ssk.yahoo.co.jp> <317452.45869.qm@web101717.mail.ssk.yahoo.co.jp> From: Warner Losh Date: Tue, 26 Sep 2017 22:01:52 -0600 X-Google-Sender-Auth: 68Rv_VYs-D1MJikBOq95yJNtWkg Message-ID: Subject: Re: Hang up at boot on armv5t To: Mori Hiroki , Mateusz Guzik Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 04:01:54 -0000 Well, you could do something cheezy like #ifndef arm :) If you do that in the latest sources, does it solve the problem? diff --git a/sys/sys/systm.h b/sys/sys/systm.h index ddebe0a6843..484784466a3 100644 --- a/sys/sys/systm.h +++ b/sys/sys/systm.h @@ -258,12 +258,14 @@ void hexdump(const void *ptr, int length, const char *hdr, int flags); #define ovbcopy(f, t, l) bcopy((f), (t), (l)) void bcopy(const void * _Nonnull from, void * _Nonnull to, size_t len); void bzero(void * _Nonnull buf, size_t len); +#ifndef arm #define bzero(buf, len) ({ \ if (__builtin_constant_p(len) && (len) <= 64) \ __builtin_memset((buf), 0, (len)); \ else \ bzero((buf), (len)); \ }) +#endif void explicit_bzero(void * _Nonnull, size_t); void *memcpy(void * _Nonnull to, const void * _Nonnull from, size_t len); And is this built with gcc or clang? What version? Warner On Tue, Sep 26, 2017 at 9:55 PM, Mori Hiroki wrote: > Hi. > > I found out hang up problem cause of this commit. > > commit 20b4bc44be9bc985b74f8d5a01a24e302e2a44ff > Author: mjg > Date: Fri Sep 8 20:09:14 2017 +0000 > > How to fix these commit ? > > Hiroki Mori > > > ----- Original Message ----- > > From: Mori Hiroki > > To: "freebsd-arm@freebsd.org" > > Cc: > > Date: 2017/9/27, Wed 10:42 > > Subject: Re: Hang up at boot on armv5t > > > > Hi. > > > > I still investigate this problem. > > > > I found other problem. > > > > This commit make panic on armv5t(RT1310). > > > > commit 1db0a229476afafe06f2bc9749f6738e6cc6d047 > > Author: markj > > Date: Thu Sep 7 21:43:39 2017 +0000 > > > > https://gist.github.com/yamori813/dc3740085996af505d6694461751706f > > > > > > Hiroki Mori > > > > > > ----- Original Message ----- > >> From: Mori Hiroki > >> To: Warner Losh > >> Cc: "freebsd-arm@freebsd.org" > >> Date: 2017/9/19, Tue 15:27 > >> Subject: Re: Hang up at boot on armv5t > >> > >> Hi > >> > >> ----- Original Message ----- > >>> From: Warner Losh > >>> To: Mori Hiroki > >>> Cc: "freebsd-arm@freebsd.org" > >>> Date: 2017/9/19, Tue 00:32 > >>> Subject: Re: Hang up at boot on armv5t > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Mon, Sep 18, 2017 at 12:59 AM, Mori Hiroki > > > >> wrote: > >>> > >>> Hi > >>>> > >>>> Now head is hung up at boot on armv5t. > >>>> > >>>> KDB: debugger backends: ddb > >>>> KDB: current backend: ddb > >>>> Copyright (c) 1992-2017 The FreeBSD Project. > >>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > > 1994 > >>>> The Regents of the University of California. All rights > >> reserved. > >>>> FreeBSD is a registered trademark of The FreeBSD Foundation. > >>>> FreeBSD 12.0-CURRENT #2 a3dbcdd(zrouter)-dirty: Mon Sep 11 18:04:22 > > JST > >> 2017 > >>>> hiroki@microserver:/storage/ home/hiroki/obj/storage/home/ > >> hiroki/zrouter/tmp/ > >>>> arm.arm/storage/home/hiroki/ freebsd/sys/Buffalo_WZR2-G300N arm > >>>> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based > > on > >> LLVM 5.0.0 > >>>> svn) > >>>> > >>>> Last month build is fine. > >>>> > >>>> https://gist.github.com/ yamori813/ 88224f1c96c9c592fb611b12a15e4a > > b5 > >>> > >>> > >>> You might want to do a binary search between the working and broken > > builds > >> to see where it breaks. Without that, it's hard to make progress. > >>> > >>> > >>> Warner > >> > >> > >> This is RT1310 build by sys/arm/ralink. > >> > >> I get debug log by VERBOSE_SYSINIT. > >> > >> > >> Copyright (c) 1992-2017 The FreeBSD Project. > >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > 1994 > >> The Regents of the University of California. All rights > reserved. > >> FreeBSD is a registered trademark of The FreeBSD Foundation. > >> FreeBSD 12.0-CURRENT #1 a3dbcdd(zrouter)-dirty: Tue Sep 19 15:03:43 JST > > 2017 > >> > > hiroki@microserver:/storage/home/hiroki/obj/storage/home/ > hiroki/zrouter/tmp/ > >> arm.arm/storage/home/hiroki/freebsd/sys/Buffalo_WZR2-G300N arm > >> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on > LLVM > > 5.0.0 > >> svn) > >> subsystem 1000000 > >> 0xc01c1674(0)... done. > >> 0xc01d3a0c(0)... done. > >> subsystem 1800000 > >> 0xc00b9cb4(0)... done. > >> 0xc0097fc4(0)... done. > >> 0xc0097c00(0xc0280580)... > >> > >> I checked last address by objdump -D. > >> > >> c0097c00 : > >> c0280580 : > >> > >> What is wrong ? > >> > >> I use git repository on build. If I change git branch then arm > platform is > > build > >> take > >> > >> 6 hour by my server. It is very hard debugging. > >> > >> 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" > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Wed Sep 27 06:45:09 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B134BE2C935 for ; Wed, 27 Sep 2017 06:45:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A01CB6631E for ; Wed, 27 Sep 2017 06:45:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v8R6j9xt085984 for ; Wed, 27 Sep 2017 06:45:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 222634] ffec: Support i.MX7D and performance improvements Date: Wed, 27 Sep 2017 06:45:09 +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: sebastian.huber@embedded-brains.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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 06:45:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222634 Bug ID: 222634 Summary: ffec: Support i.MX7D and performance improvements Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: sebastian.huber@embedded-brains.de I would like to * add support for the i.MX7D, * add checksum offload, * get rid of the m_defrag() in the transmit path, and * avoid the data move of entire frames in the receive path. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Wed Sep 27 09:20:19 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3097E2F2D1 for ; Wed, 27 Sep 2017 09:20:19 +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 522B96A8BD; Wed, 27 Sep 2017 09:20:18 +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 45a9a0f1; Wed, 27 Sep 2017 11:20:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=xDIxD4nGrf//x7CmydVvO/X4D3E=; b=pij+uJ9312LhwoAgjkb6V36v+ffZ TNkC1RBYiYP2vRE+hbGXIFU+dXkC6RHtCWTXVNAJwIxqRuvHJOmLQHQC4rkG/KTl wsaAAPApvy4G6Tl0xYiwmHiYEO0Pb5a4dfMfZXkzu1FWQNpTJtSaF9obuYCzPwnc 8e3hE/IVvE1MS5M= 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=tPodVm+/k6tyZ7WmOkyDWhzVnLMkgmavusOLYpUHrPIvAK1GJtSZ/FVf zTGW2ugRfLia0sbljQdtnbAAPMQJ9HePPDcRB11f1rBKQ86NyWSdBXTEB2fZVZY0 bEqMkDoYiXBdd2geB1hXVt7XLM+q8n+ma7OF7UpkE/QqG5r51wY= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 7dcdb794 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 27 Sep 2017 11:20:16 +0200 (CEST) Date: Wed, 27 Sep 2017 11:20:15 +0200 From: Emmanuel Vadot To: Warner Losh Cc: Ian Lepore , freebsd-arm Subject: Re: CUBOX snapshots working? Message-Id: <20170927112015.e997d7b1b8e9002c8377547a@bidouilliste.com> In-Reply-To: References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:20:20 -0000 On Tue, 26 Sep 2017 17:05:40 -0600 Warner Losh wrote: > On Tue, Sep 26, 2017 at 4:55 PM, Ian Lepore wrote: > > > On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote: > > > On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore wrote: > > > > > > > > > > > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley wrote: > > > > > > > > > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot > > > > te.c > > > > > om> wrote: > > > > > > > > > > > > > > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > > > > > > Ian Lepore wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > > > > > > > Brett Glass wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One would think that sauce for the goose would be sauce > > > > > > > > > for > > > > > > > > > the > > > > > > > > > gander. But is this particular Cubox now useless with > > > > > > > > > FreeBSD? > > > > > > > > > And if so, why? It is not an unusual model. The Cubox > > > > > > > > > does > > > > > > > > > work > > > > > > > > > if I flash their "Ignition" startup software (which is > > > > > > > > > used > > > > > > > > > to > > > > > > > > > bootstrap by downloading various OS images) to the same > > > > > > > > > Micro SD card. > > > > > > > > > > > > > > > > > > --Brett Glass > > > > > > > > The problem isn't FreeBSD related, it's U-Boot related. > > > > > > > > > > > > > > > > You could test build mainline u-boot just to confirm that > > > > > > > > it > > > > > > > > isn't > > > > > > > > something due to our ports. > > > > > > > > > > > > > > > If we used to provide working cubox images and we don't > > > > > > > anymore, > > > > > > > it's > > > > > > > hard to call that anything but a freebsd problem. > > > > > > There is working cubox images, the last one is from yesterday. > > > > > > You even say yourself that you did test it and that it worked. > > > > > > Do we even know if the snapshot worked for this board ? > > > > > > Brett, could you test the 11.0 release for example ? (I don't > > > > > > remember > > > > > > if for 11.1 we already switch u-boot or not). > > > > > I believe the change is in the u-boot port itself. However, I > > > > > don't > > > > > think it's a u-boot problem (IMHO), it's a u-boot build > > > > > configuration > > > > > problem. There are different board variants with different > > > > > hardware > > > > > layout. u-boot has code for it, but our build does not account > > > > > for. > > > > > Unless the scripts that build the 11.1 image use a different > > > > > revision > > > > > of the u-boot port, wouldn't it just use the current 2017.7 base? > > > > > > > > > > I'm trying to figure out how to generate a u-boot with the > > > > > correct > > > > > SPL > > > > > portion of u-boot. One could pull the SolidRun u-boot repo, or go > > > > > find > > > > > the ports commit before the changeover and see if we can generate > > > > > the > > > > > correct SPL. > > > > > > > > > > I looked at Mainline u-boot and there is a board directory for > > > > > solid > > > > > run. > > > > > https://github.com/u-boot/u-boot/blob/master/board/solidrun/mx6cu > > > > > boxi > > > > > /mx6cuboxi.c > > > > > seems to support multiple memory configurations based on defines, > > > > > so > > > > > this should just be a configuration problem. > > > > > > > > > > We clearly need to start supporting the lower spec'd SolidRun > > > > > boards > > > > > because this has come up a couple of times now since the > > > > > changeover. > > > > > It should be just a matter of creating a port that does the same > > > > > thing > > > > > but generates the correct SPL file? My SOM is a i2eX so I can't > > > > > be > > > > > too > > > > > much help (and I've also over volunteered myself!). > > > > > > > > > > Russ > > > > > > > > > The old imx6 uboot ports generated a single copy of uboot that > > > > would > > > > boot dual and quad-core versions of both hummingboard and cubox > > > > systems. If the new uboot works only on quad core, that's another > > > > regression. It might be possible to extract the u-boot.imx file > > > > from a > > > > freebsd 10 image to get back to the old one. > > > > > > > > Ooops. Except it appears those no longer exist. > > > > > > Is this a loss of functionality when the changes were upstreamed? Is > > > it a > > > bad configuration on our part? Any idea what might be going on or how > > > to > > > fix it? > > > > The vendor uboot worked well. The generic mainline, apparently not so > > much. It may indicate that the vendor didn't upstream everything. I > > haven't worked much with the new imx6 uboot packages because for me > > they're completely unusable because they lack support for netbooting. > > (If you feel tempted to say something about efi and netbooting, please > > provide links to how-to documentation at the very least, and an example > > that works for armv6 would be even better.) > > > > I didn't think that we were enabling EFI + armv6 on anything yet by > default... > > Can't help you there. > > Warner We do, EFI is enabled by default in U-Boot on most of the boards. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Sep 27 09:21:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59EF3E2F33C for ; Wed, 27 Sep 2017 09:21:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 1B4A96A99E for ; Wed, 27 Sep 2017 09:21:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id e189so15202514ioa.4 for ; Wed, 27 Sep 2017 02:21:11 -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=QwEF6Zcu5KgRdw6xeZKyLs7nRWYMJucDKhJ18qCNchw=; b=tK+3XVYRWk7EdmYdgaLotU5R6bL3OCDyZ6iFzuTJNSYMwm3eA5toNpryO4S5MFTBxK kPC2pNpmZ714XUQb8FYzPwM0rupLgdAPx/nchPY+Ewpt0N02jRVIrklRneysTi5cAhWa uqMi1qg6HLxqfxanGTS1RvqWNy9aCDNAIt6iXbdsj76NWYp4hicDWamKvormNW9itEFv G/taPIL+J9JTQ887xf5ertuKNZpBE6N/i/NmAiQtup4KK+8OZTDkC1dOM80Bmppzi6dk nOWOQZ7WNzMr6Z7dz1bq0HFEqtDgYk+jbEcOYaRObaStpdHOJ3R2JsUWfZTBvLE0joaU jceQ== 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=QwEF6Zcu5KgRdw6xeZKyLs7nRWYMJucDKhJ18qCNchw=; b=Q6mUe4VojtA15CDbuqE9wktQAx5/WB+4BHHy6P+bhhuv1Nk/Zx3PX1rsvfj3a+WtKK 1VJwEBqTRr0uNE5GCvSAB2vmo/bDq69fd5+cyPM60UB0Vcp3p6xRhP+vqvVSvZ5RyYCC 8jRAHtMeKgOZwJL3lAbfC8csZUBDFDpVv4EpZn7ZCoZ7H+1Y/79CZFVXsXbWEQqJgS+r YWOfPE36JgWXJnVunhbmVMOlMbkXvRpN7HoPCFYLH+25To6mbyiw2BecK8GQ8OHaICim UOKN7NUUGgde+oNJdAsq8KkxBQnlIkrQOJ7J0Odi7QAAc+yXcqBaVTZ/jFNwrxjRgoB7 Yanw== X-Gm-Message-State: AMCzsaWN8//7Vq0VoOJIclEsTvyT0NFXuafMC6z+zZY+IraktspcrQJl r4Cffw08wBTnOhnDE7ZFmzA2LKDU5pppNL7NfItjaA== X-Google-Smtp-Source: AOwi7QDVSOtA2393pTQ+F82Wb1FT8O3k8LCjUsW/cSuCtAylg0k42ysz/tB91AKgqxAvslFL03+wU6BsGk7ncwRoqbw= X-Received: by 10.107.135.147 with SMTP id r19mr1052930ioi.26.1506504070328; Wed, 27 Sep 2017 02:21:10 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Wed, 27 Sep 2017 02:21:09 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:f996:822c:89a6:8ee4] In-Reply-To: <20170927112015.e997d7b1b8e9002c8377547a@bidouilliste.com> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> <20170927112015.e997d7b1b8e9002c8377547a@bidouilliste.com> From: Warner Losh Date: Wed, 27 Sep 2017 03:21:09 -0600 X-Google-Sender-Auth: LZvoJ27-VZGj62Lx-qVevDbD_I8 Message-ID: Subject: Re: CUBOX snapshots working? To: Emmanuel Vadot Cc: Ian Lepore , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:21:11 -0000 On Wed, Sep 27, 2017 at 3:20 AM, Emmanuel Vadot wrote: > On Tue, 26 Sep 2017 17:05:40 -0600 > Warner Losh wrote: > > > On Tue, Sep 26, 2017 at 4:55 PM, Ian Lepore wrote: > > > > > On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote: > > > > On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore wrote: > > > > > > > > > > > > > > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley wrote: > > > > > > > > > > > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot > > > > > te.c > > > > > > om> wrote: > > > > > > > > > > > > > > > > > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > > > > > > > Ian Lepore wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > > > > > > > > Brett Glass wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One would think that sauce for the goose would be sauce > > > > > > > > > > for > > > > > > > > > > the > > > > > > > > > > gander. But is this particular Cubox now useless with > > > > > > > > > > FreeBSD? > > > > > > > > > > And if so, why? It is not an unusual model. The Cubox > > > > > > > > > > does > > > > > > > > > > work > > > > > > > > > > if I flash their "Ignition" startup software (which is > > > > > > > > > > used > > > > > > > > > > to > > > > > > > > > > bootstrap by downloading various OS images) to the same > > > > > > > > > > Micro SD card. > > > > > > > > > > > > > > > > > > > > --Brett Glass > > > > > > > > > The problem isn't FreeBSD related, it's U-Boot related. > > > > > > > > > > > > > > > > > > You could test build mainline u-boot just to confirm that > > > > > > > > > it > > > > > > > > > isn't > > > > > > > > > something due to our ports. > > > > > > > > > > > > > > > > > If we used to provide working cubox images and we don't > > > > > > > > anymore, > > > > > > > > it's > > > > > > > > hard to call that anything but a freebsd problem. > > > > > > > There is working cubox images, the last one is from yesterday. > > > > > > > You even say yourself that you did test it and that it worked. > > > > > > > Do we even know if the snapshot worked for this board ? > > > > > > > Brett, could you test the 11.0 release for example ? (I don't > > > > > > > remember > > > > > > > if for 11.1 we already switch u-boot or not). > > > > > > I believe the change is in the u-boot port itself. However, I > > > > > > don't > > > > > > think it's a u-boot problem (IMHO), it's a u-boot build > > > > > > configuration > > > > > > problem. There are different board variants with different > > > > > > hardware > > > > > > layout. u-boot has code for it, but our build does not account > > > > > > for. > > > > > > Unless the scripts that build the 11.1 image use a different > > > > > > revision > > > > > > of the u-boot port, wouldn't it just use the current 2017.7 base? > > > > > > > > > > > > I'm trying to figure out how to generate a u-boot with the > > > > > > correct > > > > > > SPL > > > > > > portion of u-boot. One could pull the SolidRun u-boot repo, or go > > > > > > find > > > > > > the ports commit before the changeover and see if we can generate > > > > > > the > > > > > > correct SPL. > > > > > > > > > > > > I looked at Mainline u-boot and there is a board directory for > > > > > > solid > > > > > > run. > > > > > > https://github.com/u-boot/u-boot/blob/master/board/ > solidrun/mx6cu > > > > > > boxi > > > > > > /mx6cuboxi.c > > > > > > seems to support multiple memory configurations based on defines, > > > > > > so > > > > > > this should just be a configuration problem. > > > > > > > > > > > > We clearly need to start supporting the lower spec'd SolidRun > > > > > > boards > > > > > > because this has come up a couple of times now since the > > > > > > changeover. > > > > > > It should be just a matter of creating a port that does the same > > > > > > thing > > > > > > but generates the correct SPL file? My SOM is a i2eX so I can't > > > > > > be > > > > > > too > > > > > > much help (and I've also over volunteered myself!). > > > > > > > > > > > > Russ > > > > > > > > > > > The old imx6 uboot ports generated a single copy of uboot that > > > > > would > > > > > boot dual and quad-core versions of both hummingboard and cubox > > > > > systems. If the new uboot works only on quad core, that's another > > > > > regression. It might be possible to extract the u-boot.imx file > > > > > from a > > > > > freebsd 10 image to get back to the old one. > > > > > > > > > > Ooops. Except it appears those no longer exist. > > > > > > > > Is this a loss of functionality when the changes were upstreamed? Is > > > > it a > > > > bad configuration on our part? Any idea what might be going on or how > > > > to > > > > fix it? > > > > > > The vendor uboot worked well. The generic mainline, apparently not so > > > much. It may indicate that the vendor didn't upstream everything. I > > > haven't worked much with the new imx6 uboot packages because for me > > > they're completely unusable because they lack support for netbooting. > > > (If you feel tempted to say something about efi and netbooting, please > > > provide links to how-to documentation at the very least, and an example > > > that works for armv6 would be even better.) > > > > > > > I didn't think that we were enabling EFI + armv6 on anything yet by > > default... > > > > Can't help you there. > > > > Warner > > We do, EFI is enabled by default in U-Boot on most of the boards. And GENERIC actually supports that? Warner From owner-freebsd-arm@freebsd.org Wed Sep 27 09:22:44 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DE3BE2F4C5 for ; Wed, 27 Sep 2017 09:22:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CBD06ABEF for ; Wed, 27 Sep 2017 09:22:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id 85so5821347ith.2 for ; Wed, 27 Sep 2017 02:22:44 -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=UzMQ1PdFjsVXNnqfNsFHJPDIg5yTau+7m27mCBqoN1E=; b=hc6RZAGjJVFGQv5a6GBIvmEHQGB+NXatPiBn+cqve417ejB8d4hIOh3hhkDGvoFwLn 775PgxXVCQ3MOU4A09ISTp1z5DQ5s8h8Po56QnFLEoKx5TZFle74mIC6CzXzGFaTAiQH CHtUnpEQy/GazlKy/zL9CdUakQqDvEPg5KJctjjPhbQZxRFi7S9eSYoX7ldL2DVZzy8x 6Tnn8XDVojiUPku42lFK+x+z+AhGnBkx84zkm4IiOcQt1+lRpBUNg7GOWCH/bM2oRmk3 cSAF3x64/nvyVsP5JE8u2Nlx+IFreOWiD6BsYueaVVt5TPdeLDeyLhBCmGSp/1wn9mUz As+g== 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=UzMQ1PdFjsVXNnqfNsFHJPDIg5yTau+7m27mCBqoN1E=; b=iiQUdwZTzgG+xErDp68Q933kApeNq8sju8q9O+KaXGOm87m+A3Ja0O0A4Tywy2jz+R s2VjHFjgoZTnP85VUmb9g+OLyR5Hv8I9zHXwPP2Xyxjn72F+nQswvp5xIz42iS5TzWYT ZkfKiMfX5BCJkJbmAHxQlLrLWgvpDi7/BB9bF2JSR0gZo4GQnJh6conJ7AbRgtzbXw7S MnI4Wr81/9TDZdg6KHpuk6s6G/+TSh4d/4T0IN54nmv60dHqtpfzZyJ8yexlJd5qicSu fgEUxHVHo+vo2TNErultXGQLp29LDpgoCI0EsyTpSu3+LUTdLpTXju7eg+uAiQEBtfZt q+9w== X-Gm-Message-State: AHPjjUiaupEJMwItATb0a/nXAzaBITyzvPk8hP+zPh2Z6a3QZhNSOzQM vnMIN6EhlWq9o4L9jnJjvzy0ZxM+w6BVvnEwbBjiNg== X-Google-Smtp-Source: AOwi7QB3fJNyFMpOXKv9IDd8+0ZkjSHvemXAgzO97EDgee0M+xsrIzpAZHTqrBXCDyXq2QDSZEBKO2kgVnQjhvy5yOo= X-Received: by 10.36.20.149 with SMTP id 143mr1351398itg.63.1506504163526; Wed, 27 Sep 2017 02:22:43 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Wed, 27 Sep 2017 02:22:42 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:f996:822c:89a6:8ee4] In-Reply-To: References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> <20170927112015.e997d7b1b8e9002c8377547a@bidouilliste.com> From: Warner Losh Date: Wed, 27 Sep 2017 03:22:42 -0600 X-Google-Sender-Auth: CCO-VDxE38C_D8JyF89oUXEd0tY Message-ID: Subject: Re: CUBOX snapshots working? To: Emmanuel Vadot Cc: Ian Lepore , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:22:44 -0000 On Wed, Sep 27, 2017 at 3:21 AM, Warner Losh wrote: > > > On Wed, Sep 27, 2017 at 3:20 AM, Emmanuel Vadot > wrote: > >> On Tue, 26 Sep 2017 17:05:40 -0600 >> Warner Losh wrote: >> >> > On Tue, Sep 26, 2017 at 4:55 PM, Ian Lepore wrote: >> > >> > > On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote: >> > > > On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore >> wrote: >> > > > >> > > > > >> > > > > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley wrote: >> > > > > > >> > > > > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot >> > > > > > > te.c >> > > > > > om> wrote: >> > > > > > > >> > > > > > > >> > > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 >> > > > > > > Ian Lepore wrote: >> > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 >> > > > > > > > > Brett Glass wrote: >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > One would think that sauce for the goose would be sauce >> > > > > > > > > > for >> > > > > > > > > > the >> > > > > > > > > > gander. But is this particular Cubox now useless with >> > > > > > > > > > FreeBSD? >> > > > > > > > > > And if so, why? It is not an unusual model. The Cubox >> > > > > > > > > > does >> > > > > > > > > > work >> > > > > > > > > > if I flash their "Ignition" startup software (which is >> > > > > > > > > > used >> > > > > > > > > > to >> > > > > > > > > > bootstrap by downloading various OS images) to the same >> > > > > > > > > > Micro SD card. >> > > > > > > > > > >> > > > > > > > > > --Brett Glass >> > > > > > > > > The problem isn't FreeBSD related, it's U-Boot related. >> > > > > > > > > >> > > > > > > > > You could test build mainline u-boot just to confirm that >> > > > > > > > > it >> > > > > > > > > isn't >> > > > > > > > > something due to our ports. >> > > > > > > > > >> > > > > > > > If we used to provide working cubox images and we don't >> > > > > > > > anymore, >> > > > > > > > it's >> > > > > > > > hard to call that anything but a freebsd problem. >> > > > > > > There is working cubox images, the last one is from >> yesterday. >> > > > > > > You even say yourself that you did test it and that it >> worked. >> > > > > > > Do we even know if the snapshot worked for this board ? >> > > > > > > Brett, could you test the 11.0 release for example ? (I don't >> > > > > > > remember >> > > > > > > if for 11.1 we already switch u-boot or not). >> > > > > > I believe the change is in the u-boot port itself. However, I >> > > > > > don't >> > > > > > think it's a u-boot problem (IMHO), it's a u-boot build >> > > > > > configuration >> > > > > > problem. There are different board variants with different >> > > > > > hardware >> > > > > > layout. u-boot has code for it, but our build does not account >> > > > > > for. >> > > > > > Unless the scripts that build the 11.1 image use a different >> > > > > > revision >> > > > > > of the u-boot port, wouldn't it just use the current 2017.7 >> base? >> > > > > > >> > > > > > I'm trying to figure out how to generate a u-boot with the >> > > > > > correct >> > > > > > SPL >> > > > > > portion of u-boot. One could pull the SolidRun u-boot repo, or >> go >> > > > > > find >> > > > > > the ports commit before the changeover and see if we can >> generate >> > > > > > the >> > > > > > correct SPL. >> > > > > > >> > > > > > I looked at Mainline u-boot and there is a board directory for >> > > > > > solid >> > > > > > run. >> > > > > > https://github.com/u-boot/u-boot/blob/master/board/solidrun/ >> mx6cu >> > > > > > boxi >> > > > > > /mx6cuboxi.c >> > > > > > seems to support multiple memory configurations based on >> defines, >> > > > > > so >> > > > > > this should just be a configuration problem. >> > > > > > >> > > > > > We clearly need to start supporting the lower spec'd SolidRun >> > > > > > boards >> > > > > > because this has come up a couple of times now since the >> > > > > > changeover. >> > > > > > It should be just a matter of creating a port that does the same >> > > > > > thing >> > > > > > but generates the correct SPL file? My SOM is a i2eX so I can't >> > > > > > be >> > > > > > too >> > > > > > much help (and I've also over volunteered myself!). >> > > > > > >> > > > > > Russ >> > > > > > >> > > > > The old imx6 uboot ports generated a single copy of uboot that >> > > > > would >> > > > > boot dual and quad-core versions of both hummingboard and cubox >> > > > > systems. If the new uboot works only on quad core, that's another >> > > > > regression. It might be possible to extract the u-boot.imx file >> > > > > from a >> > > > > freebsd 10 image to get back to the old one. >> > > > > >> > > > > Ooops. Except it appears those no longer exist. >> > > > >> > > > Is this a loss of functionality when the changes were upstreamed? Is >> > > > it a >> > > > bad configuration on our part? Any idea what might be going on or >> how >> > > > to >> > > > fix it? >> > > >> > > The vendor uboot worked well. The generic mainline, apparently not so >> > > much. It may indicate that the vendor didn't upstream everything. I >> > > haven't worked much with the new imx6 uboot packages because for me >> > > they're completely unusable because they lack support for netbooting. >> > > (If you feel tempted to say something about efi and netbooting, >> please >> > > provide links to how-to documentation at the very least, and an >> example >> > > that works for armv6 would be even better.) >> > > >> > >> > I didn't think that we were enabling EFI + armv6 on anything yet by >> > default... >> > >> > Can't help you there. >> > >> > Warner >> >> We do, EFI is enabled by default in U-Boot on most of the boards. > > > And GENERIC actually supports that? > And more importantly, we have the right tooling to build the right images for EFI booting? Warner From owner-freebsd-arm@freebsd.org Wed Sep 27 09:24:26 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4B29E2F5BC for ; Wed, 27 Sep 2017 09:24:26 +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 316CC6ADBA; Wed, 27 Sep 2017 09:24:25 +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 aadb5642; Wed, 27 Sep 2017 11:24:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=eGC6jQVHtvDQptlG6wcBuNkJq6Q=; b=TXxU9OKN7dIYXZYfadmmfVp8Na3i f+rPdyo7afDLKEKfmK3h6tuADzNPb6BccsIaFdafEoZNKdIT41A64d4aAGkr8hCB YXEboSI8zAZerhDIBgOadhTdMmg8q9A/ZOYjSpHcbT301YzIz9CwdhCO5FWmKSEt 8OnhaUSBA5i2xhM= 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=jgcD4A3QoZFL9Vu+0EndpwSop8LoE9x3V6UVdeTqRlrcVYHCPwK/n46R HQG81IT7U6zsf6fSDJ9j9NLEEdigE7x6WEnfVHY794D7W18e1mO9uWDj8V4QXtLh 5BirOg+iPcRNb61xdKNrauNaUMrv3iV6Ox2a3iCCUFZe7Mj5vA0= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id e666665f TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 27 Sep 2017 11:24:23 +0200 (CEST) Date: Wed, 27 Sep 2017 11:24:13 +0200 From: Emmanuel Vadot To: Ian Lepore Cc: Warner Losh , freebsd-arm Subject: Re: CUBOX snapshots working? Message-Id: <20170927112413.4fc048082df75f51a4b71eea@bidouilliste.com> In-Reply-To: <1506466528.73082.172.camel@freebsd.org> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> X-Mailer: Sylpheed 3.5.1 (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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:24:26 -0000 On Tue, 26 Sep 2017 16:55:28 -0600 Ian Lepore wrote: > On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote: > > On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore wrote: > >=20 > > >=20 > > > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley wrote: > > > >=20 > > > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot > > > te.c > > > > om> wrote: > > > > >=20 > > > > >=20 > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > > > > > Ian Lepore wrote: > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > > > > > > >=20 > > > > > > >=20 > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > > > > > > Brett Glass wrote: > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > One would think that sauce for the goose would be sauce > > > > > > > > for > > > > > > > > the > > > > > > > > gander. But is this particular Cubox now useless with > > > > > > > > FreeBSD? > > > > > > > > And if so, why? It is not an unusual model. The Cubox > > > > > > > > does > > > > > > > > work > > > > > > > > if I flash their "Ignition" startup software (which is > > > > > > > > used > > > > > > > > to > > > > > > > > bootstrap by downloading various OS images) to the same > > > > > > > > Micro SD card. > > > > > > > >=20 > > > > > > > > --Brett Glass > > > > > > > =A0The problem isn't FreeBSD related, it's U-Boot related. > > > > > > >=20 > > > > > > > =A0You could test build mainline u-boot just to confirm that > > > > > > > it > > > > > > > isn't > > > > > > > something due to our ports. > > > > > > >=20 > > > > > > If we used to provide working cubox images and we don't > > > > > > anymore, > > > > > > it's > > > > > > hard to call that anything but a freebsd problem. > > > > > =A0There is working cubox images, the last one is from yesterday. > > > > > =A0You even say yourself that you did test it and that it worked. > > > > > =A0Do we even know if the snapshot worked for this board ? > > > > > =A0Brett, could you test the 11.0 release for example ? (I don't > > > > > remember > > > > > if for 11.1 we already switch u-boot or not). > > > > I believe the change is in the u-boot port itself. However, I > > > > don't > > > > think it's a u-boot problem (IMHO), it's a u-boot build > > > > configuration > > > > problem. There are different board variants with different > > > > hardware > > > > layout. u-boot has code for it, but our build does not account > > > > for. > > > > Unless the scripts that build the 11.1 image use a different > > > > revision > > > > of the u-boot port, wouldn't it just use the current 2017.7 base? > > > >=20 > > > > I'm trying to figure out how to generate a u-boot with the > > > > correct > > > > SPL > > > > portion of u-boot. One could pull the SolidRun u-boot repo, or go > > > > find > > > > the ports commit before the changeover and see if we can generate > > > > the > > > > correct SPL. > > > >=20 > > > > I looked at Mainline u-boot and there is a board directory for > > > > solid > > > > run. > > > > https://github.com/u-boot/u-boot/blob/master/board/solidrun/mx6cu > > > > boxi > > > > /mx6cuboxi.c > > > > seems to support multiple memory configurations based on defines, > > > > so > > > > this should just be a configuration problem. > > > >=20 > > > > We clearly need to start supporting the lower spec'd SolidRun > > > > boards > > > > because this has come up a couple of times now since the > > > > changeover. > > > > It should be just a matter of creating a port that does the same > > > > thing > > > > but generates the correct SPL file? My SOM is a i2eX so I can't > > > > be > > > > too > > > > much help (and I've also over volunteered myself!). > > > >=20 > > > > Russ > > > >=20 > > > The old imx6 uboot ports generated a single copy of uboot that > > > would > > > boot dual and quad-core versions of both hummingboard and cubox > > > systems.=A0=A0If the new uboot works only on quad core, that's another > > > regression.=A0=A0It might be possible to extract the u-boot.imx file > > > from a > > > freebsd 10 image to get back to the old one. > > >=20 > > > Ooops.=A0=A0Except it appears those no longer exist. > >=20 > > Is this a loss of functionality when the changes were upstreamed? Is > > it a > > bad configuration on our part? Any idea what might be going on or how > > to > > fix it? >=20 > The vendor uboot worked well. =A0The generic mainline, apparently not so > much. =A0It may indicate that the vendor didn't upstream everything. =A0I > haven't worked much with the new imx6 uboot packages because for me > they're completely unusable because they lack support for netbooting. > =A0(If you feel tempted to say something about efi and netbooting, please > provide links to how-to documentation at the very least, and an example > that works for armv6 would be even better.) >=20 > -- Ian Just set 'filename' to loader.efi in dhcpd.conf (if you use isc-dhcpd) and have it served by tftpd. In U-boot : $ env set boot_targets=3Ddhcp (default is different for each board but will look like "mmc0 dhcp usb") $ env save (if you want it by default) $ boot This will make u-boot do dhcp request, tftp load the DTB (so have it in your tftpd directory), loader.efi and run it. --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Sep 27 09:25:52 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD14FE2F656 for ; Wed, 27 Sep 2017 09:25:52 +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 38ABF6AE50; Wed, 27 Sep 2017 09:25:51 +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 82142f26; Wed, 27 Sep 2017 11:25:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=4zrhyDw0p9QeUAAaroyBOGDZ380=; b=BnkVVJ5tgw7PRc0+phX3YP07x4ST UvJc/AAPQ4/Mxk6KU3ARKxbfITa/3Y/FoucCQc5ipodcSiy61DBplfhKZCrGg5L9 YakdjafJ2Hsw0n4HDAp+0hR1QIw7Kpd2VtCUZkKvUQMQEBwpEaAkYk886ubY5oZo D3yedSZnr+LufhE= 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=CXZ3LZLEa9b1xZOVthtgMpJm7GiBGlO119oLNDTNzIzHz+ZL6l3cc216 hJ7toBOd7R7NX6AttNl/rcnS8qd7mXxQxwxRaeZUhfkOFMpjE40TJv66w1l3QOZN xLb8b3vfWq5NAHsNL5shMFtKdBcIumgU+VX5HrXS2hgZgd7n+zg= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 98438a18 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 27 Sep 2017 11:25:49 +0200 (CEST) Date: Wed, 27 Sep 2017 11:25:48 +0200 From: Emmanuel Vadot To: Warner Losh Cc: Ian Lepore , freebsd-arm Subject: Re: CUBOX snapshots working? Message-Id: <20170927112548.1b405a726da9938c26ad5cbb@bidouilliste.com> In-Reply-To: References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> <20170927112015.e997d7b1b8e9002c8377547a@bidouilliste.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:25:52 -0000 On Wed, 27 Sep 2017 03:22:42 -0600 Warner Losh wrote: > On Wed, Sep 27, 2017 at 3:21 AM, Warner Losh wrote: > > > > > > > On Wed, Sep 27, 2017 at 3:20 AM, Emmanuel Vadot > > wrote: > > > >> On Tue, 26 Sep 2017 17:05:40 -0600 > >> Warner Losh wrote: > >> > >> > On Tue, Sep 26, 2017 at 4:55 PM, Ian Lepore wrote: > >> > > >> > > On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote: > >> > > > On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore > >> wrote: > >> > > > > >> > > > > > >> > > > > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley wrote: > >> > > > > > > >> > > > > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot > >> >> > > > > > te.c > >> > > > > > om> wrote: > >> > > > > > > > >> > > > > > > > >> > > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > >> > > > > > > Ian Lepore wrote: > >> > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > >> > > > > > > > > Brett Glass wrote: > >> > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > One would think that sauce for the goose would be sauce > >> > > > > > > > > > for > >> > > > > > > > > > the > >> > > > > > > > > > gander. But is this particular Cubox now useless with > >> > > > > > > > > > FreeBSD? > >> > > > > > > > > > And if so, why? It is not an unusual model. The Cubox > >> > > > > > > > > > does > >> > > > > > > > > > work > >> > > > > > > > > > if I flash their "Ignition" startup software (which is > >> > > > > > > > > > used > >> > > > > > > > > > to > >> > > > > > > > > > bootstrap by downloading various OS images) to the same > >> > > > > > > > > > Micro SD card. > >> > > > > > > > > > > >> > > > > > > > > > --Brett Glass > >> > > > > > > > > The problem isn't FreeBSD related, it's U-Boot related. > >> > > > > > > > > > >> > > > > > > > > You could test build mainline u-boot just to confirm that > >> > > > > > > > > it > >> > > > > > > > > isn't > >> > > > > > > > > something due to our ports. > >> > > > > > > > > > >> > > > > > > > If we used to provide working cubox images and we don't > >> > > > > > > > anymore, > >> > > > > > > > it's > >> > > > > > > > hard to call that anything but a freebsd problem. > >> > > > > > > There is working cubox images, the last one is from > >> yesterday. > >> > > > > > > You even say yourself that you did test it and that it > >> worked. > >> > > > > > > Do we even know if the snapshot worked for this board ? > >> > > > > > > Brett, could you test the 11.0 release for example ? (I don't > >> > > > > > > remember > >> > > > > > > if for 11.1 we already switch u-boot or not). > >> > > > > > I believe the change is in the u-boot port itself. However, I > >> > > > > > don't > >> > > > > > think it's a u-boot problem (IMHO), it's a u-boot build > >> > > > > > configuration > >> > > > > > problem. There are different board variants with different > >> > > > > > hardware > >> > > > > > layout. u-boot has code for it, but our build does not account > >> > > > > > for. > >> > > > > > Unless the scripts that build the 11.1 image use a different > >> > > > > > revision > >> > > > > > of the u-boot port, wouldn't it just use the current 2017.7 > >> base? > >> > > > > > > >> > > > > > I'm trying to figure out how to generate a u-boot with the > >> > > > > > correct > >> > > > > > SPL > >> > > > > > portion of u-boot. One could pull the SolidRun u-boot repo, or > >> go > >> > > > > > find > >> > > > > > the ports commit before the changeover and see if we can > >> generate > >> > > > > > the > >> > > > > > correct SPL. > >> > > > > > > >> > > > > > I looked at Mainline u-boot and there is a board directory for > >> > > > > > solid > >> > > > > > run. > >> > > > > > https://github.com/u-boot/u-boot/blob/master/board/solidrun/ > >> mx6cu > >> > > > > > boxi > >> > > > > > /mx6cuboxi.c > >> > > > > > seems to support multiple memory configurations based on > >> defines, > >> > > > > > so > >> > > > > > this should just be a configuration problem. > >> > > > > > > >> > > > > > We clearly need to start supporting the lower spec'd SolidRun > >> > > > > > boards > >> > > > > > because this has come up a couple of times now since the > >> > > > > > changeover. > >> > > > > > It should be just a matter of creating a port that does the same > >> > > > > > thing > >> > > > > > but generates the correct SPL file? My SOM is a i2eX so I can't > >> > > > > > be > >> > > > > > too > >> > > > > > much help (and I've also over volunteered myself!). > >> > > > > > > >> > > > > > Russ > >> > > > > > > >> > > > > The old imx6 uboot ports generated a single copy of uboot that > >> > > > > would > >> > > > > boot dual and quad-core versions of both hummingboard and cubox > >> > > > > systems. If the new uboot works only on quad core, that's another > >> > > > > regression. It might be possible to extract the u-boot.imx file > >> > > > > from a > >> > > > > freebsd 10 image to get back to the old one. > >> > > > > > >> > > > > Ooops. Except it appears those no longer exist. > >> > > > > >> > > > Is this a loss of functionality when the changes were upstreamed? Is > >> > > > it a > >> > > > bad configuration on our part? Any idea what might be going on or > >> how > >> > > > to > >> > > > fix it? > >> > > > >> > > The vendor uboot worked well. The generic mainline, apparently not so > >> > > much. It may indicate that the vendor didn't upstream everything. I > >> > > haven't worked much with the new imx6 uboot packages because for me > >> > > they're completely unusable because they lack support for netbooting. > >> > > (If you feel tempted to say something about efi and netbooting, > >> please > >> > > provide links to how-to documentation at the very least, and an > >> example > >> > > that works for armv6 would be even better.) > >> > > > >> > > >> > I didn't think that we were enabling EFI + armv6 on anything yet by > >> > default... > >> > > >> > Can't help you there. > >> > > >> > Warner > >> > >> We do, EFI is enabled by default in U-Boot on most of the boards. > > > > > > And GENERIC actually supports that? > > > > And more importantly, we have the right tooling to build the right images > for EFI booting? > > Warner GENERIC supports that and boot1.efi/loader.efi built for arm is correctly built. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Sep 27 09:28:41 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73BCBE2F6FD for ; Wed, 27 Sep 2017 09:28:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 332266AF14 for ; Wed, 27 Sep 2017 09:28:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id d16so15114257ioj.3 for ; Wed, 27 Sep 2017 02:28:41 -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=lRvbd0ybZdVssMy3B2/TDNGDfiEglV1Un0BD+i3lFSY=; b=r/PDIXYcuoesYnrNhLRGbUhiRd1D9fFETco70dZ0zLYcxpS0mkuidtdeaP7D0/UNy6 Y0lTVdhvTFZ6vfVa5pbJc+a8MyRfIlH+HhY8psTNA04OTh2N0NmNjZmF9YvciJBsxtss kVO2TG3xGXzTwt+wKD2CaRMzh0qSxEvJPQKvA4yL9LtUhLtdQbOQ7AdZhbqCeUiDzubA ZY3rQb0TvSVNSdc8yx9ccwdHm4QiDKdkDCjtr2GUDfLychR2M70R2ehTsIlF0176/4qq QrnxtvkKKYPYKmjjg71/JMi2/5ZNy8Q67MVnf9zOmqw0TDvT3H3Rpiib4lzBaqFQFfuw Eyrg== 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=lRvbd0ybZdVssMy3B2/TDNGDfiEglV1Un0BD+i3lFSY=; b=TWtrW8Nncr6lbYzHflPgwc79O+/Kna6OoXH8g/Ne3ayjb1VKcYndVbcwCJrwW02MCx IH+FGRjIhQgYPNn/fszmkrUR478jugiKPyG9IA0ZKWBOG+9fUWQ+0XPzXj3s7zMmRCLy P/rYvXSrGAlmn97Fza5QEgEbjsvTc3oYKTs3/R3qxXmPSaf3PKFAvMXiLrRNIXGKRX4E KUKnbjgEhDAZcrPeH8sXqpyGCfT6Wq6cY4953sLYmvj0jVJokyFec96VkFg8eoJCou/T blk68r+3rKI9hUtF8XZUqnqyrSGhkppeuLxa4DR9xA+fLJeeVBwnz850E3/GDaFXrOWQ KHug== X-Gm-Message-State: AMCzsaVSdcbUOoDazEm3iHsIYkDLCpQ45RZm46M9ebWH8Mc8pm+aYXTU DwvXEdQVoQF+bxpLnj9UldpsYiRL6fe1hKVLjg8AcA== X-Google-Smtp-Source: AOwi7QCmGpEPj9NmzFOJ/EX77HFXv2uvRrygbENv6775fgZwfc0s7gQloYZm5MuLQPDHS+qjzwge0rs5MHgL5gsbBH4= X-Received: by 10.107.185.7 with SMTP id j7mr1034113iof.221.1506504520596; Wed, 27 Sep 2017 02:28:40 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Wed, 27 Sep 2017 02:28:39 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:f996:822c:89a6:8ee4] In-Reply-To: <20170927112548.1b405a726da9938c26ad5cbb@bidouilliste.com> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> <20170927112015.e997d7b1b8e9002c8377547a@bidouilliste.com> <20170927112548.1b405a726da9938c26ad5cbb@bidouilliste.com> From: Warner Losh Date: Wed, 27 Sep 2017 03:28:39 -0600 X-Google-Sender-Auth: dBMEY01sN3pnjWuYXf_YqPVf4vo Message-ID: Subject: Re: CUBOX snapshots working? To: Emmanuel Vadot Cc: Ian Lepore , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:28:41 -0000 On Wed, Sep 27, 2017 at 3:25 AM, Emmanuel Vadot wrote: > On Wed, 27 Sep 2017 03:22:42 -0600 > Warner Losh wrote: > > > On Wed, Sep 27, 2017 at 3:21 AM, Warner Losh wrote: > > > > > > > > > > > On Wed, Sep 27, 2017 at 3:20 AM, Emmanuel Vadot > > > > wrote: > > > > > >> On Tue, 26 Sep 2017 17:05:40 -0600 > > >> Warner Losh wrote: > > >> > > >> > On Tue, Sep 26, 2017 at 4:55 PM, Ian Lepore > wrote: > > >> > > > >> > > On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote: > > >> > > > On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore > > >> wrote: > > >> > > > > > >> > > > > > > >> > > > > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley wrote: > > >> > > > > > > > >> > > > > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot > > >> > >> > > > > > te.c > > >> > > > > > om> wrote: > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > > >> > > > > > > Ian Lepore wrote: > > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > >> > > > > > > > > Brett Glass wrote: > > >> > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > One would think that sauce for the goose would be > sauce > > >> > > > > > > > > > for > > >> > > > > > > > > > the > > >> > > > > > > > > > gander. But is this particular Cubox now useless > with > > >> > > > > > > > > > FreeBSD? > > >> > > > > > > > > > And if so, why? It is not an unusual model. The > Cubox > > >> > > > > > > > > > does > > >> > > > > > > > > > work > > >> > > > > > > > > > if I flash their "Ignition" startup software (which > is > > >> > > > > > > > > > used > > >> > > > > > > > > > to > > >> > > > > > > > > > bootstrap by downloading various OS images) to the > same > > >> > > > > > > > > > Micro SD card. > > >> > > > > > > > > > > > >> > > > > > > > > > --Brett Glass > > >> > > > > > > > > The problem isn't FreeBSD related, it's U-Boot > related. > > >> > > > > > > > > > > >> > > > > > > > > You could test build mainline u-boot just to confirm > that > > >> > > > > > > > > it > > >> > > > > > > > > isn't > > >> > > > > > > > > something due to our ports. > > >> > > > > > > > > > > >> > > > > > > > If we used to provide working cubox images and we don't > > >> > > > > > > > anymore, > > >> > > > > > > > it's > > >> > > > > > > > hard to call that anything but a freebsd problem. > > >> > > > > > > There is working cubox images, the last one is from > > >> yesterday. > > >> > > > > > > You even say yourself that you did test it and that it > > >> worked. > > >> > > > > > > Do we even know if the snapshot worked for this board ? > > >> > > > > > > Brett, could you test the 11.0 release for example ? (I > don't > > >> > > > > > > remember > > >> > > > > > > if for 11.1 we already switch u-boot or not). > > >> > > > > > I believe the change is in the u-boot port itself. However, > I > > >> > > > > > don't > > >> > > > > > think it's a u-boot problem (IMHO), it's a u-boot build > > >> > > > > > configuration > > >> > > > > > problem. There are different board variants with different > > >> > > > > > hardware > > >> > > > > > layout. u-boot has code for it, but our build does not > account > > >> > > > > > for. > > >> > > > > > Unless the scripts that build the 11.1 image use a different > > >> > > > > > revision > > >> > > > > > of the u-boot port, wouldn't it just use the current 2017.7 > > >> base? > > >> > > > > > > > >> > > > > > I'm trying to figure out how to generate a u-boot with the > > >> > > > > > correct > > >> > > > > > SPL > > >> > > > > > portion of u-boot. One could pull the SolidRun u-boot repo, > or > > >> go > > >> > > > > > find > > >> > > > > > the ports commit before the changeover and see if we can > > >> generate > > >> > > > > > the > > >> > > > > > correct SPL. > > >> > > > > > > > >> > > > > > I looked at Mainline u-boot and there is a board directory > for > > >> > > > > > solid > > >> > > > > > run. > > >> > > > > > https://github.com/u-boot/u-boot/blob/master/board/ > solidrun/ > > >> mx6cu > > >> > > > > > boxi > > >> > > > > > /mx6cuboxi.c > > >> > > > > > seems to support multiple memory configurations based on > > >> defines, > > >> > > > > > so > > >> > > > > > this should just be a configuration problem. > > >> > > > > > > > >> > > > > > We clearly need to start supporting the lower spec'd > SolidRun > > >> > > > > > boards > > >> > > > > > because this has come up a couple of times now since the > > >> > > > > > changeover. > > >> > > > > > It should be just a matter of creating a port that does the > same > > >> > > > > > thing > > >> > > > > > but generates the correct SPL file? My SOM is a i2eX so I > can't > > >> > > > > > be > > >> > > > > > too > > >> > > > > > much help (and I've also over volunteered myself!). > > >> > > > > > > > >> > > > > > Russ > > >> > > > > > > > >> > > > > The old imx6 uboot ports generated a single copy of uboot that > > >> > > > > would > > >> > > > > boot dual and quad-core versions of both hummingboard and > cubox > > >> > > > > systems. If the new uboot works only on quad core, that's > another > > >> > > > > regression. It might be possible to extract the u-boot.imx > file > > >> > > > > from a > > >> > > > > freebsd 10 image to get back to the old one. > > >> > > > > > > >> > > > > Ooops. Except it appears those no longer exist. > > >> > > > > > >> > > > Is this a loss of functionality when the changes were > upstreamed? Is > > >> > > > it a > > >> > > > bad configuration on our part? Any idea what might be going on > or > > >> how > > >> > > > to > > >> > > > fix it? > > >> > > > > >> > > The vendor uboot worked well. The generic mainline, apparently > not so > > >> > > much. It may indicate that the vendor didn't upstream > everything. I > > >> > > haven't worked much with the new imx6 uboot packages because for > me > > >> > > they're completely unusable because they lack support for > netbooting. > > >> > > (If you feel tempted to say something about efi and netbooting, > > >> please > > >> > > provide links to how-to documentation at the very least, and an > > >> example > > >> > > that works for armv6 would be even better.) > > >> > > > > >> > > > >> > I didn't think that we were enabling EFI + armv6 on anything yet by > > >> > default... > > >> > > > >> > Can't help you there. > > >> > > > >> > Warner > > >> > > >> We do, EFI is enabled by default in U-Boot on most of the boards. > > > > > > > > > And GENERIC actually supports that? > > > > > > > And more importantly, we have the right tooling to build the right images > > for EFI booting? > > > > Warner > > GENERIC supports that and boot1.efi/loader.efi built for arm is > correctly built. And -stable kernels boot with this setup as well? Or is this not default for ports-built u-boot? And the tooling goes well beyond just boot1.efi, and includes things like making sure the release images work correctly. And EFI support is about to start requiring efirt working (well, efibootmgr is coming soon) to manage booting, at least on x86. What's the story for arm? Warner From owner-freebsd-arm@freebsd.org Wed Sep 27 09:32:29 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4262E2F8AA for ; Wed, 27 Sep 2017 09:32:29 +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 3316B6B206; Wed, 27 Sep 2017 09:32:28 +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 e120fe07; Wed, 27 Sep 2017 11:32:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=a8fSK08T5LvfMSqtWXyf7H8U1Ec=; b=eQNAHHh2rgfPHGnbGgPYy8vj28OJ aUIC6ytp4cnAmjvuXVQeNVHNIszpIoVnFnFLvWgveEFLXBskURjmTIqCvi03m3Wb JkOW1tkOr057yR1sTL7C+UIMfvumxqEVAzLYnnmKlFrrLCcmXNYCXSqpj0coFHV9 JXmRujs6nr21fUQ= 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=KID0tfc7GfIW4tqQir8MU1Xdt181/hNBx3LmesuHUVjJgbNQVwevpokv vqqqNpt+0aNoHK8vEsDCWf0lyw/oNbheJhMEtpv7Lg3SEVjmcOJwumOx0V4GJdmA V3NRJ3YL0pyTuiA+WIdWEZiXhGht6p/enDS72brXpp/emQthvXw= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 206b67ff TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 27 Sep 2017 11:32:26 +0200 (CEST) Date: Wed, 27 Sep 2017 11:32:26 +0200 From: Emmanuel Vadot To: Warner Losh Cc: Ian Lepore , freebsd-arm Subject: Re: CUBOX snapshots working? Message-Id: <20170927113226.899fbb9617783b356bdb6279@bidouilliste.com> In-Reply-To: References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> <20170927112015.e997d7b1b8e9002c8377547a@bidouilliste.com> <20170927112548.1b405a726da9938c26ad5cbb@bidouilliste.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:32:29 -0000 On Wed, 27 Sep 2017 03:28:39 -0600 Warner Losh wrote: > On Wed, Sep 27, 2017 at 3:25 AM, Emmanuel Vadot > wrote: > > > On Wed, 27 Sep 2017 03:22:42 -0600 > > Warner Losh wrote: > > > > > On Wed, Sep 27, 2017 at 3:21 AM, Warner Losh wrote: > > > > > > > > > > > > > > > On Wed, Sep 27, 2017 at 3:20 AM, Emmanuel Vadot > > > > > > wrote: > > > > > > > >> On Tue, 26 Sep 2017 17:05:40 -0600 > > > >> Warner Losh wrote: > > > >> > > > >> > On Tue, Sep 26, 2017 at 4:55 PM, Ian Lepore > > wrote: > > > >> > > > > >> > > On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote: > > > >> > > > On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore > > > >> wrote: > > > >> > > > > > > >> > > > > > > > >> > > > > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley wrote: > > > >> > > > > > > > > >> > > > > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot > > > >> > > >> > > > > > te.c > > > >> > > > > > om> wrote: > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > > > >> > > > > > > Ian Lepore wrote: > > > >> > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > > >> > > > > > > > > Brett Glass wrote: > > > >> > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > One would think that sauce for the goose would be > > sauce > > > >> > > > > > > > > > for > > > >> > > > > > > > > > the > > > >> > > > > > > > > > gander. But is this particular Cubox now useless > > with > > > >> > > > > > > > > > FreeBSD? > > > >> > > > > > > > > > And if so, why? It is not an unusual model. The > > Cubox > > > >> > > > > > > > > > does > > > >> > > > > > > > > > work > > > >> > > > > > > > > > if I flash their "Ignition" startup software (which > > is > > > >> > > > > > > > > > used > > > >> > > > > > > > > > to > > > >> > > > > > > > > > bootstrap by downloading various OS images) to the > > same > > > >> > > > > > > > > > Micro SD card. > > > >> > > > > > > > > > > > > >> > > > > > > > > > --Brett Glass > > > >> > > > > > > > > The problem isn't FreeBSD related, it's U-Boot > > related. > > > >> > > > > > > > > > > > >> > > > > > > > > You could test build mainline u-boot just to confirm > > that > > > >> > > > > > > > > it > > > >> > > > > > > > > isn't > > > >> > > > > > > > > something due to our ports. > > > >> > > > > > > > > > > > >> > > > > > > > If we used to provide working cubox images and we don't > > > >> > > > > > > > anymore, > > > >> > > > > > > > it's > > > >> > > > > > > > hard to call that anything but a freebsd problem. > > > >> > > > > > > There is working cubox images, the last one is from > > > >> yesterday. > > > >> > > > > > > You even say yourself that you did test it and that it > > > >> worked. > > > >> > > > > > > Do we even know if the snapshot worked for this board ? > > > >> > > > > > > Brett, could you test the 11.0 release for example ? (I > > don't > > > >> > > > > > > remember > > > >> > > > > > > if for 11.1 we already switch u-boot or not). > > > >> > > > > > I believe the change is in the u-boot port itself. However, > > I > > > >> > > > > > don't > > > >> > > > > > think it's a u-boot problem (IMHO), it's a u-boot build > > > >> > > > > > configuration > > > >> > > > > > problem. There are different board variants with different > > > >> > > > > > hardware > > > >> > > > > > layout. u-boot has code for it, but our build does not > > account > > > >> > > > > > for. > > > >> > > > > > Unless the scripts that build the 11.1 image use a different > > > >> > > > > > revision > > > >> > > > > > of the u-boot port, wouldn't it just use the current 2017.7 > > > >> base? > > > >> > > > > > > > > >> > > > > > I'm trying to figure out how to generate a u-boot with the > > > >> > > > > > correct > > > >> > > > > > SPL > > > >> > > > > > portion of u-boot. One could pull the SolidRun u-boot repo, > > or > > > >> go > > > >> > > > > > find > > > >> > > > > > the ports commit before the changeover and see if we can > > > >> generate > > > >> > > > > > the > > > >> > > > > > correct SPL. > > > >> > > > > > > > > >> > > > > > I looked at Mainline u-boot and there is a board directory > > for > > > >> > > > > > solid > > > >> > > > > > run. > > > >> > > > > > https://github.com/u-boot/u-boot/blob/master/board/ > > solidrun/ > > > >> mx6cu > > > >> > > > > > boxi > > > >> > > > > > /mx6cuboxi.c > > > >> > > > > > seems to support multiple memory configurations based on > > > >> defines, > > > >> > > > > > so > > > >> > > > > > this should just be a configuration problem. > > > >> > > > > > > > > >> > > > > > We clearly need to start supporting the lower spec'd > > SolidRun > > > >> > > > > > boards > > > >> > > > > > because this has come up a couple of times now since the > > > >> > > > > > changeover. > > > >> > > > > > It should be just a matter of creating a port that does the > > same > > > >> > > > > > thing > > > >> > > > > > but generates the correct SPL file? My SOM is a i2eX so I > > can't > > > >> > > > > > be > > > >> > > > > > too > > > >> > > > > > much help (and I've also over volunteered myself!). > > > >> > > > > > > > > >> > > > > > Russ > > > >> > > > > > > > > >> > > > > The old imx6 uboot ports generated a single copy of uboot that > > > >> > > > > would > > > >> > > > > boot dual and quad-core versions of both hummingboard and > > cubox > > > >> > > > > systems. If the new uboot works only on quad core, that's > > another > > > >> > > > > regression. It might be possible to extract the u-boot.imx > > file > > > >> > > > > from a > > > >> > > > > freebsd 10 image to get back to the old one. > > > >> > > > > > > > >> > > > > Ooops. Except it appears those no longer exist. > > > >> > > > > > > >> > > > Is this a loss of functionality when the changes were > > upstreamed? Is > > > >> > > > it a > > > >> > > > bad configuration on our part? Any idea what might be going on > > or > > > >> how > > > >> > > > to > > > >> > > > fix it? > > > >> > > > > > >> > > The vendor uboot worked well. The generic mainline, apparently > > not so > > > >> > > much. It may indicate that the vendor didn't upstream > > everything. I > > > >> > > haven't worked much with the new imx6 uboot packages because for > > me > > > >> > > they're completely unusable because they lack support for > > netbooting. > > > >> > > (If you feel tempted to say something about efi and netbooting, > > > >> please > > > >> > > provide links to how-to documentation at the very least, and an > > > >> example > > > >> > > that works for armv6 would be even better.) > > > >> > > > > > >> > > > > >> > I didn't think that we were enabling EFI + armv6 on anything yet by > > > >> > default... > > > >> > > > > >> > Can't help you there. > > > >> > > > > >> > Warner > > > >> > > > >> We do, EFI is enabled by default in U-Boot on most of the boards. > > > > > > > > > > > > And GENERIC actually supports that? > > > > > > > > > > And more importantly, we have the right tooling to build the right images > > > for EFI booting? > > > > > > Warner > > > > GENERIC supports that and boot1.efi/loader.efi built for arm is > > correctly built. > > > And -stable kernels boot with this setup as well? Or is this not default > for ports-built u-boot? > > And the tooling goes well beyond just boot1.efi, and includes things like > making sure the release images work correctly. And EFI support is about to > start requiring efirt working (well, efibootmgr is coming soon) to manage > booting, at least on x86. What's the story for arm? > > Warner You can take the release image for BBB for example, put boot1.efi as /EFI/boot/bootarm.efi in the MSDOS partition and it will work (I don't remember right now if you need U-Boot to load the DTB or not but it's just a matter or puting the DTB in the MSDOS as well under / or /DTB). -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Sep 27 09:34:31 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0F77E2F922 for ; Wed, 27 Sep 2017 09:34:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 5E5ED6B36F for ; Wed, 27 Sep 2017 09:34:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id 21so15124043iof.6 for ; Wed, 27 Sep 2017 02:34:31 -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=+6xqrNgskd3K8HPqyLI7xW3B6UAM9IhneXvvpxXJna0=; b=BqIWq6GUvv+Mpri26Fngd1305gQSGiTGm3pXC8F7FMXsKRx+DR/yi6XFDIu8ix3yye zhMZ8uyuDL0MB/Ei1IgpUhzH/kgnQziNfkbTbEQhYepekhsSzVFejhRdgy0zq3AeE+HJ 1b6srTeVg1VZp8H21jepal7UFXdxLVFIPbkf5dpUyPwxWSGFRJrpEZnK+QcYyDdoi+/c +W/R4Qw2gHoGo9xBXLmVn3pYJGrNjNleDKDWVxaBHj/mX+qj0zgtubzFJfr/AAgHRBiB 0XwRpt5DZsDjB8Sz3c/K1iS0a7/IN0i+BmAg9oBnJIe98VwyvBfeIs9/9US6Oavd9BaJ mfpQ== 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=+6xqrNgskd3K8HPqyLI7xW3B6UAM9IhneXvvpxXJna0=; b=qxBtjEAlqUJPMkuCVfUkiNHCAej+9li9xY4QcLOkRGwxaMnKEVBgWzzIE6n5lNT52B L+JDW1PJ1hYofCNd8vVn3iQMpeTlxZYv+OBqiYdY1UQxxkKcbABgICYFxBjElxVZ84WB NbjOUXBTEXU1UwXqLJtTtJ36lJ9nsdslBXCKf8nm1ej+1Kipmso7bcsG9AOngCEBwsf/ AKOV048AxB+piG+aHOJaz0jvcGrhGThhSh6ffAS4BzxaNrmKnDAnF0ovraI+mddzFwqp RWKdL4cAU59XcXeJSzvMd2bABFPu9jganAUEKnhk901atW0UrtDnpqGg/JgH+f00nW8l p6UA== X-Gm-Message-State: AMCzsaUtK4zsaTtncoaXyXZ2TemPyhhYqnb7e6DmsD8ZizaTt7Nm3ltK 28i3J78ZTjIzrnshwSh9kuMyI0D7dWpsINMUTISynA== X-Google-Smtp-Source: AOwi7QBCXE+EEVIQCxr4NGvNX0GOqcnUru83vB0W0A+NrjpSV3+StWmQqfq9eLYjEXB/PJZvTyYSxubZklWPHvdful8= X-Received: by 10.107.7.161 with SMTP id g33mr957512ioi.169.1506504870621; Wed, 27 Sep 2017 02:34:30 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Wed, 27 Sep 2017 02:34:29 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:f996:822c:89a6:8ee4] In-Reply-To: <20170927113226.899fbb9617783b356bdb6279@bidouilliste.com> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> <20170927112015.e997d7b1b8e9002c8377547a@bidouilliste.com> <20170927112548.1b405a726da9938c26ad5cbb@bidouilliste.com> <20170927113226.899fbb9617783b356bdb6279@bidouilliste.com> From: Warner Losh Date: Wed, 27 Sep 2017 03:34:29 -0600 X-Google-Sender-Auth: om-iWuZ_I53PvB8aaCLpfyngfxA Message-ID: Subject: Re: CUBOX snapshots working? To: Emmanuel Vadot Cc: Ian Lepore , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:34:31 -0000 On Wed, Sep 27, 2017 at 3:32 AM, Emmanuel Vadot wrote: > On Wed, 27 Sep 2017 03:28:39 -0600 > Warner Losh wrote: > > > On Wed, Sep 27, 2017 at 3:25 AM, Emmanuel Vadot > > wrote: > > > > > On Wed, 27 Sep 2017 03:22:42 -0600 > > > Warner Losh wrote: > > > > > > > On Wed, Sep 27, 2017 at 3:21 AM, Warner Losh wrote: > > > > > > > > > > > > > > > > > > > On Wed, Sep 27, 2017 at 3:20 AM, Emmanuel Vadot < > manu@bidouilliste.com > > > > > > > > > wrote: > > > > > > > > > >> On Tue, 26 Sep 2017 17:05:40 -0600 > > > > >> Warner Losh wrote: > > > > >> > > > > >> > On Tue, Sep 26, 2017 at 4:55 PM, Ian Lepore > > > wrote: > > > > >> > > > > > >> > > On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote: > > > > >> > > > On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore < > ian@freebsd.org> > > > > >> wrote: > > > > >> > > > > > > > >> > > > > > > > > >> > > > > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley wrote: > > > > >> > > > > > > > > > >> > > > > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot > > > > >> > > > >> > > > > > te.c > > > > >> > > > > > om> wrote: > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > > > > >> > > > > > > Ian Lepore wrote: > > > > >> > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot > wrote: > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > > > >> > > > > > > > > Brett Glass wrote: > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > One would think that sauce for the goose would > be > > > sauce > > > > >> > > > > > > > > > for > > > > >> > > > > > > > > > the > > > > >> > > > > > > > > > gander. But is this particular Cubox now useless > > > with > > > > >> > > > > > > > > > FreeBSD? > > > > >> > > > > > > > > > And if so, why? It is not an unusual model. The > > > Cubox > > > > >> > > > > > > > > > does > > > > >> > > > > > > > > > work > > > > >> > > > > > > > > > if I flash their "Ignition" startup software > (which > > > is > > > > >> > > > > > > > > > used > > > > >> > > > > > > > > > to > > > > >> > > > > > > > > > bootstrap by downloading various OS images) to > the > > > same > > > > >> > > > > > > > > > Micro SD card. > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > --Brett Glass > > > > >> > > > > > > > > The problem isn't FreeBSD related, it's U-Boot > > > related. > > > > >> > > > > > > > > > > > > >> > > > > > > > > You could test build mainline u-boot just to > confirm > > > that > > > > >> > > > > > > > > it > > > > >> > > > > > > > > isn't > > > > >> > > > > > > > > something due to our ports. > > > > >> > > > > > > > > > > > > >> > > > > > > > If we used to provide working cubox images and we > don't > > > > >> > > > > > > > anymore, > > > > >> > > > > > > > it's > > > > >> > > > > > > > hard to call that anything but a freebsd problem. > > > > >> > > > > > > There is working cubox images, the last one is from > > > > >> yesterday. > > > > >> > > > > > > You even say yourself that you did test it and that > it > > > > >> worked. > > > > >> > > > > > > Do we even know if the snapshot worked for this > board ? > > > > >> > > > > > > Brett, could you test the 11.0 release for example ? > (I > > > don't > > > > >> > > > > > > remember > > > > >> > > > > > > if for 11.1 we already switch u-boot or not). > > > > >> > > > > > I believe the change is in the u-boot port itself. > However, > > > I > > > > >> > > > > > don't > > > > >> > > > > > think it's a u-boot problem (IMHO), it's a u-boot build > > > > >> > > > > > configuration > > > > >> > > > > > problem. There are different board variants with > different > > > > >> > > > > > hardware > > > > >> > > > > > layout. u-boot has code for it, but our build does not > > > account > > > > >> > > > > > for. > > > > >> > > > > > Unless the scripts that build the 11.1 image use a > different > > > > >> > > > > > revision > > > > >> > > > > > of the u-boot port, wouldn't it just use the current > 2017.7 > > > > >> base? > > > > >> > > > > > > > > > >> > > > > > I'm trying to figure out how to generate a u-boot with > the > > > > >> > > > > > correct > > > > >> > > > > > SPL > > > > >> > > > > > portion of u-boot. One could pull the SolidRun u-boot > repo, > > > or > > > > >> go > > > > >> > > > > > find > > > > >> > > > > > the ports commit before the changeover and see if we can > > > > >> generate > > > > >> > > > > > the > > > > >> > > > > > correct SPL. > > > > >> > > > > > > > > > >> > > > > > I looked at Mainline u-boot and there is a board > directory > > > for > > > > >> > > > > > solid > > > > >> > > > > > run. > > > > >> > > > > > https://github.com/u-boot/u-boot/blob/master/board/ > > > solidrun/ > > > > >> mx6cu > > > > >> > > > > > boxi > > > > >> > > > > > /mx6cuboxi.c > > > > >> > > > > > seems to support multiple memory configurations based on > > > > >> defines, > > > > >> > > > > > so > > > > >> > > > > > this should just be a configuration problem. > > > > >> > > > > > > > > > >> > > > > > We clearly need to start supporting the lower spec'd > > > SolidRun > > > > >> > > > > > boards > > > > >> > > > > > because this has come up a couple of times now since the > > > > >> > > > > > changeover. > > > > >> > > > > > It should be just a matter of creating a port that does > the > > > same > > > > >> > > > > > thing > > > > >> > > > > > but generates the correct SPL file? My SOM is a i2eX so > I > > > can't > > > > >> > > > > > be > > > > >> > > > > > too > > > > >> > > > > > much help (and I've also over volunteered myself!). > > > > >> > > > > > > > > > >> > > > > > Russ > > > > >> > > > > > > > > > >> > > > > The old imx6 uboot ports generated a single copy of uboot > that > > > > >> > > > > would > > > > >> > > > > boot dual and quad-core versions of both hummingboard and > > > cubox > > > > >> > > > > systems. If the new uboot works only on quad core, that's > > > another > > > > >> > > > > regression. It might be possible to extract the > u-boot.imx > > > file > > > > >> > > > > from a > > > > >> > > > > freebsd 10 image to get back to the old one. > > > > >> > > > > > > > > >> > > > > Ooops. Except it appears those no longer exist. > > > > >> > > > > > > > >> > > > Is this a loss of functionality when the changes were > > > upstreamed? Is > > > > >> > > > it a > > > > >> > > > bad configuration on our part? Any idea what might be going > on > > > or > > > > >> how > > > > >> > > > to > > > > >> > > > fix it? > > > > >> > > > > > > >> > > The vendor uboot worked well. The generic mainline, > apparently > > > not so > > > > >> > > much. It may indicate that the vendor didn't upstream > > > everything. I > > > > >> > > haven't worked much with the new imx6 uboot packages because > for > > > me > > > > >> > > they're completely unusable because they lack support for > > > netbooting. > > > > >> > > (If you feel tempted to say something about efi and > netbooting, > > > > >> please > > > > >> > > provide links to how-to documentation at the very least, and > an > > > > >> example > > > > >> > > that works for armv6 would be even better.) > > > > >> > > > > > > >> > > > > > >> > I didn't think that we were enabling EFI + armv6 on anything > yet by > > > > >> > default... > > > > >> > > > > > >> > Can't help you there. > > > > >> > > > > > >> > Warner > > > > >> > > > > >> We do, EFI is enabled by default in U-Boot on most of the boards. > > > > > > > > > > > > > > > And GENERIC actually supports that? > > > > > > > > > > > > > And more importantly, we have the right tooling to build the right > images > > > > for EFI booting? > > > > > > > > Warner > > > > > > GENERIC supports that and boot1.efi/loader.efi built for arm is > > > correctly built. > > > > > > And -stable kernels boot with this setup as well? Or is this not default > > for ports-built u-boot? > > > > And the tooling goes well beyond just boot1.efi, and includes things like > > making sure the release images work correctly. And EFI support is about > to > > start requiring efirt working (well, efibootmgr is coming soon) to manage > > booting, at least on x86. What's the story for arm? > > > > Warner > > You can take the release image for BBB for example, put boot1.efi > as /EFI/boot/bootarm.efi in the MSDOS partition and it will work (I > don't remember right now if you need U-Boot to load the DTB or not but > it's just a matter or puting the DTB in the MSDOS as well under / > or /DTB). Do they work w/o doing that? Warner From owner-freebsd-arm@freebsd.org Wed Sep 27 09:54:34 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4605E2FDD3 for ; Wed, 27 Sep 2017 09:54:34 +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 02CB26BD1D; Wed, 27 Sep 2017 09:54:33 +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 c2a429f4; Wed, 27 Sep 2017 11:54:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=bC5WcPhwHdVeGooyNHv3olzwIjA=; b=Qgl2GBT/IT4x712IPKcrVsAnGFN2 52oNlLNp8iLf0Tukdi3LNd8TK/rybBIXYG4UVmLCeH/2NURLXhVYzgpCz3NCNHYe ywluqkkfh5z49RILr9JC8qcJ/mbISi5xRZw65I//d3pAaHXXaH8Hlq6BgsEhuqiu WpTjll4mkg+8YDM= 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=Ww/U6g5eKh1m3qPU0ZucuW9jQhrh/EVG/YSgOkhyrLIRUGg3vHQnH+AA H6oxYs8DugAUBnzcZa0DnCcIu+2+7Gu3Y1q869BGVtG95CnCerz0Njgi18mNBeiO 9RjoTxWcCLw9jDUf6FC5lBKBhDl0FzuDr+VwCS5xqVFjjLubX0Q= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 7c699b58 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 27 Sep 2017 11:54:31 +0200 (CEST) Date: Wed, 27 Sep 2017 11:54:29 +0200 From: Emmanuel Vadot To: Warner Losh Cc: Ian Lepore , freebsd-arm Subject: Re: CUBOX snapshots working? Message-Id: <20170927115429.2cb567567a0523961bae677b@bidouilliste.com> In-Reply-To: References: <201709260339.VAA16701@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> <20170927112015.e997d7b1b8e9002c8377547a@bidouilliste.com> <20170927112548.1b405a726da9938c26ad5cbb@bidouilliste.com> <20170927113226.899fbb9617783b356bdb6279@bidouilliste.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:54:34 -0000 On Wed, 27 Sep 2017 03:34:29 -0600 Warner Losh wrote: > On Wed, Sep 27, 2017 at 3:32 AM, Emmanuel Vadot > wrote: > > > On Wed, 27 Sep 2017 03:28:39 -0600 > > Warner Losh wrote: > > > > > On Wed, Sep 27, 2017 at 3:25 AM, Emmanuel Vadot > > > wrote: > > > > > > > On Wed, 27 Sep 2017 03:22:42 -0600 > > > > Warner Losh wrote: > > > > > > > > > On Wed, Sep 27, 2017 at 3:21 AM, Warner Losh wrote: > > > > > > > > > > > > > > > > > > > > > > > On Wed, Sep 27, 2017 at 3:20 AM, Emmanuel Vadot < > > manu@bidouilliste.com > > > > > > > > > > > wrote: > > > > > > > > > > > >> On Tue, 26 Sep 2017 17:05:40 -0600 > > > > > >> Warner Losh wrote: > > > > > >> > > > > > >> > On Tue, Sep 26, 2017 at 4:55 PM, Ian Lepore > > > > wrote: > > > > > >> > > > > > > >> > > On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote: > > > > > >> > > > On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore < > > ian@freebsd.org> > > > > > >> wrote: > > > > > >> > > > > > > > > >> > > > > > > > > > >> > > > > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley wrote: > > > > > >> > > > > > > > > > > >> > > > > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot > > > > > >> > > > > >> > > > > > te.c > > > > > >> > > > > > om> wrote: > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > > > > > >> > > > > > > Ian Lepore wrote: > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot > > wrote: > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > > > > >> > > > > > > > > Brett Glass wrote: > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > One would think that sauce for the goose would > > be > > > > sauce > > > > > >> > > > > > > > > > for > > > > > >> > > > > > > > > > the > > > > > >> > > > > > > > > > gander. But is this particular Cubox now useless > > > > with > > > > > >> > > > > > > > > > FreeBSD? > > > > > >> > > > > > > > > > And if so, why? It is not an unusual model. The > > > > Cubox > > > > > >> > > > > > > > > > does > > > > > >> > > > > > > > > > work > > > > > >> > > > > > > > > > if I flash their "Ignition" startup software > > (which > > > > is > > > > > >> > > > > > > > > > used > > > > > >> > > > > > > > > > to > > > > > >> > > > > > > > > > bootstrap by downloading various OS images) to > > the > > > > same > > > > > >> > > > > > > > > > Micro SD card. > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > --Brett Glass > > > > > >> > > > > > > > > The problem isn't FreeBSD related, it's U-Boot > > > > related. > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > You could test build mainline u-boot just to > > confirm > > > > that > > > > > >> > > > > > > > > it > > > > > >> > > > > > > > > isn't > > > > > >> > > > > > > > > something due to our ports. > > > > > >> > > > > > > > > > > > > > >> > > > > > > > If we used to provide working cubox images and we > > don't > > > > > >> > > > > > > > anymore, > > > > > >> > > > > > > > it's > > > > > >> > > > > > > > hard to call that anything but a freebsd problem. > > > > > >> > > > > > > There is working cubox images, the last one is from > > > > > >> yesterday. > > > > > >> > > > > > > You even say yourself that you did test it and that > > it > > > > > >> worked. > > > > > >> > > > > > > Do we even know if the snapshot worked for this > > board ? > > > > > >> > > > > > > Brett, could you test the 11.0 release for example ? > > (I > > > > don't > > > > > >> > > > > > > remember > > > > > >> > > > > > > if for 11.1 we already switch u-boot or not). > > > > > >> > > > > > I believe the change is in the u-boot port itself. > > However, > > > > I > > > > > >> > > > > > don't > > > > > >> > > > > > think it's a u-boot problem (IMHO), it's a u-boot build > > > > > >> > > > > > configuration > > > > > >> > > > > > problem. There are different board variants with > > different > > > > > >> > > > > > hardware > > > > > >> > > > > > layout. u-boot has code for it, but our build does not > > > > account > > > > > >> > > > > > for. > > > > > >> > > > > > Unless the scripts that build the 11.1 image use a > > different > > > > > >> > > > > > revision > > > > > >> > > > > > of the u-boot port, wouldn't it just use the current > > 2017.7 > > > > > >> base? > > > > > >> > > > > > > > > > > >> > > > > > I'm trying to figure out how to generate a u-boot with > > the > > > > > >> > > > > > correct > > > > > >> > > > > > SPL > > > > > >> > > > > > portion of u-boot. One could pull the SolidRun u-boot > > repo, > > > > or > > > > > >> go > > > > > >> > > > > > find > > > > > >> > > > > > the ports commit before the changeover and see if we can > > > > > >> generate > > > > > >> > > > > > the > > > > > >> > > > > > correct SPL. > > > > > >> > > > > > > > > > > >> > > > > > I looked at Mainline u-boot and there is a board > > directory > > > > for > > > > > >> > > > > > solid > > > > > >> > > > > > run. > > > > > >> > > > > > https://github.com/u-boot/u-boot/blob/master/board/ > > > > solidrun/ > > > > > >> mx6cu > > > > > >> > > > > > boxi > > > > > >> > > > > > /mx6cuboxi.c > > > > > >> > > > > > seems to support multiple memory configurations based on > > > > > >> defines, > > > > > >> > > > > > so > > > > > >> > > > > > this should just be a configuration problem. > > > > > >> > > > > > > > > > > >> > > > > > We clearly need to start supporting the lower spec'd > > > > SolidRun > > > > > >> > > > > > boards > > > > > >> > > > > > because this has come up a couple of times now since the > > > > > >> > > > > > changeover. > > > > > >> > > > > > It should be just a matter of creating a port that does > > the > > > > same > > > > > >> > > > > > thing > > > > > >> > > > > > but generates the correct SPL file? My SOM is a i2eX so > > I > > > > can't > > > > > >> > > > > > be > > > > > >> > > > > > too > > > > > >> > > > > > much help (and I've also over volunteered myself!). > > > > > >> > > > > > > > > > > >> > > > > > Russ > > > > > >> > > > > > > > > > > >> > > > > The old imx6 uboot ports generated a single copy of uboot > > that > > > > > >> > > > > would > > > > > >> > > > > boot dual and quad-core versions of both hummingboard and > > > > cubox > > > > > >> > > > > systems. If the new uboot works only on quad core, that's > > > > another > > > > > >> > > > > regression. It might be possible to extract the > > u-boot.imx > > > > file > > > > > >> > > > > from a > > > > > >> > > > > freebsd 10 image to get back to the old one. > > > > > >> > > > > > > > > > >> > > > > Ooops. Except it appears those no longer exist. > > > > > >> > > > > > > > > >> > > > Is this a loss of functionality when the changes were > > > > upstreamed? Is > > > > > >> > > > it a > > > > > >> > > > bad configuration on our part? Any idea what might be going > > on > > > > or > > > > > >> how > > > > > >> > > > to > > > > > >> > > > fix it? > > > > > >> > > > > > > > >> > > The vendor uboot worked well. The generic mainline, > > apparently > > > > not so > > > > > >> > > much. It may indicate that the vendor didn't upstream > > > > everything. I > > > > > >> > > haven't worked much with the new imx6 uboot packages because > > for > > > > me > > > > > >> > > they're completely unusable because they lack support for > > > > netbooting. > > > > > >> > > (If you feel tempted to say something about efi and > > netbooting, > > > > > >> please > > > > > >> > > provide links to how-to documentation at the very least, and > > an > > > > > >> example > > > > > >> > > that works for armv6 would be even better.) > > > > > >> > > > > > > > >> > > > > > > >> > I didn't think that we were enabling EFI + armv6 on anything > > yet by > > > > > >> > default... > > > > > >> > > > > > > >> > Can't help you there. > > > > > >> > > > > > > >> > Warner > > > > > >> > > > > > >> We do, EFI is enabled by default in U-Boot on most of the boards. > > > > > > > > > > > > > > > > > > And GENERIC actually supports that? > > > > > > > > > > > > > > > > And more importantly, we have the right tooling to build the right > > images > > > > > for EFI booting? > > > > > > > > > > Warner > > > > > > > > GENERIC supports that and boot1.efi/loader.efi built for arm is > > > > correctly built. > > > > > > > > > And -stable kernels boot with this setup as well? Or is this not default > > > for ports-built u-boot? > > > > > > And the tooling goes well beyond just boot1.efi, and includes things like > > > making sure the release images work correctly. And EFI support is about > > to > > > start requiring efirt working (well, efibootmgr is coming soon) to manage > > > booting, at least on x86. What's the story for arm? > > > > > > Warner > > > > You can take the release image for BBB for example, put boot1.efi > > as /EFI/boot/bootarm.efi in the MSDOS partition and it will work (I > > don't remember right now if you need U-Boot to load the DTB or not but > > it's just a matter or puting the DTB in the MSDOS as well under / > > or /DTB). > > > Do they work w/o doing that? > > Warner Without doing what ? The release script don't put boot1.efi on the msdos partition. If we do it, it will have a higher priority than loading ubldr. We should do it at one point, but not now. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Sep 27 09:59:16 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECCBAE2FEAE for ; Wed, 27 Sep 2017 09:59:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A949A6BE99 for ; Wed, 27 Sep 2017 09:59:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id e134so5904104ite.3 for ; Wed, 27 Sep 2017 02:59:15 -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=lk30sxYBQOXHjjqKWFn4zEEXUW049HbQRovkgGWksm0=; b=K0sPP/7hYWzANt6ORpeU1DCOnjXt2KlmV1cfbcwY6Otc/2w+F1S8Zn2WMrdrRXbxn1 cJUvCk6j1UbTazWCgVdtt83ZgjORFF/O2XLqrWvwCsRio2pwSPfmdfgOXUQfC2ZStpF7 E5PuNJQSSNJ+Ksp4B5FkrzPsG7cQe9O6jaBB2CRtTviwdFvDQFA61L+0+IHDkcn3fbAR O/2gHhD8qjZuORdYgfSVBrHrXNR6pEj6VIThA13x71j0n0su5Un4Pkp83jVY4zbyNlz7 KbJLoEnhobtH1SFkz86N9ZQ03FEEocCm5woCp+hnjP0xdI/EI2Vl5N31QaFbl/0dL4zT 29gw== 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=lk30sxYBQOXHjjqKWFn4zEEXUW049HbQRovkgGWksm0=; b=c71COY+LJCwfA0k1GZtYAyaQFmA0GQO7qcp/XFezv8z0fotk7sx5HFRMLUCCVYh3gN H0rADqCDTFhLKge2F1Jhf9Vo3L6/6FbWm78b9NHwP0ExyntOzvCgGfiWIbSutW1/oIiw fXGQ+jYSn/w9MpXsfKA9KIOIlIh/ctR7YbVphIemVTngTCEwRBda7L83AxuTdyDj6Cro rhh37EqdsJoDL87uXiRpd1bDcER9zsky+i82ELzPh93oUU9iruxJ5W1ceOF2WXYJnIcX J2cgylZlQvLhYe0tcDNG57s1VSL0uTX0mJAfxk8k3ZKUIoEhiPShb8yNo/M+X0wm1yQR 20pw== X-Gm-Message-State: AHPjjUgiCL2S8+8C0joegRoEcRb5Fz6GE+hs7NXvjsc83k9ADOSlEc04 2MTZ9gBvXipraUUOUUJI14DELdUi8e/PBrFh+EeIeQ== X-Google-Smtp-Source: AOwi7QBF675SpdBzwlbKNLrVXBwkv/R3gz9lixTSvn77nKda+6S3RHoBYuB2J/I+0QSPEr8hdUdtUp5et/1TlQdL33c= X-Received: by 10.36.20.149 with SMTP id 143mr1454444itg.63.1506506355089; Wed, 27 Sep 2017 02:59:15 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Wed, 27 Sep 2017 02:59:14 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:f996:822c:89a6:8ee4] In-Reply-To: <20170927115429.2cb567567a0523961bae677b@bidouilliste.com> References: <201709260339.VAA16701@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> <20170927112015.e997d7b1b8e9002c8377547a@bidouilliste.com> <20170927112548.1b405a726da9938c26ad5cbb@bidouilliste.com> <20170927113226.899fbb9617783b356bdb6279@bidouilliste.com> <20170927115429.2cb567567a0523961bae677b@bidouilliste.com> From: Warner Losh Date: Wed, 27 Sep 2017 03:59:14 -0600 X-Google-Sender-Auth: uOMFd80qShNRe6ZgmQMEAwmau1w Message-ID: Subject: Re: CUBOX snapshots working? To: Emmanuel Vadot Cc: Ian Lepore , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:59:16 -0000 On Wed, Sep 27, 2017 at 3:54 AM, Emmanuel Vadot wrote: > On Wed, 27 Sep 2017 03:34:29 -0600 > Warner Losh wrote: > > > On Wed, Sep 27, 2017 at 3:32 AM, Emmanuel Vadot > > wrote: > > > > > On Wed, 27 Sep 2017 03:28:39 -0600 > > > Warner Losh wrote: > > > > > > > On Wed, Sep 27, 2017 at 3:25 AM, Emmanuel Vadot < > manu@bidouilliste.com> > > > > wrote: > > > > > > > > > On Wed, 27 Sep 2017 03:22:42 -0600 > > > > > Warner Losh wrote: > > > > > > > > > > > On Wed, Sep 27, 2017 at 3:21 AM, Warner Losh > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Sep 27, 2017 at 3:20 AM, Emmanuel Vadot < > > > manu@bidouilliste.com > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > >> On Tue, 26 Sep 2017 17:05:40 -0600 > > > > > > >> Warner Losh wrote: > > > > > > >> > > > > > > >> > On Tue, Sep 26, 2017 at 4:55 PM, Ian Lepore < > ian@freebsd.org> > > > > > wrote: > > > > > > >> > > > > > > > >> > > On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote: > > > > > > >> > > > On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore < > > > ian@freebsd.org> > > > > > > >> wrote: > > > > > > >> > > > > > > > > > >> > > > > > > > > > > >> > > > > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley > wrote: > > > > > > >> > > > > > > > > > > > >> > > > > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot > > > > > > >> > > > > > >> > > > > > te.c > > > > > > >> > > > > > om> wrote: > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > > > > > > >> > > > > > > Ian Lepore wrote: > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel > Vadot > > > wrote: > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > > > > > >> > > > > > > > > Brett Glass wrote: > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > One would think that sauce for the goose > would > > > be > > > > > sauce > > > > > > >> > > > > > > > > > for > > > > > > >> > > > > > > > > > the > > > > > > >> > > > > > > > > > gander. But is this particular Cubox now > useless > > > > > with > > > > > > >> > > > > > > > > > FreeBSD? > > > > > > >> > > > > > > > > > And if so, why? It is not an unusual model. > The > > > > > Cubox > > > > > > >> > > > > > > > > > does > > > > > > >> > > > > > > > > > work > > > > > > >> > > > > > > > > > if I flash their "Ignition" startup software > > > (which > > > > > is > > > > > > >> > > > > > > > > > used > > > > > > >> > > > > > > > > > to > > > > > > >> > > > > > > > > > bootstrap by downloading various OS images) > to > > > the > > > > > same > > > > > > >> > > > > > > > > > Micro SD card. > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > --Brett Glass > > > > > > >> > > > > > > > > The problem isn't FreeBSD related, it's > U-Boot > > > > > related. > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > You could test build mainline u-boot just to > > > confirm > > > > > that > > > > > > >> > > > > > > > > it > > > > > > >> > > > > > > > > isn't > > > > > > >> > > > > > > > > something due to our ports. > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > If we used to provide working cubox images and > we > > > don't > > > > > > >> > > > > > > > anymore, > > > > > > >> > > > > > > > it's > > > > > > >> > > > > > > > hard to call that anything but a freebsd > problem. > > > > > > >> > > > > > > There is working cubox images, the last one is > from > > > > > > >> yesterday. > > > > > > >> > > > > > > You even say yourself that you did test it and > that > > > it > > > > > > >> worked. > > > > > > >> > > > > > > Do we even know if the snapshot worked for this > > > board ? > > > > > > >> > > > > > > Brett, could you test the 11.0 release for > example ? > > > (I > > > > > don't > > > > > > >> > > > > > > remember > > > > > > >> > > > > > > if for 11.1 we already switch u-boot or not). > > > > > > >> > > > > > I believe the change is in the u-boot port itself. > > > However, > > > > > I > > > > > > >> > > > > > don't > > > > > > >> > > > > > think it's a u-boot problem (IMHO), it's a u-boot > build > > > > > > >> > > > > > configuration > > > > > > >> > > > > > problem. There are different board variants with > > > different > > > > > > >> > > > > > hardware > > > > > > >> > > > > > layout. u-boot has code for it, but our build does > not > > > > > account > > > > > > >> > > > > > for. > > > > > > >> > > > > > Unless the scripts that build the 11.1 image use a > > > different > > > > > > >> > > > > > revision > > > > > > >> > > > > > of the u-boot port, wouldn't it just use the current > > > 2017.7 > > > > > > >> base? > > > > > > >> > > > > > > > > > > > >> > > > > > I'm trying to figure out how to generate a u-boot > with > > > the > > > > > > >> > > > > > correct > > > > > > >> > > > > > SPL > > > > > > >> > > > > > portion of u-boot. One could pull the SolidRun > u-boot > > > repo, > > > > > or > > > > > > >> go > > > > > > >> > > > > > find > > > > > > >> > > > > > the ports commit before the changeover and see if > we can > > > > > > >> generate > > > > > > >> > > > > > the > > > > > > >> > > > > > correct SPL. > > > > > > >> > > > > > > > > > > > >> > > > > > I looked at Mainline u-boot and there is a board > > > directory > > > > > for > > > > > > >> > > > > > solid > > > > > > >> > > > > > run. > > > > > > >> > > > > > https://github.com/u-boot/u-boot/blob/master/board/ > > > > > solidrun/ > > > > > > >> mx6cu > > > > > > >> > > > > > boxi > > > > > > >> > > > > > /mx6cuboxi.c > > > > > > >> > > > > > seems to support multiple memory configurations > based on > > > > > > >> defines, > > > > > > >> > > > > > so > > > > > > >> > > > > > this should just be a configuration problem. > > > > > > >> > > > > > > > > > > > >> > > > > > We clearly need to start supporting the lower spec'd > > > > > SolidRun > > > > > > >> > > > > > boards > > > > > > >> > > > > > because this has come up a couple of times now > since the > > > > > > >> > > > > > changeover. > > > > > > >> > > > > > It should be just a matter of creating a port that > does > > > the > > > > > same > > > > > > >> > > > > > thing > > > > > > >> > > > > > but generates the correct SPL file? My SOM is a > i2eX so > > > I > > > > > can't > > > > > > >> > > > > > be > > > > > > >> > > > > > too > > > > > > >> > > > > > much help (and I've also over volunteered myself!). > > > > > > >> > > > > > > > > > > > >> > > > > > Russ > > > > > > >> > > > > > > > > > > > >> > > > > The old imx6 uboot ports generated a single copy of > uboot > > > that > > > > > > >> > > > > would > > > > > > >> > > > > boot dual and quad-core versions of both hummingboard > and > > > > > cubox > > > > > > >> > > > > systems. If the new uboot works only on quad core, > that's > > > > > another > > > > > > >> > > > > regression. It might be possible to extract the > > > u-boot.imx > > > > > file > > > > > > >> > > > > from a > > > > > > >> > > > > freebsd 10 image to get back to the old one. > > > > > > >> > > > > > > > > > > >> > > > > Ooops. Except it appears those no longer exist. > > > > > > >> > > > > > > > > > >> > > > Is this a loss of functionality when the changes were > > > > > upstreamed? Is > > > > > > >> > > > it a > > > > > > >> > > > bad configuration on our part? Any idea what might be > going > > > on > > > > > or > > > > > > >> how > > > > > > >> > > > to > > > > > > >> > > > fix it? > > > > > > >> > > > > > > > > >> > > The vendor uboot worked well. The generic mainline, > > > apparently > > > > > not so > > > > > > >> > > much. It may indicate that the vendor didn't upstream > > > > > everything. I > > > > > > >> > > haven't worked much with the new imx6 uboot packages > because > > > for > > > > > me > > > > > > >> > > they're completely unusable because they lack support for > > > > > netbooting. > > > > > > >> > > (If you feel tempted to say something about efi and > > > netbooting, > > > > > > >> please > > > > > > >> > > provide links to how-to documentation at the very least, > and > > > an > > > > > > >> example > > > > > > >> > > that works for armv6 would be even better.) > > > > > > >> > > > > > > > > >> > > > > > > > >> > I didn't think that we were enabling EFI + armv6 on anything > > > yet by > > > > > > >> > default... > > > > > > >> > > > > > > > >> > Can't help you there. > > > > > > >> > > > > > > > >> > Warner > > > > > > >> > > > > > > >> We do, EFI is enabled by default in U-Boot on most of the > boards. > > > > > > > > > > > > > > > > > > > > > And GENERIC actually supports that? > > > > > > > > > > > > > > > > > > > And more importantly, we have the right tooling to build the > right > > > images > > > > > > for EFI booting? > > > > > > > > > > > > Warner > > > > > > > > > > GENERIC supports that and boot1.efi/loader.efi built for arm is > > > > > correctly built. > > > > > > > > > > > > And -stable kernels boot with this setup as well? Or is this not > default > > > > for ports-built u-boot? > > > > > > > > And the tooling goes well beyond just boot1.efi, and includes things > like > > > > making sure the release images work correctly. And EFI support is > about > > > to > > > > start requiring efirt working (well, efibootmgr is coming soon) to > manage > > > > booting, at least on x86. What's the story for arm? > > > > > > > > Warner > > > > > > You can take the release image for BBB for example, put boot1.efi > > > as /EFI/boot/bootarm.efi in the MSDOS partition and it will work (I > > > don't remember right now if you need U-Boot to load the DTB or not but > > > it's just a matter or puting the DTB in the MSDOS as well under / > > > or /DTB). > > > > > > Do they work w/o doing that? > > > > Warner > > Without doing what ? The release script don't put boot1.efi on the > msdos partition. If we do it, it will have a higher priority than > loading ubldr. We should do it at one point, but not now. Sorry, I mean 'will we boot with the old, crappy u-boot ABI interface to /boot/loader and have a kernel boot'. Sounds like the answer is 'that still works, don't worry'. Warner From owner-freebsd-arm@freebsd.org Wed Sep 27 10:02:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B00FE301D1 for ; Wed, 27 Sep 2017 10:02:11 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A3C5E6C0AA; Wed, 27 Sep 2017 10:02:10 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id ebac9759; Wed, 27 Sep 2017 12:02:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=FkUBvCXn9IlscV1USFdCBLjUFoo=; b=A7qML0xdTUpYft9OpOat1mVK4VLi Jr/6KCkY5sHaWGqdZU45k9OCUFU8JS1lYYcQDP4bOe7l2Nq1/d3Ej8uBqVK9vB2l r+2dvp0ZGIipCLKyffOLKxRw1xOWgIrR0Uu+RPQqUfFc8cyVq58B/xEE4Vg/JnW1 IeAOpgxdxc2kWpE= 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=Jv/lecDbC4bTfdj0yPCQC4mlBgbbTQBbBwsakenLuy7i6Uf5eYhpE2Rf 7nplLfl3hhOY+RdnKoOBmNL2p4PSjMaF83LKqugiMOTww+71B+F47vnHZc4ua31t TNadCsbJlTfgr3i9NwUoZR70FRMLxX5M0zyL94DcmxXm+mpmfDw= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id f161d361 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 27 Sep 2017 12:02:08 +0200 (CEST) Date: Wed, 27 Sep 2017 12:02:06 +0200 From: Emmanuel Vadot To: Warner Losh Cc: Ian Lepore , freebsd-arm Subject: Re: CUBOX snapshots working? Message-Id: <20170927120206.6bfd125854c6cee0af1f8bcd@bidouilliste.com> In-Reply-To: References: <201709260339.VAA16701@mail.lariat.net> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> <20170927112015.e997d7b1b8e9002c8377547a@bidouilliste.com> <20170927112548.1b405a726da9938c26ad5cbb@bidouilliste.com> <20170927113226.899fbb9617783b356bdb6279@bidouilliste.com> <20170927115429.2cb567567a0523961bae677b@bidouilliste.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 10:02:11 -0000 On Wed, 27 Sep 2017 03:59:14 -0600 Warner Losh wrote: > On Wed, Sep 27, 2017 at 3:54 AM, Emmanuel Vadot > wrote: > > > On Wed, 27 Sep 2017 03:34:29 -0600 > > Warner Losh wrote: > > > > > On Wed, Sep 27, 2017 at 3:32 AM, Emmanuel Vadot > > > wrote: > > > > > > > On Wed, 27 Sep 2017 03:28:39 -0600 > > > > Warner Losh wrote: > > > > > > > > > On Wed, Sep 27, 2017 at 3:25 AM, Emmanuel Vadot < > > manu@bidouilliste.com> > > > > > wrote: > > > > > > > > > > > On Wed, 27 Sep 2017 03:22:42 -0600 > > > > > > Warner Losh wrote: > > > > > > > > > > > > > On Wed, Sep 27, 2017 at 3:21 AM, Warner Losh > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Sep 27, 2017 at 3:20 AM, Emmanuel Vadot < > > > > manu@bidouilliste.com > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > >> On Tue, 26 Sep 2017 17:05:40 -0600 > > > > > > > >> Warner Losh wrote: > > > > > > > >> > > > > > > > >> > On Tue, Sep 26, 2017 at 4:55 PM, Ian Lepore < > > ian@freebsd.org> > > > > > > wrote: > > > > > > > >> > > > > > > > > >> > > On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote: > > > > > > > >> > > > On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore < > > > > ian@freebsd.org> > > > > > > > >> wrote: > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > > >> > > > > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley > > wrote: > > > > > > > >> > > > > > > > > > > > > >> > > > > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot > > > > > > > >> > > > > > > >> > > > > > te.c > > > > > > > >> > > > > > om> wrote: > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > > > > > > > >> > > > > > > Ian Lepore wrote: > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel > > Vadot > > > > wrote: > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > > > > > > >> > > > > > > > > Brett Glass wrote: > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > One would think that sauce for the goose > > would > > > > be > > > > > > sauce > > > > > > > >> > > > > > > > > > for > > > > > > > >> > > > > > > > > > the > > > > > > > >> > > > > > > > > > gander. But is this particular Cubox now > > useless > > > > > > with > > > > > > > >> > > > > > > > > > FreeBSD? > > > > > > > >> > > > > > > > > > And if so, why? It is not an unusual model. > > The > > > > > > Cubox > > > > > > > >> > > > > > > > > > does > > > > > > > >> > > > > > > > > > work > > > > > > > >> > > > > > > > > > if I flash their "Ignition" startup software > > > > (which > > > > > > is > > > > > > > >> > > > > > > > > > used > > > > > > > >> > > > > > > > > > to > > > > > > > >> > > > > > > > > > bootstrap by downloading various OS images) > > to > > > > the > > > > > > same > > > > > > > >> > > > > > > > > > Micro SD card. > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > --Brett Glass > > > > > > > >> > > > > > > > > The problem isn't FreeBSD related, it's > > U-Boot > > > > > > related. > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > You could test build mainline u-boot just to > > > > confirm > > > > > > that > > > > > > > >> > > > > > > > > it > > > > > > > >> > > > > > > > > isn't > > > > > > > >> > > > > > > > > something due to our ports. > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > If we used to provide working cubox images and > > we > > > > don't > > > > > > > >> > > > > > > > anymore, > > > > > > > >> > > > > > > > it's > > > > > > > >> > > > > > > > hard to call that anything but a freebsd > > problem. > > > > > > > >> > > > > > > There is working cubox images, the last one is > > from > > > > > > > >> yesterday. > > > > > > > >> > > > > > > You even say yourself that you did test it and > > that > > > > it > > > > > > > >> worked. > > > > > > > >> > > > > > > Do we even know if the snapshot worked for this > > > > board ? > > > > > > > >> > > > > > > Brett, could you test the 11.0 release for > > example ? > > > > (I > > > > > > don't > > > > > > > >> > > > > > > remember > > > > > > > >> > > > > > > if for 11.1 we already switch u-boot or not). > > > > > > > >> > > > > > I believe the change is in the u-boot port itself. > > > > However, > > > > > > I > > > > > > > >> > > > > > don't > > > > > > > >> > > > > > think it's a u-boot problem (IMHO), it's a u-boot > > build > > > > > > > >> > > > > > configuration > > > > > > > >> > > > > > problem. There are different board variants with > > > > different > > > > > > > >> > > > > > hardware > > > > > > > >> > > > > > layout. u-boot has code for it, but our build does > > not > > > > > > account > > > > > > > >> > > > > > for. > > > > > > > >> > > > > > Unless the scripts that build the 11.1 image use a > > > > different > > > > > > > >> > > > > > revision > > > > > > > >> > > > > > of the u-boot port, wouldn't it just use the current > > > > 2017.7 > > > > > > > >> base? > > > > > > > >> > > > > > > > > > > > > >> > > > > > I'm trying to figure out how to generate a u-boot > > with > > > > the > > > > > > > >> > > > > > correct > > > > > > > >> > > > > > SPL > > > > > > > >> > > > > > portion of u-boot. One could pull the SolidRun > > u-boot > > > > repo, > > > > > > or > > > > > > > >> go > > > > > > > >> > > > > > find > > > > > > > >> > > > > > the ports commit before the changeover and see if > > we can > > > > > > > >> generate > > > > > > > >> > > > > > the > > > > > > > >> > > > > > correct SPL. > > > > > > > >> > > > > > > > > > > > > >> > > > > > I looked at Mainline u-boot and there is a board > > > > directory > > > > > > for > > > > > > > >> > > > > > solid > > > > > > > >> > > > > > run. > > > > > > > >> > > > > > https://github.com/u-boot/u-boot/blob/master/board/ > > > > > > solidrun/ > > > > > > > >> mx6cu > > > > > > > >> > > > > > boxi > > > > > > > >> > > > > > /mx6cuboxi.c > > > > > > > >> > > > > > seems to support multiple memory configurations > > based on > > > > > > > >> defines, > > > > > > > >> > > > > > so > > > > > > > >> > > > > > this should just be a configuration problem. > > > > > > > >> > > > > > > > > > > > > >> > > > > > We clearly need to start supporting the lower spec'd > > > > > > SolidRun > > > > > > > >> > > > > > boards > > > > > > > >> > > > > > because this has come up a couple of times now > > since the > > > > > > > >> > > > > > changeover. > > > > > > > >> > > > > > It should be just a matter of creating a port that > > does > > > > the > > > > > > same > > > > > > > >> > > > > > thing > > > > > > > >> > > > > > but generates the correct SPL file? My SOM is a > > i2eX so > > > > I > > > > > > can't > > > > > > > >> > > > > > be > > > > > > > >> > > > > > too > > > > > > > >> > > > > > much help (and I've also over volunteered myself!). > > > > > > > >> > > > > > > > > > > > > >> > > > > > Russ > > > > > > > >> > > > > > > > > > > > > >> > > > > The old imx6 uboot ports generated a single copy of > > uboot > > > > that > > > > > > > >> > > > > would > > > > > > > >> > > > > boot dual and quad-core versions of both hummingboard > > and > > > > > > cubox > > > > > > > >> > > > > systems. If the new uboot works only on quad core, > > that's > > > > > > another > > > > > > > >> > > > > regression. It might be possible to extract the > > > > u-boot.imx > > > > > > file > > > > > > > >> > > > > from a > > > > > > > >> > > > > freebsd 10 image to get back to the old one. > > > > > > > >> > > > > > > > > > > > >> > > > > Ooops. Except it appears those no longer exist. > > > > > > > >> > > > > > > > > > > >> > > > Is this a loss of functionality when the changes were > > > > > > upstreamed? Is > > > > > > > >> > > > it a > > > > > > > >> > > > bad configuration on our part? Any idea what might be > > going > > > > on > > > > > > or > > > > > > > >> how > > > > > > > >> > > > to > > > > > > > >> > > > fix it? > > > > > > > >> > > > > > > > > > >> > > The vendor uboot worked well. The generic mainline, > > > > apparently > > > > > > not so > > > > > > > >> > > much. It may indicate that the vendor didn't upstream > > > > > > everything. I > > > > > > > >> > > haven't worked much with the new imx6 uboot packages > > because > > > > for > > > > > > me > > > > > > > >> > > they're completely unusable because they lack support for > > > > > > netbooting. > > > > > > > >> > > (If you feel tempted to say something about efi and > > > > netbooting, > > > > > > > >> please > > > > > > > >> > > provide links to how-to documentation at the very least, > > and > > > > an > > > > > > > >> example > > > > > > > >> > > that works for armv6 would be even better.) > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > I didn't think that we were enabling EFI + armv6 on anything > > > > yet by > > > > > > > >> > default... > > > > > > > >> > > > > > > > > >> > Can't help you there. > > > > > > > >> > > > > > > > > >> > Warner > > > > > > > >> > > > > > > > >> We do, EFI is enabled by default in U-Boot on most of the > > boards. > > > > > > > > > > > > > > > > > > > > > > > > And GENERIC actually supports that? > > > > > > > > > > > > > > > > > > > > > > And more importantly, we have the right tooling to build the > > right > > > > images > > > > > > > for EFI booting? > > > > > > > > > > > > > > Warner > > > > > > > > > > > > GENERIC supports that and boot1.efi/loader.efi built for arm is > > > > > > correctly built. > > > > > > > > > > > > > > > And -stable kernels boot with this setup as well? Or is this not > > default > > > > > for ports-built u-boot? > > > > > > > > > > And the tooling goes well beyond just boot1.efi, and includes things > > like > > > > > making sure the release images work correctly. And EFI support is > > about > > > > to > > > > > start requiring efirt working (well, efibootmgr is coming soon) to > > manage > > > > > booting, at least on x86. What's the story for arm? > > > > > > > > > > Warner > > > > > > > > You can take the release image for BBB for example, put boot1.efi > > > > as /EFI/boot/bootarm.efi in the MSDOS partition and it will work (I > > > > don't remember right now if you need U-Boot to load the DTB or not but > > > > it's just a matter or puting the DTB in the MSDOS as well under / > > > > or /DTB). > > > > > > > > > Do they work w/o doing that? > > > > > > Warner > > > > Without doing what ? The release script don't put boot1.efi on the > > msdos partition. If we do it, it will have a higher priority than > > loading ubldr. We should do it at one point, but not now. > > > Sorry, I mean 'will we boot with the old, crappy u-boot ABI interface to > /boot/loader and have a kernel boot'. Sounds like the answer is 'that still > works, don't worry'. > > Warner Oh yes sure, with the same U-Boot and kernel you can either use ubldr or boot1.efi (or loader.efi if you netboot). -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Sep 27 12:31:05 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2C0FE02C1A for ; Wed, 27 Sep 2017 12:31:05 +0000 (UTC) (envelope-from noname.esst@yahoo.com) Received: from sonic315-35.consmr.mail.gq1.yahoo.com (sonic315-35.consmr.mail.gq1.yahoo.com [98.137.65.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CFB1470FA2 for ; Wed, 27 Sep 2017 12:31:05 +0000 (UTC) (envelope-from noname.esst@yahoo.com) X-YMail-OSG: 6d6k3goVM1k9KeDpGpEGK4dqMlEiW3H0XU_PQ2GaOLsGoVU9c3HjyDA26hTRRwd FAzMR724hEsw9gy0ZCJabH1CAB3DnXXpOphyfECLP4MTz7NNh7_VyrOspBFQD8Aszmwn7yyA3Xbn MBBRuc0NU8BwohNthcNh0k0yoLApmXKHpUUAQlRKp6r6KayaH4w9MOB.7E3FKxPMpXqIE6CUs_MW jrZEITyyz0Qo1z_drBXyUMuaFB7B9Q1e5vuBtidFu1i.LbwLXRgJIpIsiFnabIr7TBtkJOD5hfA4 U_ysMJ_I3TIpuFS_LpuiW.2HcSvmMfXyZcLgdD6kGAdTDy1wMF6L5V6TisLJ8bRjwOkSAt0sQnbu 6SkPNYcvV3hJyjEv.yhAtPA4_FW2Wwr7GvBQxBahWxdYKR9kyHjgsgq9SG2WnpQ0LhEDQojo7VI8 xoKctCExLkgifvpRqTyvWkfYnV7D_BsnpF9gp.1cbXpn4C5kgAUV6dJiqurZB4rYicg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Wed, 27 Sep 2017 12:31:04 +0000 Date: Wed, 27 Sep 2017 11:26:00 +0000 (UTC) From: Nomad Esst Reply-To: Nomad Esst To: "freebsd-arm@freebsd.org" Message-ID: <312104517.10213240.1506511560284@mail.yahoo.com> Subject: FreeBSD 11 on Banana-Pi M3 A83t MIME-Version: 1.0 References: <312104517.10213240.1506511560284.ref@mail.yahoo.com> X-Mailer: WebService/1.1.10521 YahooMailNeo Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 12:31:06 -0000 Hello allI have created an image using Crochet build tool for my BPi M3 board. I have burnt it on it's on-board 4GB EMMC. When I try to boot the board, I get the following error: U-Boot SPL 2016.05 (Aug 13 2017 - 05:07:01)DRAM: 2048 MiBCard did not respond to voltage select!Could not determine boot source resetting ... What should I do? Thanks in advance. From owner-freebsd-arm@freebsd.org Wed Sep 27 14:06:03 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54D79E04F01 for ; Wed, 27 Sep 2017 14:06:03 +0000 (UTC) (envelope-from russ.haley@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 A166D745A9 for ; Wed, 27 Sep 2017 14:06:02 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-wr0-x22b.google.com with SMTP id g29so16686662wrg.11 for ; Wed, 27 Sep 2017 07:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Taa7dVXPjaviexVPXQFkJ9i7KSS4Wu+DYDRqBJHPbMc=; b=Qenq8f/g3eppFqh+ETFx4ZWQJDO2C0TG7Yln6zAftgykIaKN5ekPz5dyQr8lFk3WJA 7SdyGVrS8evhv4IjOQlXm5ML7onXkypf8zz0wiYgMwAWHztPZINBVFyOypy9m3DKjMfd 8GD6HiQt441IbyFNyTu9qknlYkCZCPUc/4gBcJqUE4ksnyUAN+EvVL/iXHn8D2CJV5Jf 4ySS3YL4Nx9BE6YVDdoYtVqqMuPtAlG9/fNP3CB42cDotqV0RVXTLxhmwIQQl0jZiqF5 bK0b7V3ogzjwB0TFjxqqzlZnVHgfB+IDjBRxsNi6x+ekTLxjs4YbVCXTLU8zOUxYxsOR rk1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Taa7dVXPjaviexVPXQFkJ9i7KSS4Wu+DYDRqBJHPbMc=; b=UqOJ58gSVGscC2e5i5X32IB+KQtN7Pki4tXSkH5VDMi36IfjC6AaOyuEe+bnkGqMaR JvPS9oJFZxGkwyv0tkKgm1ofRRuLgTLjldpRQbEvBbqYoMa+L3mFtF9PDeObw2r2W+B8 +OcoMYoZleu1sbdIcvPeKeg9dF1BIujUsm9Kv3LvVMUXWPcqqFvw/EVsLlxaJVPkhHVM 43lSGk3BifmZIH3fklC905eAph5doLI8hWZyUniw+pIDiE2xxm1oRtnR0Rr0B1bBzrDi ApCdLZFdRzaejkM48v/cIgDWd2L026bK5GdCKTm1+nFxuqW+/gh7lVWRYmhI9XTVcQym o7jA== X-Gm-Message-State: AHPjjUjt4SdKNKr1FI8sxIH8cXk+zIa7ruFszKeRtzCY/aLmxMdW6TB6 JOqLHdQngw0rko4VluEQJqbHKRxmHqPvX2klp+ALig== X-Google-Smtp-Source: AOwi7QDuKKElwEhwLn2qjJ1CneeJyjWnmpjW/tHEriE1R/9DYoLTxER5z4Rbt1OwrjrEN6JDIDvP2qXGy5c0lhZaCfo= X-Received: by 10.46.9.150 with SMTP id 144mr729012ljj.30.1506521160822; Wed, 27 Sep 2017 07:06:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Wed, 27 Sep 2017 07:06:00 -0700 (PDT) From: Russell Haley Date: Wed, 27 Sep 2017 07:06:00 -0700 Message-ID: Subject: Unplugged Ethernet Interface listed as RUNNING To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 14:06:03 -0000 Hi, I'm poking at stuff on my Hummingboard. I was using my wired interface ffec0 and then switched over to my wifi stick. After unplugging the etherent cable, ifconfig still lists the ffec0 interface as UP and RUNNING still has an ip address even though it was assigned via dhcp. This was consistent over multiple attempts with and without the wifi stick invovled. The status indication correctly shows no carrier when the ethernet is unplugged. I did a comparison to my BBB running Debian Jessie and when the ethernet cable is removed, the interface is still listed as UP but not as RUNNING (although there is no status indication in Linux). My question: Should FreeBSD be showing the ffec0 interface as RUNNING even though there is no cable plugged in? Should the DHCP aquired ip address be removed from the ifconfig listing when the ethernet cable is unplugged? Thanks Russ root@imx6:~ # ifconfig ffec0: flags=8843 metric 0 mtu 1500 options=80008 ether d0:63:b4:00:8f:19 hwaddr d0:63:b4:00:8f:19 inet 192.168.2.2 netmask 0xffffff00 broadcast 192.168.2.255 media: Ethernet autoselect (none) status: no carrier nd6 options=29 lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21 wlan0: flags=8843 metric 0 mtu 1500 ether 60:a4:4c:ec:c9:a5 hwaddr 60:a4:4c:ec:c9:a5 inet 192.168.2.62 netmask 0xffffff00 broadcast 192.168.2.255 groups: wlan ssid Haleys_DownStairs channel 8 (2447 MHz 11g) bssid ac:9e:17:67:85:90 regdomain FCC country US authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 60 protmode CTS wme roaming MANUAL media: IEEE 802.11 Wireless Ethernet DS/1Mbps mode 11g status: associated nd6 options=29 root@imx6:~ # cat /etc/rc.conf hostname="imx6" ifconfig_DEFAULT="DHCP" wlans_run0="wlan0" ifconfig_wlan0="WPA SYNCDHCP" sshd_enable="YES" sendmail_enable="NONE" sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO" growfs_enable="YES" From owner-freebsd-arm@freebsd.org Wed Sep 27 14:18:34 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72492E051CE for ; Wed, 27 Sep 2017 14:18:34 +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 D819D749C8 for ; Wed, 27 Sep 2017 14:18:32 +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 d5dfd954; Wed, 27 Sep 2017 16:18:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=PXNYl5wViFg3dho/h9FaxWgQexc=; b=e7jHfho3n0d995Lej18gJQvcI7Zt oRUzME6LQ495F4qUpS4E2EN1dPIiqxKu+/hrsLz0YnN00J1co5A3dtPSeVNRa4US 9pWkf2NhiTII25g0UWSPqLAh8bo7vEVuHUFUJqBD652bBWOG6XpeHN12CV0ucSX2 ydNq45IlP4Mjk54= 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=htBPOIE4Oah7TNhAd6oFDWbAWMy7REMAx7+PPhtwiHBcbedkPdHxXL/U svq5mjWNxLikcBdf3LI1b/jZaxLInUvnAqr5yQbyPLvr7x2cZXku5vGo/K8w+PCA cGS1HaGHTjvIFYieLrkuG7HbcfjPnV3eUZEZsPAyLuj8ap9e3vg= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 759ae2fe TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 27 Sep 2017 16:18:20 +0200 (CEST) Date: Wed, 27 Sep 2017 16:18:19 +0200 From: Emmanuel Vadot To: Nomad Esst Cc: Nomad Esst via freebsd-arm Subject: Re: FreeBSD 11 on Banana-Pi M3 A83t Message-Id: <20170927161819.6e36cd53a76f9e75b782a3b3@bidouilliste.com> In-Reply-To: <312104517.10213240.1506511560284@mail.yahoo.com> References: <312104517.10213240.1506511560284.ref@mail.yahoo.com> <312104517.10213240.1506511560284@mail.yahoo.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 14:18:34 -0000 On Wed, 27 Sep 2017 11:26:00 +0000 (UTC) Nomad Esst via freebsd-arm wrote: > Hello allI have created an image using Crochet build tool for my BPi M3 board. I have burnt it on it's on-board 4GB EMMC. When I try to boot the board, I get the following error: > > U-Boot SPL 2016.05 (Aug 13 2017 - 05:07:01)DRAM: 2048 MiBCard did not respond to voltage select!Could not determine boot source > resetting ... > What should I do? > Thanks in advance. Our U-Boot is probably not recent enough to support the eMMC. A83T support is not really great even in Linux or U-Boot. You could try updating u-boot to use the u-boot-master port (which curently track the 2017.07 version of U-Boot). -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Sep 27 15:00:29 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CD61E063CB for ; Wed, 27 Sep 2017 15:00:29 +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 2CB4E762B9 for ; Wed, 27 Sep 2017 15:00:28 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 8cc51870-a394-11e7-b50b-53dc5ecda239 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 8cc51870-a394-11e7-b50b-53dc5ecda239; Wed, 27 Sep 2017 15:00:07 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8RF0QDI001997; Wed, 27 Sep 2017 09:00:26 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506524426.73082.182.camel@freebsd.org> Subject: Re: CUBOX snapshots working? From: Ian Lepore To: Emmanuel Vadot Cc: freebsd-arm Date: Wed, 27 Sep 2017 09:00:26 -0600 In-Reply-To: <20170927112413.4fc048082df75f51a4b71eea@bidouilliste.com> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> <20170927112413.4fc048082df75f51a4b71eea@bidouilliste.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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 15:00:29 -0000 On Wed, 2017-09-27 at 11:24 +0200, Emmanuel Vadot wrote: > On Tue, 26 Sep 2017 16:55:28 -0600 > Ian Lepore wrote: > > > > > [...] > > haven't worked much with the new imx6 uboot packages because for me > > they're completely unusable because they lack support for netbooting. > >  (If you feel tempted to say something about efi and netbooting, please > > provide links to how-to documentation at the very least, and an example > > that works for armv6 would be even better.) > > > > -- Ian >  Just set 'filename' to loader.efi in dhcpd.conf (if you use isc-dhcpd) > and have it served by tftpd. >  In U-boot : > >  $ env set boot_targets=dhcp (default is different for each board but > will look like "mmc0 dhcp usb") >  $ env save (if you want it by default) >  $ boot > >  This will make u-boot do dhcp request, tftp load the DTB (so > have it in your tftpd directory), loader.efi and run it. > What if I don't have control over the dhcp server config, how can I locally configure what file to load? What if I'm running nfs, but not a tftp server? Where does loader.efi load the kernel and modules from?  How do I control / change that? The configuration I prefer is that loader(8) comes from local storage (sdcard, whatever), and it loads the kernel, the dtb, and modules, via nfs.  I don't want uboot doing anything on the network itself.  How do I configure that? -- Ian From owner-freebsd-arm@freebsd.org Wed Sep 27 15:13:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99A5CE06B56 for ; Wed, 27 Sep 2017 15:13:06 +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 D441876ED2; Wed, 27 Sep 2017 15:13: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 fbdbc5be; Wed, 27 Sep 2017 17:13:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=7RStbFT4iu/ac88SOhxI8IAEXpw=; b=LNOQnituXb0pwbTaGiJHGdnbbw8Q uB1ZJXPqN1Fb+Navuf9UxXG8953sbOSw2rtdBYKIbI5YYcHWaYBlt2jSFetk1u0c l2ATK+vthlioxj5FKUiFJLbjt7/ufiNArAMBGXLUOcBhHWthDu2hgeUcdAZnGHDN ey1CtB+TUjEAEJE= 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=IiHxGZ65zF+XT7+VBtH/z9p0FmoJ8TmKF3RRoIwI2SgcrOa/050T80k2 VRKcajKxh6QfhYZsQw9Wv/hkdCOuOcKTyOs39L0xtMjvlnvoUZVmhJ7Bp3ecZpP8 /Afcjyp1cHz6FvaYbDem7x6dOKpOsSy4YmfbjuoLf7A5iM1o4zU= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id de40e82b TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 27 Sep 2017 17:13:02 +0200 (CEST) Date: Wed, 27 Sep 2017 17:13:01 +0200 From: Emmanuel Vadot To: Ian Lepore Cc: freebsd-arm Subject: Re: CUBOX snapshots working? Message-Id: <20170927171301.8cbf838f481c980d1c5f309a@bidouilliste.com> In-Reply-To: <1506524426.73082.182.camel@freebsd.org> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> <20170927112413.4fc048082df75f51a4b71eea@bidouilliste.com> <1506524426.73082.182.camel@freebsd.org> X-Mailer: Sylpheed 3.5.1 (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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 15:13:06 -0000 On Wed, 27 Sep 2017 09:00:26 -0600 Ian Lepore wrote: > On Wed, 2017-09-27 at 11:24 +0200, Emmanuel Vadot wrote: > > On Tue, 26 Sep 2017 16:55:28 -0600 > > Ian Lepore wrote: > >=20 > > >=20 > > > [...] > > > haven't worked much with the new imx6 uboot packages because for me > > > they're completely unusable because they lack support for netbooting. > > > =A0(If you feel tempted to say something about efi and netbooting, pl= ease > > > provide links to how-to documentation at the very least, and an examp= le > > > that works for armv6 would be even better.) > > >=20 > > > -- Ian > > =A0Just set 'filename' to loader.efi in dhcpd.conf (if you use isc-dhcp= d) > > and have it served by tftpd. > > =A0In U-boot : > >=20 > > =A0$ env set boot_targets=3Ddhcp (default is different for each board b= ut > > will look like "mmc0 dhcp usb") > > =A0$ env save (if you want it by default) > > =A0$ boot > >=20 > > =A0This will make u-boot do dhcp request, tftp load the DTB (so > > have it in your tftpd directory), loader.efi and run it. > >=20 >=20 > What if I don't have control over the dhcp server config, how can I > locally configure what file to load? From U-Boot: $ dhcp $ tftp $kernel_addr_r Or something like that, run 'tftp help' or 'help tftp' I never recall. > What if I'm running nfs, but not a tftp server? I don't know if in loader.efi you can use the ip stack from the EFI firmware without doing tftp/bootp If you can just set the variable in loader.efi and it should work. > Where does loader.efi load the kernel and modules from? =A0How do I > control / change that? from the loaddev variable iirc > The configuration I prefer is that loader(8) comes from local storage > (sdcard, whatever), and it loads the kernel, the dtb, and modules, via > nfs. =A0I don't want uboot doing anything on the network itself. =A0How do > I configure that? You can try setting the loaddev to net under loader.efi The main reason to use efi is that we have (in theory) the same support as on amd64. Maybe some of your scenario can't work ATM I don't know, best way is to try. --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Sep 27 15:26:04 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11262E071B8 for ; Wed, 27 Sep 2017 15:26:04 +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 E41AD776BB for ; Wed, 27 Sep 2017 15:26:03 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 1f3da98c-a398-11e7-b50b-53dc5ecda239 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 1f3da98c-a398-11e7-b50b-53dc5ecda239; Wed, 27 Sep 2017 15:25:41 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8RFQ0F3002043; Wed, 27 Sep 2017 09:26:00 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506525960.31939.3.camel@freebsd.org> Subject: Re: CUBOX snapshots working? From: Ian Lepore To: Emmanuel Vadot Cc: freebsd-arm Date: Wed, 27 Sep 2017 09:26:00 -0600 In-Reply-To: <20170927171301.8cbf838f481c980d1c5f309a@bidouilliste.com> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> <20170927112413.4fc048082df75f51a4b71eea@bidouilliste.com> <1506524426.73082.182.camel@freebsd.org> <20170927171301.8cbf838f481c980d1c5f309a@bidouilliste.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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 15:26:04 -0000 On Wed, 2017-09-27 at 17:13 +0200, Emmanuel Vadot wrote: > > > On Wed, 27 Sep 2017 09:00:26 -0600 > Ian Lepore wrote: > > > > > On Wed, 2017-09-27 at 11:24 +0200, Emmanuel Vadot wrote: > > > > > > On Tue, 26 Sep 2017 16:55:28 -0600 > > > Ian Lepore wrote: > > > > > > > > > > > > > > > [...] > > > > haven't worked much with the new imx6 uboot packages because > > > > for me > > > > they're completely unusable because they lack support for > > > > netbooting. > > > >  (If you feel tempted to say something about efi and > > > > netbooting, please > > > > provide links to how-to documentation at the very least, and an > > > > example > > > > that works for armv6 would be even better.) > > > > > > > > -- Ian > > >  Just set 'filename' to loader.efi in dhcpd.conf (if you use isc- > > > dhcpd) > > > and have it served by tftpd. > > >  In U-boot : > > > > > >  $ env set boot_targets=dhcp (default is different for each board > > > but > > > will look like "mmc0 dhcp usb") > > >  $ env save (if you want it by default) > > >  $ boot > > > > > >  This will make u-boot do dhcp request, tftp load the DTB (so > > > have it in your tftpd directory), loader.efi and run it. > > > > > What if I don't have control over the dhcp server config, how can I > > locally configure what file to load? >  From U-Boot: >  $ dhcp >  $ tftp $kernel_addr_r > >  Or something like that, run 'tftp help' or 'help tftp' I never > recall. > > > > > What if I'm running nfs, but not a tftp server? >  I don't know if in loader.efi you can use the ip stack from the EFI > firmware without doing tftp/bootp tftp and bootp have nothing to do with each other. A common situation for people is that an IP address is available via dhcp or bootp, but they have no control over other boot parms delivered along with the basic IP info.  In some cases that other info (rootpath, filename, etc) is present but wildly wrong and must be ignored.  There needs to be a way to locally override such info and specify the tftp or nfs server and path locally. -- Ian >  If you can just set the variable in loader.efi and it should work. > > > Where does loader.efi load the kernel and modules from?  How do I > > control / change that? >  from the loaddev variable iirc > > > > > The configuration I prefer is that loader(8) comes from local > > storage > > (sdcard, whatever), and it loads the kernel, the dtb, and modules, > > via > > nfs.  I don't want uboot doing anything on the network itself.  How > > do > > I configure that? >  You can try setting the loaddev to net under loader.efi > >  The main reason to use efi is that we have (in theory) the same > support as on amd64. >  Maybe some of your scenario can't work ATM I don't know, best way is > to try. > From owner-freebsd-arm@freebsd.org Wed Sep 27 15:43:58 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 038DDE07932 for ; Wed, 27 Sep 2017 15:43:58 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC7547C4A4 for ; Wed, 27 Sep 2017 15:43:57 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: adbb7414-a39a-11e7-a937-4f970e858fdb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id adbb7414-a39a-11e7-a937-4f970e858fdb; Wed, 27 Sep 2017 15:43:59 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8RFhspL002110; Wed, 27 Sep 2017 09:43:54 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506527034.31939.8.camel@freebsd.org> Subject: Re: Unplugged Ethernet Interface listed as RUNNING From: Ian Lepore To: Russell Haley , freebsd-arm Date: Wed, 27 Sep 2017 09:43:54 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 15:43:58 -0000 On Wed, 2017-09-27 at 07:06 -0700, Russell Haley wrote: > Hi, > > I'm poking at stuff on my Hummingboard. I was using my wired > interface > ffec0 and then switched over to my wifi stick. After unplugging the > etherent cable, ifconfig still lists the ffec0 interface as UP and > RUNNING still has an ip address even though it was assigned via dhcp. > This was consistent over multiple attempts with and without the wifi > stick invovled. The status indication correctly shows no carrier when > the ethernet is unplugged. > > I did a comparison to my BBB running Debian Jessie and when the > ethernet cable is removed, the interface is still listed as UP but > not > as RUNNING (although there is no status indication in Linux). > > My question: Should FreeBSD be showing the ffec0 interface as RUNNING > even though there is no cable plugged in? Should the DHCP aquired ip > address be removed from the ifconfig listing when the ethernet cable > is unplugged? > The re0 and re1 interfaces on my x86 desktop system behave the same way; I think all of that is normal.  In freebsd, the RUNNING flag is commented in the header file as "[driver] resources allocated". You definitely wouldn't want the interface to lose its IP address just because the connection is down, that could lead to all your open tcp connections dying because of a momentary loss of carrier. -- Ian > Thanks > > Russ > > root@imx6:~ # ifconfig > ffec0: flags=8843 metric 0 > mtu 1500 >         options=80008 >         ether d0:63:b4:00:8f:19 >         hwaddr d0:63:b4:00:8f:19 >         inet 192.168.2.2 netmask 0xffffff00 broadcast 192.168.2.255 >         media: Ethernet autoselect (none) >         status: no carrier >         nd6 options=29 > lo0: flags=8049 metric 0 mtu 16384 >         options=600003 >         inet6 ::1 prefixlen 128 >         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >         inet 127.0.0.1 netmask 0xff000000 >         groups: lo >         nd6 options=21 > wlan0: flags=8843 metric 0 > mtu 1500 >         ether 60:a4:4c:ec:c9:a5 >         hwaddr 60:a4:4c:ec:c9:a5 >         inet 192.168.2.62 netmask 0xffffff00 broadcast 192.168.2.255 >         groups: wlan >         ssid Haleys_DownStairs channel 8 (2447 MHz 11g) bssid > ac:9e:17:67:85:90 >         regdomain FCC country US authmode WPA2/802.11i privacy ON >         deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid > 60 >         protmode CTS wme roaming MANUAL >         media: IEEE 802.11 Wireless Ethernet DS/1Mbps mode 11g >         status: associated >         nd6 options=29 > > > root@imx6:~ # cat /etc/rc.conf > hostname="imx6" > ifconfig_DEFAULT="DHCP" > wlans_run0="wlan0" > ifconfig_wlan0="WPA SYNCDHCP" > sshd_enable="YES" > sendmail_enable="NONE" > sendmail_submit_enable="NO" > sendmail_outbound_enable="NO" > sendmail_msp_queue_enable="NO" > growfs_enable="YES" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org > " From owner-freebsd-arm@freebsd.org Wed Sep 27 21:50:10 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8458E10497 for ; Wed, 27 Sep 2017 21:50:10 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 882EC3586 for ; Wed, 27 Sep 2017 21:50:10 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id r136so337141wmf.2 for ; Wed, 27 Sep 2017 14:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=HNPp7EiopwxzzbLvxKdVLuAIVDTgWMLCcHnwq6jZ/lc=; b=vOA39duFisTRnMHIjMlafjtZvwx5yHfQHm56WJcklTJoeIkBqkAB8bxmmLJWcRIS51 IchoH4aMsUccCf7RYJK3WxP6ir7tXCeNsK8j9LC+vGckU1vCkEbZNjXt9/K69zFLqg4D zOEDVr9DTOs2uoVPWVP2TQJbJoxE3PW4+v+kuMQSpnu5D464RR+snsedEkRkew0tRrkt FQIZ5eI5o39tIiHipi9t7sp3FrtL5/EdqWudXbj3M2UHYpfk2lFNQgjqf7rruEb7K92c F0v07R0rnHuW8RzfFzVZVYoaG96ClVMcrH1nDeemuobhZy6hSNqA9ia5CVqZKPMlN6EL v99w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HNPp7EiopwxzzbLvxKdVLuAIVDTgWMLCcHnwq6jZ/lc=; b=khIaE5MBxzMiLEvu8qcTfPfAjiyGKWh13usaaADH1q7dkyqhgDW2yVnXg6XZCl7twx ue6ndnUqUGwLaxh8NYIh4JcpMCiBoShYFjRPHBoeGoTj9reqU+8HEuvNBZwZTroRJMPd 3vQUu4/OOHCBvpSRcMGJZhs5eIHJMcl2t7zFWSFjP0LEJxWseh65JGYpvCo1FUV2zGV7 T3ZyRWO7tDPDqrWDLC9EuA2iCOwcbPT2WxaCuKqRk/hVYgSsVvk8xwx7S0kUwzxFuXTt 3FXN+dRwrNNwqpsMP3zt+4SFPrq4MRzp46K11ble1urlbR4GLWPqmtIpHZCi3wMQM60N oKAg== X-Gm-Message-State: AHPjjUiewBq/EGvPLoj195lfmmRW9vtsm5+BlsQuepAUTR8x+427ZCMp aJqQMXZ4Njg/c6fD2MxM5pPZLfp0BB7K3MYiX414uA== X-Google-Smtp-Source: AOwi7QDoCx6RL0e4UcSW6hWxVbMFjvurdSH1gI2E2PcdKfAmUgcZuNuv83PqHondO2rwvVvfK7FVINVGVPnGIXG0cnc= X-Received: by 10.28.210.5 with SMTP id j5mr1326280wmg.15.1506549008590; Wed, 27 Sep 2017 14:50:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.238.142 with HTTP; Wed, 27 Sep 2017 14:50:07 -0700 (PDT) From: Guy Yur Date: Thu, 28 Sep 2017 00:50:07 +0300 Message-ID: Subject: if_awg fixes To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 21:50:11 -0000 Hi, I had issues with if_awg when passing heavy traffic (transmission, samba, ...) a. The tx hardware checksum stopped working after a while. IPv4 packets were sent with IP and TCP/UDO checksum fields unmodified. so the packets were rejected by the receiving host. IPv4 checksum was 0 and TCP/UDP checksum only pseudo header. IPv6 packets were fine since the card doesn't do offload for ipv6. b. mbuf leaks. "current" mbuf clusters count kept rising in "netstat -m" for some traffic types and never went down until eventually reaching max. Comparing the driver against if_nfe which also uses a ring buffer, there are several issues with how the rings are programmed. I made changes inspired by it. The following fixes improved the card behavior on my boards. (tested on Orange Pi PC and Orange Pi One) 1. https://github.com/guyyur/freebsd-src_patches/blob/master/if_awg_fixes_1_reg_offsets.patch Wrong register offsets for the tx_dma status regs. Registers are currently only used when dumping them (AWG_DEBUG defined and doing soft reset). 2. https://github.com/guyyur/freebsd-src_patches/blob/master/if_awg_fixes_2_fix_txcsum_disabled.patch Fix behavior when txcsum is disabled by turning CSUM_UDP and CSUM_TCP on/off along with CSUM_IP. Only consider IFCAP_TXCSUM to set/unset CSUM_* since the flags are only checked in tx path. IFCAP_RXCSUM is checked in rx path. CSUM_IP is independent from CSUM_UDP and CSUM_TCP. If only CSUM_IP is turned off but CSUM_UDP and CSUM_TCP are set the card will not compute the checksum but the OS expects the tcp/udp field to be hw computed. 3. https://github.com/guyyur/freebsd-src_patches/blob/master/if_awg_fixes_3_fix_tx_path.patch Fix tx programming when there are multiple segments. a. Set TX_DESC_CTL on the first descriptor only after all the other descriptors have been programmed. This will prevent the card from advancing on the first descriptor while the other descriptors are still being written. b. Put the mbuf and map for release on the last segment. The map from the first segment is used so swap it with the last. The data sheet mentions the descriptors are marked as done only after the frame is transmitted so it might be fine to keep the map and mbuf in the first segment but it doesn't hurt to keep it in the last. c. if m_collapse fails, release the buffer instead of enqueuing it again where it will keep failing. 4. https://github.com/guyyur/freebsd-src_patches/blob/master/if_awg_fixes_4_rx_avoid_holes.patch Avoid hole in the rx ring by keeping a spare dma map. If new mbuf allocation or dma mapping fails, just reuse the existing mbuf and increase the drop counter. Only try to allocate a new buffer if len of packet > 0. If there were errors or just an empty packet, reuse the buffer. 5. https://github.com/guyyur/freebsd-src_patches/blob/master/if_awg_fixes_5_cleanup_buffers_on_stop.patch Cleanup tx and rx buffers on card stop. ifconfig ... down ifconfig ... up tx and rx indices are advanced to where the card expects the next buffer. I don't see a way to reset the dma_cur_desc regs mentioned in the data sheet. Thanks, Guy From owner-freebsd-arm@freebsd.org Wed Sep 27 23:05:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D95BCE129DA for ; Wed, 27 Sep 2017 23:05:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-77.reflexion.net [208.70.210.77]) (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 84B8F646CA for ; Wed, 27 Sep 2017 23:05:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7365 invoked from network); 27 Sep 2017 23:05:09 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Sep 2017 23:05:09 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Wed, 27 Sep 2017 19:05:09 -0400 (EDT) Received: (qmail 26334 invoked from network); 27 Sep 2017 23:05:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Sep 2017 23:05:09 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B5761EC94EE for ; Wed, 27 Sep 2017 16:05:08 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: buildkernel for armv6 -r324071 (for example): "warning: multiple common of `ahci_devclass'"; more for armv7 Message-Id: Date: Wed, 27 Sep 2017 16:05:07 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 23:05:12 -0000 This was a non-debug kernel build via an amd64 -> armv6 (-mcpu=3Dcortex-a7) build: --- kernel.full --- linking kernel.full imx6_ahci.o: warning: multiple common of `ahci_devclass' ahci_pci.o: warning: previous common is here ctfmerge -L VERSION -g -o kernel.full ... text data bss dec hex filename 8177284 466951 1572864 10217099 0x9be68b kernel.full imx6_ahci.o: warning: multiple common of `ahci_devclass' ahci_pci.o: warning: previous common is here Building = /usr/obj/armv7_clang/arm.armv6/usr/src/sys/GENERIC-NODBG/kernel.debug Building /usr/obj/armv7_clang/arm.armv6/usr/src/sys/GENERIC-NODBG/kernel I do not remember seeing this before. As a side note for armv7 I happened to notice the messages: /usr/src/sys/arm/arm/cpufunc_asm.S:167:2: warning: deprecated since v7, = use 'dsb' mcr p15, 0, r0, c7, c10, 4 ^ /usr/src/sys/arm/arm/cpufunc_asm.S:172:2: warning: deprecated since v7, = use 'dsb' mcr p15, 0, r0, c7, c10, 4 ^ /usr/src/sys/arm/arm/cpufunc_asm.S:175:2: warning: deprecated since v7, = use 'dsb' mcr p15, 0, r0, c7, c10, 4 ^ =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Sep 28 01:11:26 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24F44E205B4 for ; Thu, 28 Sep 2017 01:11:26 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::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 E008C681E2 for ; Thu, 28 Sep 2017 01:11:25 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dxNMP-000Cj5-3i; Thu, 28 Sep 2017 03:11:29 +0200 Date: Thu, 28 Sep 2017 03:11:29 +0200 From: Kurt Jaeger To: Guy Yur Cc: freebsd-arm Subject: Re: if_awg fixes Message-ID: <20170928011129.GC86601@home.opsec.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 01:11:26 -0000 Hi! > I had issues with if_awg when passing heavy traffic > (transmission, samba, ...) [...] > Comparing the driver against if_nfe which also uses a ring buffer, > there are several issues with how the rings are programmed. > I made changes inspired by it. > > The following fixes improved the card behavior on my boards. > (tested on Orange Pi PC and Orange Pi One) Will you submit your patches via https://bugs.freebsd.org ? Otherwise it's difficult to keep track... -- pi@opsec.eu +49 171 3101372 3 years to go ! From owner-freebsd-arm@freebsd.org Thu Sep 28 01:25:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D232E2168C for ; Thu, 28 Sep 2017 01:25:11 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from nov-007-i471.relay.mailchannels.net (nov-007-i471.relay.mailchannels.net [46.232.183.25]) (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 5F17B68B7F for ; Thu, 28 Sep 2017 01:25:08 +0000 (UTC) (envelope-from ian@freebsd.org) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 9604010801B for ; Thu, 28 Sep 2017 01:24:58 +0000 (UTC) Received: from outbound1a.eu.mailhop.org (unknown [100.96.131.244]) (Authenticated sender: duocircle) by relay.mailchannels.net (Postfix) with ESMTPA id 4DC1C1083FF for ; Thu, 28 Sep 2017 01:24:57 +0000 (UTC) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [172.20.63.30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.9.14); Thu, 28 Sep 2017 01:24:58 +0000 X-MC-Relay: Forwarding X-MailChannels-SenderId: _forwarded-from|73.78.92.27 X-MailChannels-Auth-Id: duocircle X-Eight-Gusty: 37a011c44801a96e_1506561897774_1825536864 X-MC-Loop-Signature: 1506561897774:1107074363 X-MC-Ingress-Time: 1506561897774 X-MHO-User: d131be2a-a3eb-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id d131be2a-a3eb-11e7-a893-25625093991c; Thu, 28 Sep 2017 01:24:49 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8S1OknP002943; Wed, 27 Sep 2017 19:24:46 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506561886.31939.16.camel@freebsd.org> Subject: Re: if_awg fixes From: Ian Lepore To: Kurt Jaeger , Guy Yur Cc: freebsd-arm Date: Wed, 27 Sep 2017 19:24:46 -0600 In-Reply-To: <20170928011129.GC86601@home.opsec.eu> References: <20170928011129.GC86601@home.opsec.eu> 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: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 01:25:11 -0000 On Thu, 2017-09-28 at 03:11 +0200, Kurt Jaeger wrote: > Hi! >=20 > >=20 > > I had issues with if_awg when passing heavy traffic > > (transmission, samba, ...) > [...] > >=20 > > Comparing the driver against if_nfe which also uses a ring buffer, > > there are several issues with how the rings are programmed. > > I made changes inspired by it. > >=20 > > The following fixes improved the card behavior on my boards. > > (tested on Orange Pi PC and Orange Pi One) > Will you submit your patches via https://bugs.freebsd.org ? >=20 > Otherwise it's difficult to keep track... >=20 Or as one or more reviews on phabricator, if you're already signed up there. =A0https://reviews.freebsd.org/differential/ -- Ian From owner-freebsd-arm@freebsd.org Thu Sep 28 07:43:07 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90306E2B96B for ; Thu, 28 Sep 2017 07:43:07 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh505-vm1.bullet.mail.kks.yahoo.co.jp (nh505-vm1.bullet.mail.kks.yahoo.co.jp [183.79.57.103]) by mx1.freebsd.org (Postfix) with SMTP id 0E06773E85 for ; Thu, 28 Sep 2017 07:43:06 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.138] by nh505.bullet.mail.kks.yahoo.co.jp with NNFMP; 28 Sep 2017 07:39:46 -0000 Received: from [183.79.100.132] by t501.bullet.mail.kks.yahoo.co.jp with NNFMP; 28 Sep 2017 07:39:45 -0000 Received: from [127.0.0.1] by omp501.mail.kks.yahoo.co.jp with NNFMP; 28 Sep 2017 07:39:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 878931.56296.bm@omp501.mail.kks.yahoo.co.jp Received: (qmail 49642 invoked by uid 60001); 28 Sep 2017 07:39:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1506584385; bh=THItVtCqHMc6RuLbmfY5lBg1vhaijx0X1rpu6c32zPw=; 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=nQSxEwVkJZ8KhfyLf/Ft2M3Hhu6x59Z4g3RxQsYEV+GO83+A282EbVUzlOkXBZHAnbB79w6GV+BgzpI4wvLix0J2/M8EK4iMWQBVT9c72CWQplv/Fxc+U21jmoTz6MOPjGMFE9WsO8f//IOI1tBfk4uytGhULiD0w7YlL4I09+Y= 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=UYE5JuaXimxiODxp4hWWNmEUGScCWf8/637UeddLDdmGfuHOmwRK1FB2WbNJTFWvu6/l9Yz48yjSU4mnzxM/3kVyIvLZfVHJFT/LM0BbRL614LAwskxGAw0U3n8248gx4V2cJmPKbbrgy7/0cbPf1XAO8+685ldYPYUww3VHlh4=; Message-ID: <586157.40149.qm@web101704.mail.ssk.yahoo.co.jp> X-YMail-OSG: ea3dg4kVM1kbQO1kR0mFBhXgYrFHGOFs1AhZsKGA2JOG_q..uB07rTai8Zt6kCdaC5lyNBiYtN88gr7pRIG_gZ_3FF3E48eqqcmdVoQPmN1HVYdWsJx295U24qnXgftUepY2T5jslT3Zfkkou6NyVShByMfvS_fnYSlbgTkaAU1mArpV2rZLIloCl9UEdn0uOgL46Jz7SaqUdsx4lYZyCAybM5zOjyIqsr2mTEv14IOO5FAqic0fJtI_naYJyS6qkpSAGRZn8IHION_KnMWdstiUknnJf0WPlv55BswAaWL7D672Jl2_Q.Ob5SyaZm380HIu0RXDc1O9sIFPLX17riOTrVP_uRZelPZYUs9N9iX0MHMNEBZBzuSbMdgqfBD0OTDwzIrpI_p6_ij2fRm4Vz8yhm3A4UIabdkzENgHS6YcnWI.njysdutaMR31wvNDoI7IxWGkcI5UlN4o_m6vnra8YapffmF5ZDcXVajWDBj0FHi.3Aa3fSKcudBtIRWL42U.yuF4tHCKrBIjXH_C6v_kDllUyCpittBwZkFnD1n59FlMa6m2k8yuoDqdQ4FJDlXbuWHxajxbBmeh6ciWZf6PSWN5Nw_Rd5Rxzb_Pz0nk Received: from [210.20.200.168] by web101704.mail.ssk.yahoo.co.jp via HTTP; Thu, 28 Sep 2017 16:39:45 JST X-Mailer: YahooMailWebService/0.8.111_73 X-YMail-JAS: eCT8REkVM1nz2i_MyMhSdejoRUYZYbttqV..wd0j.YI4ci8R1aVCHXTrqEQXgBuTrq6syflccIWvQBeklmIDLsbNyIYTs.4EKiU1V5L3ecuuAkt449MI1JIsnyAKvHXX2c5e References: <509836.65470.qm@web101704.mail.ssk.yahoo.co.jp> <818825.27559.qm@web101705.mail.ssk.yahoo.co.jp> <323129.32331.qm@web101720.mail.ssk.yahoo.co.jp> <317452.45869.qm@web101717.mail.ssk.yahoo.co.jp> Date: Thu, 28 Sep 2017 16:39:44 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Re: Hang up at boot on armv5t To: Warner Losh , "freebsd-arm@freebsd.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 07:43:07 -0000 Hi=0A=0AI found more hang up commit on armv5t.=A0=0A=0Acommit e7430120e9c80= c0786dc0e9f54e336634932de4c(r323391)=0AAuthor: alc =0ADate= : =A0 Sun Sep 10 17:46:03 2017 +0000=0A=0AThis is more complex commit. How = make workaround on armv5t?=0A=0A=0A----- Original Message -----=0A>From: Wa= rner Losh =0A>To: Mori Hiroki ; Mate= usz Guzik =0A>Cc: "freebsd-arm@freebsd.org" =0A>Date: 2017/9/27, Wed 13:01=0A>Subject: Re: Hang up at boo= t on armv5t=0A> =0A>=0A>Well, you could do something cheezy like #ifndef ar= m :)=0A>=0A>=0A>If you do that in the latest sources, does it solve the pro= blem?=0A>=0A>=0A>diff --git a/sys/sys/systm.h b/sys/sys/systm.h=0A>index dd= ebe0a6843..484784466a3 100644=0A>--- a/sys/sys/systm.h=0A>+++ b/sys/sys/sys= tm.h=0A>@@ -258,12 +258,14 @@ void =A0 =A0 =A0hexdump(const void *ptr, int = length, const char *hdr, int flags);=0A>=A0#define ovbcopy(f, t, l) bcopy((= f), (t), (l))=0A>=A0void =A0 bcopy(const void * _Nonnull from, void * _Nonn= ull to, size_t len);=0A>=A0void =A0 bzero(void * _Nonnull buf, size_t len);= =0A>+#ifndef arm=0A>=A0#define bzero(buf, len) ({ =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \=0A>=A0 =A0 =A0 =A0 if (__builtin_constant= _p(len) && (len) <=3D 64) =A0 \=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __builti= n_memset((buf), 0, (len)); =A0 =A0 =A0\=0A>=A0 =A0 =A0 =A0 else =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0\=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bzero((buf), (len)); =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0\=0A>=A0})=0A>+#endif=0A>=A0void =A0 explicit_bz= ero(void * _Nonnull, size_t);=0A>=0A>=0A>=A0void =A0 *memcpy(void * _Nonnul= l to, const void * _Nonnull from, size_t len);=0A=0AI think "#ifndef=A0__ar= m__" is good rather than "#ifndef arm".=0A=0AThis is good before=A0r323391.= =0A=0A>=0A>=0A>And is this built with gcc or clang? What version?=0A=0AFree= BSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.= 0=0Asvn)=0A=0AHiroki Mori=0A>=0A>=0A>Warner=0A>=0A>=0A>On Tue, Sep 26, 2017= at 9:55 PM, Mori Hiroki wrote:=0A>=0A>Hi.=0A>>=0A>= >I found out hang up problem cause of this commit.=0A>>=0A>>commit 20b4bc44= be9bc985b74f8d5a01a24e 302e2a44ff=0A>>Author: mjg =0A>>Dat= e: =A0 Fri Sep 8 20:09:14 2017 +0000=0A>>=0A>>How to fix these commit ?=0A>= >=0A>>Hiroki Mori=0A>>=0A>>=0A>>----- Original Message -----=0A>>> From: Mo= ri Hiroki =0A>>=0A>>> To: "freebsd-arm@freebsd.org" = =0A>>> Cc:=0A>>> Date: 2017/9/27, Wed 10:42=0A>>> = Subject: Re: Hang up at boot on armv5t=0A>>>=0A>>> Hi.=0A>>>=0A>>> I still = investigate this problem.=0A>>>=0A>>> I found other problem.=0A>>>=0A>>> Th= is commit make panic on armv5t(RT1310).=0A>>>=0A>>> commit 1db0a229476afafe= 06f2bc9749f673 8e6cc6d047=0A>>> Author: markj =0A>>> Dat= e: =A0 Thu Sep 7 21:43:39 2017 +0000=0A>>>=0A>>> https://gist.github.com/ y= amori813/ dc3740085996af505d669446175170 6f=0A>>>=0A>>>=0A>>> Hiroki Mori= =0A>>>=0A>>>=0A>>> ----- Original Message -----=0A>>>>=A0 From: Mori Hiroki= =0A>>>>=A0 To: Warner Losh =0A>>>>= =A0 Cc: "freebsd-arm@freebsd.org" =0A>>>>=A0 Date:= 2017/9/19, Tue 15:27=0A>>>>=A0 Subject: Re: Hang up at boot on armv5t=0A>>= >>=0A>>>>=A0 Hi=0A>>>>=0A>>>>=A0 ----- Original Message -----=0A>>>>>=A0 Fr= om: Warner Losh =0A>>>>>=A0 To: Mori Hiroki =0A>>>>>=A0 Cc: "freebsd-arm@freebsd.org" = =0A>>>>>=A0 Date: 2017/9/19, Tue 00:32=0A>>>>>=A0 Subject: Re: Hang up at b= oot on armv5t=0A>>>>>=0A>>>>>=0A>>>>>=0A>>>>>=0A>>>>>=0A>>>>>=0A>>>>>=A0 On= Mon, Sep 18, 2017 at 12:59 AM, Mori Hiroki=0A>>> = =0A>>>>=A0 wrote:=0A>>>>>=0A>>>>>=A0 Hi=0A>>>>>>=0A>>>>>>=A0 Now head is hu= ng up at boot on armv5t.=A0=0A>>>>>>=0A>>>>>>=A0 KDB: debugger backends: dd= b=0A>>>>>>=A0 KDB: current backend: ddb=0A>>>>>>=A0 Copyright (c) 1992-2017= The FreeBSD Project.=0A>>>>>>=A0 Copyright (c) 1979, 1980, 1983, 1986, 198= 8, 1989, 1991, 1992, 1993,=0A>>> 1994=0A>>>>>>=A0 =A0 =A0 =A0 =A0 The Regen= ts of the University of California. All rights=0A>>>>=A0 reserved.=0A>>>>>>= =A0 FreeBSD is a registered trademark of The FreeBSD Foundation.=0A>>>>>>= =A0 FreeBSD 12.0-CURRENT #2 a3dbcdd(zrouter)-dirty: Mon Sep 11 18:04:22=0A>= >> JST=0A>>>>=A0 2017=0A>>>>>>=A0 =A0 =A0 hiroki@microserver:/storage/ home= /hiroki/obj/storage/home/=0A>>>>=A0 hiroki/zrouter/tmp/=0A>>>>>>=A0 arm.arm= /storage/home/hiroki/ freebsd/sys/Buffalo_WZR2-G300N arm=0A>>>>>>=A0 FreeBS= D clang version 5.0.0 (tags/RELEASE_500/final 312559) (based=0A>>> on=0A>>>= >=A0 LLVM 5.0.0=0A>>>>>>=A0 svn)=0A>>>>>>=0A>>>>>>=A0 Last month build is f= ine.=0A>>>>>>=0A>>>>>>=A0 https://gist.github.com/ yamori813/ 88224f1c96c9c= 592fb611b12a15e4a=0A>>> b5=0A>>>>>=0A>>>>>=0A>>>>>=A0 You might want to do = a binary search between the working and broken=0A>>> builds=0A>>>>=A0 to se= e where it breaks. Without that, it's hard to make progress.=0A>>>>>=0A>>>>= >=0A>>>>>=A0 Warner=A0=0A>>>>=0A>>>>=0A>>>>=A0 This is RT1310 build by sys/= arm/ralink.=0A>>>>=0A>>>>=A0 I get debug log by VERBOSE_SYSINIT.=0A>>>>=0A>= >>>=0A>>>>=A0 Copyright (c) 1992-2017 The FreeBSD Project.=0A>>>>=A0 Copyri= ght (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994=0A>>>>= =A0 =A0 =A0 =A0 =A0 The Regents of the University of California. All rights= reserved.=0A>>>>=A0 FreeBSD is a registered trademark of The FreeBSD Found= ation.=0A>>>>=A0 FreeBSD 12.0-CURRENT #1 a3dbcdd(zrouter)-dirty: Tue Sep 19= 15:03:43 JST=0A>>> 2017=0A>>>>=A0 =A0 =A0=0A>>> hiroki@microserver:/storag= e/ home/hiroki/obj/storage/home/ hiroki/zrouter/tmp/=0A>>>>=A0 arm.arm/stor= age/home/hiroki/ freebsd/sys/Buffalo_WZR2-G300N arm=0A>>>>=A0 FreeBSD clang= version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM=0A>>> 5.0.0= =0A>>>>=A0 svn)=0A>>>>=A0 subsystem 1000000=0A>>>>=A0 =A0=A0 0xc01c1674(0).= .. done.=0A>>>>=A0 =A0=A0 0xc01d3a0c(0)... done.=0A>>>>=A0 subsystem 180000= 0=0A>>>>=A0 =A0=A0 0xc00b9cb4(0)... done.=0A>>>>=A0 =A0=A0 0xc0097fc4(0)...= done.=0A>>>>=A0 =A0=A0 0xc0097c00(0xc0280580)...=A0=0A>>>>=0A>>>>=A0 I che= cked last address by objdump -D.=0A>>>>=0A>>>>=A0 c0097c00 := =0A>>>>=A0 c0280580 :=0A>>>>=0A>>>>=A0 What is wrong ?=0A>>>>=0A>>>= >=A0 I use git repository on build. If I change git branch then arm platfor= m is=0A>>> build=0A>>>>=A0 take=0A>>>>=0A>>>>=A0 =A06 hour by my server. It= is very hard debugging.=A0=0A>>>>=0A>>>>=A0 Hiroki Mori=0A>>>>=0A>>>>=A0 _= _____________________________ _________________=0A>>>>=A0 freebsd-arm@freeb= sd.org mailing list=0A>>>>=A0 https://lists.freebsd.org/ mailman/listinfo/f= reebsd-arm=0A>>>>=A0 To unsubscribe, send any mail to=0A>>> "freebsd-arm-un= subscribe@ freebsd.org"=0A>>>>=0A>>> ______________________________ _______= __________=0A>>> freebsd-arm@freebsd.org mailing list=0A>>> https://lists.f= reebsd.org/ mailman/listinfo/freebsd-arm=0A>>> To unsubscribe, send any mai= l to "freebsd-arm-unsubscribe@ freebsd.org"=0A>>>=0A>>_____________________= _________ _________________=0A>>freebsd-arm@freebsd.org mailing list=0A>>ht= tps://lists.freebsd.org/ mailman/listinfo/freebsd-arm=0A>>To unsubscribe, s= end any mail to "freebsd-arm-unsubscribe@ freebsd.org"=0A>>=0A>=0A>=0A> From owner-freebsd-arm@freebsd.org Thu Sep 28 08:57:29 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A8F0E2D14F for ; Thu, 28 Sep 2017 08:57:29 +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 D8C9D76231; Thu, 28 Sep 2017 08:57:27 +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 c98bf3cb; Thu, 28 Sep 2017 10:57:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=G5AQa1sUnPp8D6QeagKo5xKaI8c=; b=lr1eAjQkHgcib6BhJGz6X3Z1StIL mVkWifp5x+l7P1VnxqQ7IsRTxFEkMVy3tk+yIriLwzmYqsY1nSk3YLpEussTYlAR i7pkWy38TavMxXipbkilEtrDO8k6IQjLGpe/+GtKDTmvOKin4i/6lwom8DJbOZg+ DEGVZ/SFu8PzHjg= 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=hNlY23TZHH1DUmBENW6X6MCO+b9nIqc8vvPedAkOOSrZ/ObiRh1//cmQ kOENVnv08PD1GQfJJ/awv2C20JugzvTPBO4+/juoVBlz45If73DUeK1GaheWStsD dd4XyqCbEjQBN7BTwig7mir/iTUCDAnLCLe4wkC8U+N1/qITTdk= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id da5e1351 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 28 Sep 2017 10:57:25 +0200 (CEST) Date: Thu, 28 Sep 2017 10:57:24 +0200 From: Emmanuel Vadot To: Ian Lepore Cc: Kurt Jaeger , Guy Yur , freebsd-arm Subject: Re: if_awg fixes Message-Id: <20170928105724.b76168c5065ebb388b056f51@bidouilliste.com> In-Reply-To: <1506561886.31939.16.camel@freebsd.org> References: <20170928011129.GC86601@home.opsec.eu> <1506561886.31939.16.camel@freebsd.org> X-Mailer: Sylpheed 3.5.1 (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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 08:57:29 -0000 On Wed, 27 Sep 2017 19:24:46 -0600 Ian Lepore wrote: > On Thu, 2017-09-28 at 03:11 +0200, Kurt Jaeger wrote: > > Hi! > >=20 > > >=20 > > > I had issues with if_awg when passing heavy traffic > > > (transmission, samba, ...) > > [...] > > >=20 > > > Comparing the driver against if_nfe which also uses a ring buffer, > > > there are several issues with how the rings are programmed. > > > I made changes inspired by it. > > >=20 > > > The following fixes improved the card behavior on my boards. > > > (tested on Orange Pi PC and Orange Pi One) > > Will you submit your patches via https://bugs.freebsd.org ? > >=20 > > Otherwise it's difficult to keep track... > >=20 >=20 > Or as one or more reviews on phabricator, if you're already signed up > there. =A0https://reviews.freebsd.org/differential/ >=20 > -- Ian Yup, reviews.freebsd.org will be the best. I'll try to have a look at those. --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Sep 28 09:19:44 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1E6BE2D7E7 for ; Thu, 28 Sep 2017 09:19:44 +0000 (UTC) (envelope-from noname.esst@yahoo.com) Received: from sonic317-49.consmr.mail.gq1.yahoo.com (sonic317-49.consmr.mail.gq1.yahoo.com [98.137.66.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC3BC76DB2 for ; Thu, 28 Sep 2017 09:19:44 +0000 (UTC) (envelope-from noname.esst@yahoo.com) X-YMail-OSG: OdI64gYVM1nzPnF2HG78fpiL9ID.j4z45Us9AugFOLAH8wsrgxhMZgO.atQz_Vn k1_OTP.zYlGP5OGVl9VASV6NW7y6PIrhV.e8_q6qmtS7EDZ..wYzkabEyi88PfvCuCaXYhgscUz8 IfgS1ZceQMOGUUu8Vf8z6_ObA7XT3PKiuex7FFG80kX_QUhoOb69MUqUKAn83sT7XemI1mzY9NpM N9rP_kV5DRAKnvJz.67aq1Lqx5X7SqBb_BOldF9nMWxIL0.8hBqdsY5mGe0LxIZMTh7HpwXzPY0N 9S8kkLu2M5QIxfVX8Dc2lhr2o.vhrg9XbDfi3pbQJTSqL3yPMSK8e3j9tF1lT7DARi5rv9Mvg6gQ DA4HaqfLYGt4PXi4z3CIab0NbgeYG3xAhEy6UGclrIt5AC8O3wx8SzhhGINgs14rglDVqSq1fK78 zxOC9yS6fFbALQQuvmP.62usRsKIR0a7MrkLjHNC_IZgfLWcSsI4YIiFoYRq1hlkquw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 28 Sep 2017 09:19:43 +0000 Date: Thu, 28 Sep 2017 09:15:42 +0000 (UTC) From: Nomad Esst Reply-To: Nomad Esst To: Emmanuel Vadot Cc: Nomad Esst via freebsd-arm Message-ID: <1825224273.10951257.1506590142784@mail.yahoo.com> In-Reply-To: <20170927161819.6e36cd53a76f9e75b782a3b3@bidouilliste.com> References: <312104517.10213240.1506511560284.ref@mail.yahoo.com> <312104517.10213240.1506511560284@mail.yahoo.com> <20170927161819.6e36cd53a76f9e75b782a3b3@bidouilliste.com> Subject: Re: FreeBSD 11 on Banana-Pi M3 A83t MIME-Version: 1.0 X-Mailer: WebService/1.1.10521 YahooMailNeo Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 09:19:45 -0000 Thank you EmmanuelI'm trying to install u-boot-master according to the inst= ruction mentioned in Fresh ports:=C2=A0 #cd /usr/ports/sysutils/u-boot-master/ && make install clean But I don't have this directory! I tried to install it using pkg install: #pkg install sysutils/u-boot-master But I get this error: Updating FreeBSD repository catalogue...FreeBSD repository is up to date.Al= l repositories are up to date.pkg: No packages available to install matchin= g 'sysutils/u-boot-master' have been found in the repositories Please help me solve this.=C2=A0 Thanks in advance=C2=A0=20 On Wednesday, September 27, 2017 5:48 PM, Emmanuel Vadot wrote: =20 On Wed, 27 Sep 2017 11:26:00 +0000 (UTC) Nomad Esst via freebsd-arm wrote: > Hello allI have created an image using Crochet build tool for my BPi M3 b= oard. I have burnt it on it's on-board 4GB EMMC. When I try to boot the boa= rd, I get the following error: >=20 > U-Boot SPL 2016.05 (Aug 13 2017 - 05:07:01)DRAM: 2048 MiBCard did not res= pond to voltage select!Could not determine boot source > resetting ... > What should I do? > Thanks in advance. Our U-Boot is probably not recent enough to support the eMMC. A83T support is not really great even in Linux or U-Boot. You could try updating u-boot to use the u-boot-master port (which curently track the 2017.07 version of U-Boot). --=20 Emmanuel Vadot =20 From owner-freebsd-arm@freebsd.org Thu Sep 28 09:29:55 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2FCFE2DA7E for ; Thu, 28 Sep 2017 09:29:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 A275B771DD for ; Thu, 28 Sep 2017 09:29:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id c195so500984itb.1 for ; Thu, 28 Sep 2017 02:29:55 -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=/SHp1Tf+DnrzZLJlJKJ9JE5zhOY5mIoeMcb+lXVdQ24=; b=NNv0zCPWwroaQKS52wVHdgefIfY6K490hkRmTLEi/nQx/4PVC5LUm8iUPsV9EPKU5S PZpjVDY3YXq2EocyTlE5ocebdHljlKIa7Jh3ch8O4+8JM5CSLTEyelWUFKHSEC1r3NwR RCb/BTuGAC78X1a9hB5Efs2U4gAeH/XiTa/QngzCVIc8KVB7NuY0EWKtCE07t64rEi7U /HwuMT6YDZpDjyB2vI5XEjGSOXYhG8zYjqZwnMruY1q3/CsdvYWh7ALaB1t35Fq4zhTX 0NEf0EQM+N+0NDEwt61hBeE38D1sLKOVNsD7B+4BHQnVEmGfQ/z6rQGIO76XWy/wmKDu 6dcw== 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=/SHp1Tf+DnrzZLJlJKJ9JE5zhOY5mIoeMcb+lXVdQ24=; b=Tww4WbGWFto40+7h8bntOPuxFyymZ2iPcvnogjrShfsYYhMZZM7fY4HgWnGDt1TqR5 oFgmxnZwO1x4VK/AjDCAlUdZCTu80NUeXb/HrwAxCyiM9Wa7Q2i+MxZuCuZyEdO3RYHs JwidMkkAlRGOsmAuSzCocLBiX35PlxBgMp0OaOGPdQrfUiZo3/4PCkQ//cEkEkAg87y1 R0XziW5aUcM+AzBflYsMvNdckebXircEyAG9kyoTWx2+ecURui87kcX3m9BLicXLFLI1 ahJgZ3A0GjWU14WB6G8jSeoFM9IX4rAZ1CtjOfSYT6P4nHeXFxEG7rdl8bsZQYQ28kNq U8DA== X-Gm-Message-State: AMCzsaX6di+WGLza8LuxvNSEfAlsAA9n/ZS2xVtwFQ8YEc5Lnqws4gct +sjOtsbx2acYg6PplXSbL5aEDiyfSsuSS97fuYlaaw== X-Google-Smtp-Source: AOwi7QCpA453YXjHM55Q2gVlAD/n6TD+9itBdXuwnHiUVvAxo0GsTGOBQYP4cGQwELlQ32uZ4e49q41Cwc5fUcRwsuE= X-Received: by 10.36.6.18 with SMTP id 18mr602206itv.15.1506590994657; Thu, 28 Sep 2017 02:29:54 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Thu, 28 Sep 2017 02:29:53 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:f996:822c:89a6:8ee4] In-Reply-To: <586157.40149.qm@web101704.mail.ssk.yahoo.co.jp> References: <509836.65470.qm@web101704.mail.ssk.yahoo.co.jp> <818825.27559.qm@web101705.mail.ssk.yahoo.co.jp> <323129.32331.qm@web101720.mail.ssk.yahoo.co.jp> <317452.45869.qm@web101717.mail.ssk.yahoo.co.jp> <586157.40149.qm@web101704.mail.ssk.yahoo.co.jp> From: Warner Losh Date: Thu, 28 Sep 2017 03:29:53 -0600 X-Google-Sender-Auth: 4uAhpN8cSD936ugSMZqRfv8QMD8 Message-ID: Subject: Re: Hang up at boot on armv5t To: Mori Hiroki Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 09:29:55 -0000 what happens if you back out these two chunks of the diff: @@ -355,13 +572,13 @@ blist_print(blist_t bl) * * This is the core of the allocator and is optimized for the * BLIST_BMAP_RADIX block allocation case. Otherwise, execution - * time is proportional to log2(count) + log2(BLIST_BMAP_RADIX). + * time is proportional to log2(count) + bitpos time. */ static daddr_t blst_leaf_alloc(blmeta_t *scan, daddr_t blk, int count, daddr_t cursor) { u_daddr_t mask; - int count1, hi, lo, mid, num_shifts, range1, range_ext; + int count1, lo, num_shifts, range1, range_ext; if (count == BLIST_BMAP_RADIX) { /*@@ -419,17 +636,10 @@ blst_leaf_alloc(blmeta_t *scan, daddr_t blk, int count, daddr_t cursor) /* * The least significant set bit in mask marks the start of the first * available range of sufficient size. Clear all the bits but that one, - * and then perform a binary search to find its position. + * and then find its position. */ mask &= -mask; - hi = BLIST_BMAP_RADIX - count1; - while (lo + 1 < hi) { - mid = (lo + hi) >> 1; - if ((mask >> mid) != 0) - lo = mid; - else - hi = mid; - } + lo = bitpos(mask); /* * Set in mask exactly the bits being allocated, and clear them from since bitpos doesn't start at BLIST_BMAP_RADIX - count1 for 'hi', but instead assumes count1 is 0, and lo should start at 0 as well. Warner On Thu, Sep 28, 2017 at 1:39 AM, Mori Hiroki wrote: > Hi > > I found more hang up commit on armv5t. > > commit e7430120e9c80c0786dc0e9f54e336634932de4c(r323391) > Author: alc > Date: Sun Sep 10 17:46:03 2017 +0000 > > This is more complex commit. How make workaround on armv5t? > > > ----- Original Message ----- > >From: Warner Losh > >To: Mori Hiroki ; Mateusz Guzik > > >Cc: "freebsd-arm@freebsd.org" > >Date: 2017/9/27, Wed 13:01 > >Subject: Re: Hang up at boot on armv5t > > > > > >Well, you could do something cheezy like #ifndef arm :) > > > > > >If you do that in the latest sources, does it solve the problem? > > > > > >diff --git a/sys/sys/systm.h b/sys/sys/systm.h > >index ddebe0a6843..484784466a3 100644 > >--- a/sys/sys/systm.h > >+++ b/sys/sys/systm.h > >@@ -258,12 +258,14 @@ void hexdump(const void *ptr, int length, > const char *hdr, int flags); > > #define ovbcopy(f, t, l) bcopy((f), (t), (l)) > > void bcopy(const void * _Nonnull from, void * _Nonnull to, size_t len); > > void bzero(void * _Nonnull buf, size_t len); > >+#ifndef arm > > #define bzero(buf, len) ({ \ > > if (__builtin_constant_p(len) && (len) <= 64) \ > > __builtin_memset((buf), 0, (len)); \ > > else \ > > bzero((buf), (len)); \ > > }) > >+#endif > > void explicit_bzero(void * _Nonnull, size_t); > > > > > > void *memcpy(void * _Nonnull to, const void * _Nonnull from, size_t > len); > > I think "#ifndef __arm__" is good rather than "#ifndef arm". > > This is good before r323391. > > > > > > >And is this built with gcc or clang? What version? > > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM > 5.0.0 > svn) > > Hiroki Mori > > > > > >Warner > > > > > >On Tue, Sep 26, 2017 at 9:55 PM, Mori Hiroki > wrote: > > > >Hi. > >> > >>I found out hang up problem cause of this commit. > >> > >>commit 20b4bc44be9bc985b74f8d5a01a24e 302e2a44ff > >>Author: mjg > >>Date: Fri Sep 8 20:09:14 2017 +0000 > >> > >>How to fix these commit ? > >> > >>Hiroki Mori > >> > >> > >>----- Original Message ----- > >>> From: Mori Hiroki > >> > >>> To: "freebsd-arm@freebsd.org" > >>> Cc: > >>> Date: 2017/9/27, Wed 10:42 > >>> Subject: Re: Hang up at boot on armv5t > >>> > >>> Hi. > >>> > >>> I still investigate this problem. > >>> > >>> I found other problem. > >>> > >>> This commit make panic on armv5t(RT1310). > >>> > >>> commit 1db0a229476afafe06f2bc9749f673 8e6cc6d047 > >>> Author: markj > >>> Date: Thu Sep 7 21:43:39 2017 +0000 > >>> > >>> https://gist.github.com/ yamori813/ dc3740085996af505d669446175170 6f > >>> > >>> > >>> Hiroki Mori > >>> > >>> > >>> ----- Original Message ----- > >>>> From: Mori Hiroki > >>>> To: Warner Losh > >>>> Cc: "freebsd-arm@freebsd.org" > >>>> Date: 2017/9/19, Tue 15:27 > >>>> Subject: Re: Hang up at boot on armv5t > >>>> > >>>> Hi > >>>> > >>>> ----- Original Message ----- > >>>>> From: Warner Losh > >>>>> To: Mori Hiroki > >>>>> Cc: "freebsd-arm@freebsd.org" > >>>>> Date: 2017/9/19, Tue 00:32 > >>>>> Subject: Re: Hang up at boot on armv5t > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Sep 18, 2017 at 12:59 AM, Mori Hiroki > >>> > >>>> wrote: > >>>>> > >>>>> Hi > >>>>>> > >>>>>> Now head is hung up at boot on armv5t. > >>>>>> > >>>>>> KDB: debugger backends: ddb > >>>>>> KDB: current backend: ddb > >>>>>> Copyright (c) 1992-2017 The FreeBSD Project. > >>>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > >>> 1994 > >>>>>> The Regents of the University of California. All rights > >>>> reserved. > >>>>>> FreeBSD is a registered trademark of The FreeBSD Foundation. > >>>>>> FreeBSD 12.0-CURRENT #2 a3dbcdd(zrouter)-dirty: Mon Sep 11 18:04:22 > >>> JST > >>>> 2017 > >>>>>> hiroki@microserver:/storage/ home/hiroki/obj/storage/home/ > >>>> hiroki/zrouter/tmp/ > >>>>>> arm.arm/storage/home/hiroki/ freebsd/sys/Buffalo_WZR2-G300N arm > >>>>>> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based > >>> on > >>>> LLVM 5.0.0 > >>>>>> svn) > >>>>>> > >>>>>> Last month build is fine. > >>>>>> > >>>>>> https://gist.github.com/ yamori813/ 88224f1c96c9c592fb611b12a15e4a > >>> b5 > >>>>> > >>>>> > >>>>> You might want to do a binary search between the working and broken > >>> builds > >>>> to see where it breaks. Without that, it's hard to make progress. > >>>>> > >>>>> > >>>>> Warner > >>>> > >>>> > >>>> This is RT1310 build by sys/arm/ralink. > >>>> > >>>> I get debug log by VERBOSE_SYSINIT. > >>>> > >>>> > >>>> Copyright (c) 1992-2017 The FreeBSD Project. > >>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > 1994 > >>>> The Regents of the University of California. All rights > reserved. > >>>> FreeBSD is a registered trademark of The FreeBSD Foundation. > >>>> FreeBSD 12.0-CURRENT #1 a3dbcdd(zrouter)-dirty: Tue Sep 19 15:03:43 > JST > >>> 2017 > >>>> > >>> hiroki@microserver:/storage/ home/hiroki/obj/storage/home/ > hiroki/zrouter/tmp/ > >>>> arm.arm/storage/home/hiroki/ freebsd/sys/Buffalo_WZR2-G300N arm > >>>> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based > on LLVM > >>> 5.0.0 > >>>> svn) > >>>> subsystem 1000000 > >>>> 0xc01c1674(0)... done. > >>>> 0xc01d3a0c(0)... done. > >>>> subsystem 1800000 > >>>> 0xc00b9cb4(0)... done. > >>>> 0xc0097fc4(0)... done. > >>>> 0xc0097c00(0xc0280580)... > >>>> > >>>> I checked last address by objdump -D. > >>>> > >>>> c0097c00 : > >>>> c0280580 : > >>>> > >>>> What is wrong ? > >>>> > >>>> I use git repository on build. If I change git branch then arm > platform is > >>> build > >>>> take > >>>> > >>>> 6 hour by my server. It is very hard debugging. > >>>> > >>>> 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 > " > >>> > >>______________________________ _________________ > >>freebsd-arm@freebsd.org mailing list > >>https://lists.freebsd.org/ mailman/listinfo/freebsd-arm > >>To unsubscribe, send any mail to "freebsd-arm-unsubscribe@ freebsd.org" > >> > > > > > > > From owner-freebsd-arm@freebsd.org Thu Sep 28 09:35:10 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B49E6E2DCD0 for ; Thu, 28 Sep 2017 09:35:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 785ED775D0 for ; Thu, 28 Sep 2017 09:35:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22e.google.com with SMTP id l15so1031265iol.8 for ; Thu, 28 Sep 2017 02:35:10 -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=ofWNkGTL5h6+h1xu6IZ6NsM8lEUQFuBCP13PUiJK8as=; b=NQFzxQb1rbwMsqxN62CaHS+uvIDz4pSfWudGd9D6aahDraJyDMK123SyT58CvIxxTk JgmaJwzV5rsM8bsLh93pRUf+1zzMBMRYpph3P1sbjrJARu2Rh5wHDYQiHdTl2MqHaveJ nhuy36J9MtoVQmFhLE1KzZvvu4L7XnAGcOvDoauuzWYS+LdyyxV5DlxomUsMvuxNyUXy ZtiRQP16sBZfOYCXLrT9DmLVNPKNx5aKC4rehNzmJSh2pv/N9HqKGjhzN+CJpxeDof1A diEjkNfSnsfPkssw03zFftxZkmFfSwHkKN5CgaXTNFk3hvdMRbuG3st0Pq1SMC6ohMTE JrDA== 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=ofWNkGTL5h6+h1xu6IZ6NsM8lEUQFuBCP13PUiJK8as=; b=jeyTBhwGkagZ/ay3fuYjteDfgLvJpE5q77rrmX3XDmAyHjw2X/+OfDPwTKd+RvegDP c+v4EOvve6K+hi3dzJmUH6x+UpFzaezQuwFEAcRwU2ooTnushEhVGyF6RkkFRZmJig5k dzBIQeyecZqNeEcJbpBdu0/1tLMw+9V6/d72d/byRiecivQYlqjtD+v9OUGtDrf0r79I 8WjWDsMQQKiudP5QwYkBVViSwTDsEY2XGxndB05OBOaNZFD5IjmtzAzXOCQ/ry+W0aID i4gWZj5tJ2I8C6SGLVcLV1lhCKWDAN6DEqr+VqS/flslNR7af1oA+ztCky6AgLUp+RJK fe8w== X-Gm-Message-State: AMCzsaXbAeH1ZDTpqqT/7t9/vC2R/cp4OETeRVYC6KivNpDEhCGxmrDp P8MQSbI6nrF81QxZhLaM/7AWYBk9pchymhjoq0z3qw== X-Google-Smtp-Source: AOwi7QCgc4d4LY6gZThRTpjcZlEZ7sdvvRJN5XcdRtwt/vsZUY2C8bojZJoFE88LUCfusFJdUPRZHOIvLpR3/9fs+LY= X-Received: by 10.107.133.92 with SMTP id h89mr5871518iod.208.1506591309819; Thu, 28 Sep 2017 02:35:09 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Thu, 28 Sep 2017 02:35:09 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:f996:822c:89a6:8ee4] In-Reply-To: <1825224273.10951257.1506590142784@mail.yahoo.com> References: <312104517.10213240.1506511560284.ref@mail.yahoo.com> <312104517.10213240.1506511560284@mail.yahoo.com> <20170927161819.6e36cd53a76f9e75b782a3b3@bidouilliste.com> <1825224273.10951257.1506590142784@mail.yahoo.com> From: Warner Losh Date: Thu, 28 Sep 2017 03:35:09 -0600 X-Google-Sender-Auth: jIZpUkEY4P2-FqcfQP0Q9nGk4Vk Message-ID: Subject: Re: FreeBSD 11 on Banana-Pi M3 A83t To: Nomad Esst Cc: Emmanuel Vadot , Nomad Esst via freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 09:35:10 -0000 On Thu, Sep 28, 2017 at 3:15 AM, Nomad Esst via freebsd-arm < freebsd-arm@freebsd.org> wrote: > Thank you EmmanuelI'm trying to install u-boot-master according to the > instruction mentioned in Fresh ports: > > #cd /usr/ports/sysutils/u-boot-master/ && make install clean > > But I don't have this directory! I tried to install it using pkg install: > > #pkg install sysutils/u-boot-master > > But I get this error: > > Updating FreeBSD repository catalogue...FreeBSD repository is up to > date.All repositories are up to date.pkg: No packages available to install > matching 'sysutils/u-boot-master' have been found in the repositories > Please help me solve this. > Thanks in advance u-boot-master isn't a port that you install. It's just the place that you update when you want to change the u-boot version. You'd have to change it to point to the upstream version of u-boot rather than our repo, though, and that might start to get tricky.... Warner > On Wednesday, September 27, 2017 5:48 PM, Emmanuel Vadot < > manu@bidouilliste.com> wrote: > > > On Wed, 27 Sep 2017 11:26:00 +0000 (UTC) > Nomad Esst via freebsd-arm wrote: > > > Hello allI have created an image using Crochet build tool for my BPi M3 > board. I have burnt it on it's on-board 4GB EMMC. When I try to boot the > board, I get the following error: > > > > U-Boot SPL 2016.05 (Aug 13 2017 - 05:07:01)DRAM: 2048 MiBCard did not > respond to voltage select!Could not determine boot source > > resetting ... > > What should I do? > > Thanks in advance. > > Our U-Boot is probably not recent enough to support the eMMC. A83T > support is not really great even in Linux or U-Boot. > > You could try updating u-boot to use the u-boot-master port (which > curently track the 2017.07 version of U-Boot). > > -- > Emmanuel Vadot > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Thu Sep 28 18:25:39 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22579E059EE for ; Thu, 28 Sep 2017 18:25:39 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3AE16894A for ; Thu, 28 Sep 2017 18:25:38 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-wr0-x232.google.com with SMTP id z39so4231775wrb.8 for ; Thu, 28 Sep 2017 11:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=h8mFineOWMntbGW5PEixV1N5hDsGB7Xr+jsB3mNiURc=; b=fotFRKfKktOhprP7mIjtovZjLhSqraXKHl16/Ocwz3NUTaUNBJQRWt/v03YO679C9S zTPedjannFyCdKplo1AGcRsZlihkWPie12nbO0gsUCV1YBKcTWza+iN+uEJIN0uZlrcf 7etZ0rRzLf5RoICKt6MpG19/ZNq0PchLoZMf9bk1xTl96alVE6NWnNi0/H6SeAdH+a17 spwwX/iWCaxv/kbl+Ky2cRlCLHrUtFxT5UbTTk62PZmp1Nq902HOmeM2chPiJhhRFfkp NByQw2LS7ykEHNJJUsbBRYwUCqea4z0tLHcGV5htzVpst+5ktJqupbJSw10y5T/fBSEM AFXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=h8mFineOWMntbGW5PEixV1N5hDsGB7Xr+jsB3mNiURc=; b=qM+5NpLgWcvOzI8uwKfESJW/8oMytc350XcPGEP3oM5Dnpqcuj0BNW9gq90m163LiA XlpM+80l84tahjGGoX0jMY8xqRlCUyXQwg8Rz9YcIfhXCXUDCge8UKSf6p4Chg4pFUBy mNqQfugsFNVpDrAQGvakihfZOxOenHqEVVWY6fvABPCvuZ+ESqDp1iSIi8ynpk/1c2uE h7MpL3vRIrHdNkMxZ/v2EvVxJZljvDE+s57RYeA+pqb+TcMCO3ZfliD1D0A8tSXVdK8Z w6R14/URG8N699J4xO6jj6qyTmDZ/d3EiUQI/AUc7egxGYxmRJVugEiGm1W2n8OQNk33 TXoA== X-Gm-Message-State: AHPjjUiAlDJ82ZwBO/rMV08rtJf/wMZfDcocH+o5/P5u+CUNDqdQofjH Ad5/altZPbAVfk7GlGQmitr/tvnXd5igNxovvyVnzg== X-Google-Smtp-Source: AOwi7QClAvORe1UHRhydZHf8mvNd32RrFpixs6MWs6gMTCKynwwgIjk364NPl00VwRQiKl8QzYv12x51e1TneBK3aT4= X-Received: by 10.46.91.5 with SMTP id p5mr2535621ljb.22.1506623136908; Thu, 28 Sep 2017 11:25:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Thu, 28 Sep 2017 11:25:36 -0700 (PDT) From: Russell Haley Date: Thu, 28 Sep 2017 11:25:36 -0700 Message-ID: Subject: Dead Serial on Hummingboard? To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 18:25:39 -0000 My son was playing on my computer yesterday and I found my hummingboard on the floor this morning. It's not the first time it's hit the ground so I figured it was fine (lights are still on!). I've tried to use the serial connection but it doesn't seem to be transmitting my keyboard input. I can see the kernel output all the way to login but it doesn't respond. ssh to the board works fine through Ethernet, and the ftdi cable works fine on my BBB. I've also tried two different kernels (r324055M, r321601M). There doesn't apear to be any physical damage (solder on the pins looks okay) and I took the heatsink off and inspected the processor. It boots fine after I re-assembled, still no serial input. Any ideas? RIP hummingboard serial? Russ From owner-freebsd-arm@freebsd.org Thu Sep 28 19:10:58 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8519FE0689D for ; Thu, 28 Sep 2017 19:10:58 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 1891E6A49A; Thu, 28 Sep 2017 19:10:58 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wr0-x235.google.com with SMTP id g29so4438124wrg.11; Thu, 28 Sep 2017 12:10:58 -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=ugEHm9dlj+jqpYSDeyQS8y24wRtx6OtyJMvy3ZabDRQ=; b=HNQT/4kpKC5rHRD5BF4vKYv8mlZCBj1nl6N86dBXTnsBrT207azraXdKMMuPl3i9Lt TrYEPAmjjm2ULPDiAIwFCHo6AZnK04+oC/3jm/zc0tO5fiG80oP0FUCZyqjL156tCZNg 9q/wKpk10EOIFGx3MksWgNty9uSRapQTPRuN/Xy/yh52JhX/1VBxTmOzLw0Cs+9ktjPE rsu/y+UiveeYv6jDFJko+GRZOYTRjyXAC4wA6jpJ4CseoVIt97vVVhPKqgtWareCI5uT +u+ozHsBIO3vXoozGtY20PXFtClfPBJEYMxC1vPyjCyT/yUplHLMMlagwfx1WVsPNBC5 7bxw== 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=ugEHm9dlj+jqpYSDeyQS8y24wRtx6OtyJMvy3ZabDRQ=; b=Hjc9YMidRX9a+QR+1B9aFPG3m6aiTIvtU+QXhHpnSWczqKpIQedjUPI7B7NKZ9dzoH Wd3ib1dXoJT9Zd2Kpr12vZQN7H1lvFFchGz94C1DxcywZTBpDShV3d878GM/O8VyreSN 4aBYFEAUZoRZwE2t4L7WY1OCK25y8jmd7jB2QELgZMAgPve84e1qmH12gDTFWYr8h0yW V/kTYcmisRf/aZbOnz5XG/u7MDBCjfO4aOidxw2xMMoZoKAKHC0sapv9p/BN7sN4Qee/ tpi8ybIohGbE6i++9bLyUay7CY9lkSphgIf3WctF9TYodQ7Wtx5u1tPlvDE4IewNvSdn pAsg== X-Gm-Message-State: AHPjjUjHeIec5k7AkgyKpKAcOB/2sRK8xB+MmB4B2mip/DHxO5Xt31Ea heJZjVgsJ2LmYeawgw+v6c+01PUxoK71okikI5pnRg== X-Google-Smtp-Source: AOwi7QDRfg3zNsahEAcnodLAvSpMOXoL1HVd84ajpQdat7HJm8IaYIJl8RQk6UGjnzjM50sForA8r3aVEsOjw2bwnJQ= X-Received: by 10.223.164.206 with SMTP id h14mr5219504wrb.25.1506625856408; Thu, 28 Sep 2017 12:10:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.238.142 with HTTP; Thu, 28 Sep 2017 12:10:55 -0700 (PDT) In-Reply-To: <20170928105724.b76168c5065ebb388b056f51@bidouilliste.com> References: <20170928011129.GC86601@home.opsec.eu> <1506561886.31939.16.camel@freebsd.org> <20170928105724.b76168c5065ebb388b056f51@bidouilliste.com> From: Guy Yur Date: Thu, 28 Sep 2017 22:10:55 +0300 Message-ID: Subject: Re: if_awg fixes To: Emmanuel Vadot Cc: Ian Lepore , Kurt Jaeger , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 19:10:58 -0000 On 28 September 2017 at 11:57, Emmanuel Vadot wrote: > On Wed, 27 Sep 2017 19:24:46 -0600 > Ian Lepore wrote: > >> On Thu, 2017-09-28 at 03:11 +0200, Kurt Jaeger wrote: >> > Hi! >> > >> > > > ... > > Yup, reviews.freebsd.org will be the best. > I'll try to have a look at those. > > -- > Emmanuel Vadot Hi, I created a phabricator account and four diffs. https://reviews.freebsd.org/D12535 https://reviews.freebsd.org/D12536 https://reviews.freebsd.org/D12537 https://reviews.freebsd.org/D12538 Before writing this message I saw one of my boards got stuck again and I got the other stuck by doing "find /" over ssh. Received packets were still being seen in tcpdump but not tx ones. I will add some sysctls to debug why it gets stuck and rework D12537. Doing ifconfig down/up releases the card so I believe the fifth patch to clear the buffers on stop is ok but I will wait till I fix D12537 before adding it to phabricator . Thanks, Guy From owner-freebsd-arm@freebsd.org Thu Sep 28 19:14:01 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90E9DE06BA4 for ; Thu, 28 Sep 2017 19:14:01 +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 DA86F6A7DD; Thu, 28 Sep 2017 19:14:00 +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 7b7a891f; Thu, 28 Sep 2017 21:13:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; s=mail; bh=Vvwewb 0avbcjnJSHuIqOp77TtEY=; b=Bd/NHeQYBsaAtCCiqUaYJZPoJpgjZDuD7Wlq6a Tkop+ysgQK/IxuUBcHCttX+uOx8g41psOrWLDeGa8Bc2YoegFF6170Iuo7YIvQoh Da3WBGaPj3JY2yvDTvaMK8XWXaqpbKe8n9+Gv3kQgMCzVqPhv+X8rgcMkULMFal8 nvI1U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; q=dns; s=mail; b= MxeEIVJOBwoySTp5chbTlQemwNSLtMlYnC3P6vi5z+js/laW9bPn4xcyWvW575Nv MhEic0PaBMCBk5tw2fVo+pGDa8CGmZJxnH3qhFRfogZFx+FEgzawD/uFzt4+uUEe 47Nah00WttRsfznRkFgyAUHlJb2ynkNf45+uQ8g+ZAw= Received: from webmail.megadrive.org (www1.blih.net [212.83.177.180]) by mail.blih.net (OpenSMTPD) with ESMTP id 57194387; Thu, 28 Sep 2017 21:13:48 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 28 Sep 2017 21:13:48 +0200 From: Emmanuel Vadot To: Guy Yur Cc: Ian Lepore , Kurt Jaeger , freebsd-arm Subject: Re: if_awg fixes Organization: Bidouilliste In-Reply-To: References: <20170928011129.GC86601@home.opsec.eu> <1506561886.31939.16.camel@freebsd.org> <20170928105724.b76168c5065ebb388b056f51@bidouilliste.com> Message-ID: <8cd473c06a33c360db774a428a030833@megadrive.org> X-Sender: manu@bidouilliste.com User-Agent: Roundcube Webmail/1.1.1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 19:14:01 -0000 On 2017-09-28 21:10, Guy Yur wrote: > On 28 September 2017 at 11:57, Emmanuel Vadot > wrote: >> On Wed, 27 Sep 2017 19:24:46 -0600 >> Ian Lepore wrote: >> >>> On Thu, 2017-09-28 at 03:11 +0200, Kurt Jaeger wrote: >>> > Hi! >>> > >>> > > >> ... >> >> Yup, reviews.freebsd.org will be the best. >> I'll try to have a look at those. >> >> -- >> Emmanuel Vadot > > Hi, > > I created a phabricator account and four diffs. > > https://reviews.freebsd.org/D12535 > https://reviews.freebsd.org/D12536 > https://reviews.freebsd.org/D12537 > https://reviews.freebsd.org/D12538 > > Before writing this message I saw one of my boards got stuck > again and I got the other stuck by doing "find /" over ssh. > > Received packets were still being seen in tcpdump but not tx ones. > I will add some sysctls to debug why it gets stuck and rework D12537. > > Doing ifconfig down/up releases the card so I believe the fifth patch > to clear the buffers on stop is ok but I will wait till I fix D12537 > before adding it to phabricator . > > Thanks, > Guy Thanks a lot, I will not have time to look at them before next week. Will probably look at them on monday. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Sep 28 21:53:09 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62BCDE0D494 for ; Thu, 28 Sep 2017 21:53:09 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [IPv6:2a02:21e0:16e0:fe::101:1]) (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 EF9C56F952 for ; Thu, 28 Sep 2017 21:53:08 +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 v8SLr0lS082872 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Sep 2017 23:53:01 +0200 (CEST) (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 v8SLqwxS019863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Sep 2017 23:52:58 +0200 (CEST) (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 v8SLqwha002623 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 Sep 2017 23:52:58 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id v8SLqwS1002622; Thu, 28 Sep 2017 23:52:58 +0200 (CEST) (envelope-from ticso) Date: Thu, 28 Sep 2017 23:52:58 +0200 From: Bernd Walter To: Russell Haley Cc: freebsd-arm Subject: Re: Dead Serial on Hummingboard? Message-ID: <20170928215257.GC87138@cicely7.cicely.de> Reply-To: ticso@cicely.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 11.0-STABLE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED=-1, RP_MATCHES_RCVD=-0.001 autolearn=unavailable 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 21:53:09 -0000 On Thu, Sep 28, 2017 at 11:25:36AM -0700, Russell Haley wrote: > My son was playing on my computer yesterday and I found my > hummingboard on the floor this morning. It's not the first time it's > hit the ground so I figured it was fine (lights are still on!). > > I've tried to use the serial connection but it doesn't seem to be > transmitting my keyboard input. I can see the kernel output all the > way to login but it doesn't respond. ssh to the board works fine > through Ethernet, and the ftdi cable works fine on my BBB. I've also > tried two different kernels (r324055M, r321601M). > > There doesn't apear to be any physical damage (solder on the pins > looks okay) and I took the heatsink off and inspected the processor. > It boots fine after I re-assembled, still no serial input. > > Any ideas? RIP hummingboard serial? Does it output on the serial? I'm not up to date with my iMX6 boards, but different boards used different iMX6 uarts for console port, so chances are that you are just on the wrong one. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Thu Sep 28 22:07:19 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A51BE0D7A0 for ; Thu, 28 Sep 2017 22:07:19 +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 42FF96FDC3 for ; Thu, 28 Sep 2017 22:07:18 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 56f6dd72-a499-11e7-b50b-53dc5ecda239 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 56f6dd72-a499-11e7-b50b-53dc5ecda239; Thu, 28 Sep 2017 22:06:55 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8SM7GcH002015; Thu, 28 Sep 2017 16:07:16 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506636436.31939.34.camel@freebsd.org> Subject: Re: Dead Serial on Hummingboard? From: Ian Lepore To: ticso@cicely.de, Russell Haley Cc: freebsd-arm Date: Thu, 28 Sep 2017 16:07:16 -0600 In-Reply-To: <20170928215257.GC87138@cicely7.cicely.de> References: <20170928215257.GC87138@cicely7.cicely.de> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 22:07:19 -0000 On Thu, 2017-09-28 at 23:52 +0200, Bernd Walter wrote: > On Thu, Sep 28, 2017 at 11:25:36AM -0700, Russell Haley wrote: > > > > My son was playing on my computer yesterday and I found my > > hummingboard on the floor this morning. It's not the first time > > it's > > hit the ground so I figured it was fine (lights are still on!). > > > > I've tried to use the serial connection but it doesn't seem to be > > transmitting my keyboard input. I can see the kernel output all the > > way to login but it doesn't respond. ssh to the board works fine > > through Ethernet, and the ftdi cable works fine on my BBB. I've > > also > > tried two different kernels (r324055M, r321601M). > > > > There doesn't apear to be any physical damage (solder on the pins > > looks okay) and I took the heatsink off and inspected the > > processor. > > It boots fine after I re-assembled, still no serial input. > > > > Any  ideas? RIP hummingboard serial? > Does it output on the serial? > I'm not up to date with my iMX6 boards, but different boards used > different > iMX6 uarts for console port, so chances are that you are just on the > wrong > one. > Afaik, all imx6 boards use uart0 for serial console except Boundary Nitrogen series, which uses uart1.  In Russell's case, it was working fine until the board was dropped on the floor, and then input stopped working but output is still okay. If it's not a problem with the input coming loose and being reconnected to the wrong pin on the hummingboard header, then it's hard to imagine what else the problem could be except a cracked solder joint from the fall.  You might need a microscope (or at least a jeweler's loupe) to see the damage. -- Ian From owner-freebsd-arm@freebsd.org Thu Sep 28 23:43:49 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66F7DE0F25C for ; Thu, 28 Sep 2017 23:43:49 +0000 (UTC) (envelope-from bernd@cicely.de) Received: from raven.bwct.de (raven.bwct.de [IPv6:2a02:21e0:16e0:fe::101:1]) (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 F40E472307; Thu, 28 Sep 2017 23:43:48 +0000 (UTC) (envelope-from bernd@cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id v8SNhicJ084728 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Sep 2017 01:43:45 +0200 (CEST) (envelope-from bernd@cicely.de) Received: from [10.177.1.205] (dyn3-205.cicely.de [10.177.1.205]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id v8SNhfxv033794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Sep 2017 01:43:42 +0200 (CEST) (envelope-from bernd@cicely.de) Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) Subject: Re: Dead Serial on Hummingboard? From: Bernd Walter X-Mailer: iPad Mail (15A402) In-Reply-To: <1506636436.31939.34.camel@freebsd.org> Date: Fri, 29 Sep 2017 01:43:41 +0200 Cc: ticso@cicely.de, Russell Haley , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <13335288-6F29-450B-B731-D4DF0975C403@cicely.de> References: <20170928215257.GC87138@cicely7.cicely.de> <1506636436.31939.34.camel@freebsd.org> To: Ian Lepore X-Spam-Status: No, score=0.2 required=5.0 tests=HELO_MISC_IP=0.25, RP_MATCHES_RCVD=-0.001 autolearn=no 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 23:43:49 -0000 > Am 29.09.2017 um 00:07 schrieb Ian Lepore : >=20 >> On Thu, 2017-09-28 at 23:52 +0200, Bernd Walter wrote: >>> On Thu, Sep 28, 2017 at 11:25:36AM -0700, Russell Haley wrote: >>>=20 >>> My son was playing on my computer yesterday and I found my >>> hummingboard on the floor this morning. It's not the first time >>> it's >>> hit the ground so I figured it was fine (lights are still on!). >>>=20 >>> I've tried to use the serial connection but it doesn't seem to be >>> transmitting my keyboard input. I can see the kernel output all the >>> way to login but it doesn't respond. ssh to the board works fine >>> through Ethernet, and the ftdi cable works fine on my BBB. I've >>> also >>> tried two different kernels (r324055M, r321601M). >>>=20 >>> There doesn't apear to be any physical damage (solder on the pins >>> looks okay) and I took the heatsink off and inspected the >>> processor. >>> It boots fine after I re-assembled, still no serial input. >>>=20 >>> Any ideas? RIP hummingboard serial? >> Does it output on the serial? >> I'm not up to date with my iMX6 boards, but different boards used >> different >> iMX6 uarts for console port, so chances are that you are just on the >> wrong >> one. >>=20 >=20 > Afaik, all imx6 boards use uart0 for serial console except Boundary > Nitrogen series, which uses uart1. In Russell's case, it was working > fine until the board was dropped on the floor, and then input stopped > working but output is still okay. The marsboard also uses something else - uart1 or 2. Havn=A1=AEt used my Hummingboards yet... >=20 > If it's not a problem with the input coming loose and being reconnected > to the wrong pin on the hummingboard header, then it's hard to imagine > what else the problem could be except a cracked solder joint from the > fall. You might need a microscope (or at least a jeweler's loupe) to > see the damage. Yes - that=A1=AEs unfortunate. But if it is broken he could switch uart. Requires a bit of work though, because uboot has to know. From owner-freebsd-arm@freebsd.org Fri Sep 29 00:56:51 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D063BE10B84 for ; Fri, 29 Sep 2017 00:56:51 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6386174020; Fri, 29 Sep 2017 00:56:51 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wr0-x22a.google.com with SMTP id m18so5604775wrm.2; Thu, 28 Sep 2017 17:56:51 -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=rj/ZuT6rRUqkCi64K7g6cOQC3JoNu26m/U7gOJbqdH8=; b=XnxeJLwvXiSc6lFAcQ/k5oQp+Rx3FQu9aJncsGDs5ShiLuXSVVukSM7LFk1g7clUzw G3RZYCA9+rA716kvPspRJOywCgJz++10rdPRdwRBCsRS+44aw2P43gKDh7HL6Mwj/hNy SB66UV1zaHFPmInQ5qt9wq6bHP4+qfYWckU3UaMlOjmMM3x1v5vRx+hqbhdQ+6Y3Cu13 yGCiuiZH46+SXb7UZPbXVdA4P2FM2gBW6njGieMHXX7qSWLjRG3rZ+rYtl00dcQJYdf6 NNnCEKyp3Ipj4d7nKOSV2bb/9DRd7Lw4gcgN4vEyLi0SGZQffA6woU5hVz739fKihtVf xcSg== 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=rj/ZuT6rRUqkCi64K7g6cOQC3JoNu26m/U7gOJbqdH8=; b=qSUOq0P41TI3WbsUA/IjK8jHXl7Ox/4QN5JY17YBjPzxfm1otBSNFMGPGX3XrlZc3Q Jn33pwN4KyDuj80P6cXmYqobG+WfkVPChba0ks/+g4mmLC7qELx/WL/NpdQ50zoLvChn 9a/iHeHBcadvpIw0o8akFcjW3KZ0HoFKJpX3mVVVSCojKU1MMwpFBlmefka+eYW3A2XQ XRHygAtjfXq9jhfrMQDrt9h47NJTfM8sfo7v9321iBKOYlHrYBdy1hXVFN5PcCo5svUV s7Smw6h7zEGBPfCGGyArq8w7lsx9bpJpfO9lAAEdE5/3X/TgSKPQRWoItdp4DSVW6Lq/ P5QQ== X-Gm-Message-State: AHPjjUgwnALjqGCH09mFI92TIWV8u3CiyT/SRX4ySNmwedu/xZkWoniv q7GTu5i3RIjSfz9H3YzZ30FIe6dxBnp1IAebD796Wnau X-Google-Smtp-Source: AOwi7QBHkR9tlujqVO7R8+z2DfZGPulkSUGDk9mvG2xHT6iXUB37NbNRl2JxxI6tdcOteqHxeSekX/zCUiHORQkceaA= X-Received: by 10.223.164.206 with SMTP id h14mr5719743wrb.25.1506646609282; Thu, 28 Sep 2017 17:56:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.238.142 with HTTP; Thu, 28 Sep 2017 17:56:48 -0700 (PDT) In-Reply-To: <8cd473c06a33c360db774a428a030833@megadrive.org> References: <20170928011129.GC86601@home.opsec.eu> <1506561886.31939.16.camel@freebsd.org> <20170928105724.b76168c5065ebb388b056f51@bidouilliste.com> <8cd473c06a33c360db774a428a030833@megadrive.org> From: Guy Yur Date: Fri, 29 Sep 2017 03:56:48 +0300 Message-ID: Subject: Re: if_awg fixes To: Emmanuel Vadot Cc: Ian Lepore , Kurt Jaeger , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 00:56:51 -0000 On 28 September 2017 at 22:13, Emmanuel Vadot wrote: > On 2017-09-28 21:10, Guy Yur wrote: >> >> Hi, >> >> I created a phabricator account and four diffs. >> >> https://reviews.freebsd.org/D12535 >> https://reviews.freebsd.org/D12536 >> https://reviews.freebsd.org/D12537 >> https://reviews.freebsd.org/D12538 >> >> ... >> >> Thanks, >> Guy > > > Thanks a lot, I will not have time to look at them before next week. Will > probably look at them on monday. > > > -- > Emmanuel Vadot Thanks. I updated D12537. It appears that tx interrupt should only be requested on the last segment otherwise the card won't issue it. In a scenario where every 64th frame is not the last segment of a frame there will never be a tx interrupt triggered. My changes included only doing tx drain on TX_INT while original code also drains on TX_BUF_UA_INT. So no TX_INTs issued lead to full queue never clearing. Without my changes tx queue won't be stuck but drain will need to run on the full queue in the above scenario not just the last 64 buffers. if_vr has the same behavior of setting the flag only on last segment. Seems stable so far with ssh on constant output loop. Also added review for draining tx buffers and clearing rx buffers on stop. https://reviews.freebsd.org/D12539 -- Guy