From ganbold at gmail.com  Mon Sep  1 12:33:23 2014
From: ganbold at gmail.com (Ganbold Tsagaankhuu)
Date: Mon, 1 Sep 2014 20:33:22 +0800
Subject: U-boot for Banana Pi
In-Reply-To: <540348DD.3090406@toomeek.waw.pl>
References: <53EE0F93.6060407@toomeek.waw.pl> <53EE23B1.2020403@toomeek.waw.pl>
 <CAGtf9xNTsQg-WKMu+RqNmF3W=vKm8ccvNdcL1VKm9gWwRohsTw@mail.gmail.com>
 <53EE402D.8000204@toomeek.waw.pl>
 <20140815214416.GJ60808@cicely7.cicely.de>
 <53EFCD6C.5000601@toomeek.waw.pl> <53EFD5D5.7010406@toomeek.waw.pl>
 <53F0E640.5030506@toomeek.waw.pl> <53F14BD7.1050007@fukaumi.org>
 <53F1A126.1020408@toomeek.waw.pl> <53F1D8FD.9010903@fukaumi.org>
 <53F27EB9.3090805@toomeek.waw.pl>
 <CAGtf9xNw8EAakGLpYL+xi20QdOYZQMg=_A-QtriU5kqY2jLBUA@mail.gmail.com>
 <54031BC8.8020407@toomeek.waw.pl> <540348DD.3090406@toomeek.waw.pl>
Message-ID: <CAGtf9xNkSNQr9t1ebKFZ-8LE-EE-SGOZJDxFGgjb4UT-XCyjfQ@mail.gmail.com>

On Mon, Sep 1, 2014 at 12:10 AM, TooMeeK Admin <maps at toomeek.waw.pl> wrote:

> Reinstalled FreeBSD 10 64-bit from scratch.. fully updated..
> /usr/src/sys/boot/fdt/dts/cubieboard2.dts contains 512MB addressing, so
> it cannot be right..
> The same at:
> ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/
> 10.0-RELEASE/src.txz
> They are simply - outdated.
>
> Wiki page doesn't say where sources are, just:
> "1. Get FreeBSD head"
> So what sources You're using to build Cubieboard2 kernel?
>
> But anyway I found answer here:
> https://lists.freebsd.org/pipermail/freebsd-arm/2013-August/006201.html
> and changed Banana Pi files accordinately:
> file: a10_machdep.c
> change at: initarm_late_init
> adding: unmapped_buf_allowed = 0;
>
> I'm running 1GB of memory now.
> But no networking, no HDMI output.
> Added 1Gbit GMAC driver to BANANAPI config and /boot/loader.conf:
> miibus_load="YES"
> if_gem_load="YES"
> but still getting only lo0.
> Login prompt works.
>
> So.. how You did it working, Ganbold ?
>


There is no support (no driver) yet for A20 GMAC controller as well as hdmi.

Ganbold



>
> Best regards,
> TooMeeK
>
>
>
>> What is in Your /usr/src/sys/boot/fdt/dts/cubieboard2.dts file, section
>> memory?
>>
>> Best regards,
>> TooMeeK
>>
>> W dniu 2014-08-27 14:53, Ganbold Tsagaankhuu pisze:
>>
>>>
>>>
>>>
>>> I've just got Banana PI today, and I confirm that Cubieboard2 kernel
>>> works just fine detecting 1GB RAM and booting to multi user mode. I run
>>> recent Current of course.
>>>
>>> Ganbold
>>>
>>>
>>>
>> _______________________________________________
>> freebsd-arm at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>>
>>
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>

From freebsd.asc at strcmp.org  Mon Sep  1 14:18:06 2014
From: freebsd.asc at strcmp.org (Andreas Schwarz)
Date: Mon, 1 Sep 2014 16:17:53 +0200
Subject: U-boot for Banana Pi
In-Reply-To: <54036970.9040503@toomeek.waw.pl>
References: <53EE0F93.6060407@toomeek.waw.pl> <53EE23B1.2020403@toomeek.waw.pl>
 <CAGtf9xNTsQg-WKMu+RqNmF3W=vKm8ccvNdcL1VKm9gWwRohsTw@mail.gmail.com>
 <53EE402D.8000204@toomeek.waw.pl>
 <20140815214416.GJ60808@cicely7.cicely.de>
 <53EFCD6C.5000601@toomeek.waw.pl> <53EFD5D5.7010406@toomeek.waw.pl>
 <53F0E640.5030506@toomeek.waw.pl> <53F14BD7.1050007@fukaumi.org>
 <53F1A126.1020408@toomeek.waw.pl> <53F1D8FD.9010903@fukaumi.org>
 <53F27EB9.3090805@toomeek.waw.pl>
 <CAGtf9xNw8EAakGLpYL+xi20QdOYZQMg=_A-QtriU5kqY2jLBUA@mail.gmail.com>
 <54031BC8.8020407@toomeek.waw.pl> <540348DD.3090406@toomeek.waw.pl>
 <20140831181954.499135cfbffb3266d7ce69ab@schwarzes.net>
 <54036970.9040503@toomeek.waw.pl>
Message-ID: <20140901161753.042f46918777774d313272b0@strcmp.org>

On Sun, 31 Aug 2014 20:29:04 +0200
TooMeeK Admin <maps at toomeek.waw.pl> wrote:

> Thanks,
> 
> I didn't used this tool before. How to resolve conflicts?
> ....
> Tree conflict on '/usr/src/COPYRIGHT'
>     > local file unversioned, incoming file add upon update
> Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: h
> 
>    (r)  - accept current working copy state
>    (p)  - resolve the conflict later  [postpone]
>    (q)  - postpone all remaining conflicts
>    (h)  - show this help (also '?')
> 
> Should I type "r" here?
> If yes, then I still have obsolete versions, example:
> /usr/src/sys/boot/fdt/dts/cubieboard2.dts
> doesn't match:
> http://svn.freebsd.org/base/head/sys/boot/fdt/dts/arm/cubieboard2.dts

I've not expected that you have already an existing copy in /usr/src (probably 
the 10 release). To avoid problems, please do the checkout and update in a clean 
dir and then add your modifications.

-- 
best regards
Andreas


From maps at toomeek.waw.pl  Tue Sep  2 00:09:23 2014
From: maps at toomeek.waw.pl (TooMeeK Admin)
Date: Tue, 02 Sep 2014 02:09:05 +0200
Subject: U-boot for Banana Pi
In-Reply-To: <CAGtf9xNkSNQr9t1ebKFZ-8LE-EE-SGOZJDxFGgjb4UT-XCyjfQ@mail.gmail.com>
References: <53EE0F93.6060407@toomeek.waw.pl>	<53EE23B1.2020403@toomeek.waw.pl>	<CAGtf9xNTsQg-WKMu+RqNmF3W=vKm8ccvNdcL1VKm9gWwRohsTw@mail.gmail.com>	<53EE402D.8000204@toomeek.waw.pl>	<20140815214416.GJ60808@cicely7.cicely.de>	<53EFCD6C.5000601@toomeek.waw.pl>	<53EFD5D5.7010406@toomeek.waw.pl>	<53F0E640.5030506@toomeek.waw.pl>	<53F14BD7.1050007@fukaumi.org>	<53F1A126.1020408@toomeek.waw.pl>	<53F1D8FD.9010903@fukaumi.org>	<53F27EB9.3090805@toomeek.waw.pl>	<CAGtf9xNw8EAakGLpYL+xi20QdOYZQMg=_A-QtriU5kqY2jLBUA@mail.gmail.com>	<54031BC8.8020407@toomeek.waw.pl>	<540348DD.3090406@toomeek.waw.pl>
 <CAGtf9xNkSNQr9t1ebKFZ-8LE-EE-SGOZJDxFGgjb4UT-XCyjfQ@mail.gmail.com>
Message-ID: <54050AA1.4050908@toomeek.waw.pl>

Uh :(
That's sad.

The main purpuse of this thread was to port FreeBSD 10.0 OS for Banana 
Pi as base for great pfSense OS..
..as this is very good base for low power, low cost, high performance 
router..
Shame there's no 1Gbit driver yet. I suppose running EMAC driver at 
100Mbit won't work too.

Case closed, goes to archive X...
Thank You all for clues and help.

Best regards,
TooMeeK

W dniu 2014-09-01 14:33, Ganbold Tsagaankhuu pisze:
>
>
> There is no support (no driver) yet for A20 GMAC controller as well as 
> hdmi.
>
> Ganbold
>
>


From perretcantonim at gmail.com  Wed Sep  3 22:11:18 2014
From: perretcantonim at gmail.com (=?UTF-8?Q?Mat=C3=ADas_Perret_Cantoni?=)
Date: Wed, 3 Sep 2014 19:11:15 -0300
Subject: address dependent code?
Message-ID: <CADLKG01UUdz4M-VDVk3oYeUepiB14nf3vHmNimR5okuhZZzixw@mail.gmail.com>

Hello! I've found that for compiling ubldr I need to specify the address
where it will be loaded and executed, and I'd like to know more about this.
It's the first time I find that I need to specify a physical address on
compile time.

I'm sure it's kind of a whole specific programming field, so can you point
out some material that I can read about this? Any info about this will be
appreciated!

Thanks in advance.

Regards, Matias.

From ian at FreeBSD.org  Wed Sep  3 22:30:12 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Wed, 03 Sep 2014 16:30:09 -0600
Subject: address dependent code?
In-Reply-To: <CADLKG01UUdz4M-VDVk3oYeUepiB14nf3vHmNimR5okuhZZzixw@mail.gmail.com>
References: <CADLKG01UUdz4M-VDVk3oYeUepiB14nf3vHmNimR5okuhZZzixw@mail.gmail.com>
Message-ID: <1409783409.1150.297.camel@revolution.hippie.lan>

On Wed, 2014-09-03 at 19:11 -0300, Mat?as Perret Cantoni wrote:
> Hello! I've found that for compiling ubldr I need to specify the address
> where it will be loaded and executed, and I'd like to know more about this.
> It's the first time I find that I need to specify a physical address on
> compile time.
> 
> I'm sure it's kind of a whole specific programming field, so can you point
> out some material that I can read about this? Any info about this will be
> appreciated!
> 
> Thanks in advance.
> 
> Regards, Matias.

The kernel also needs to be compiled to load at a specific address, but
you don't have to set it manually because it's hard-coded in the
std.soctype file for each chip.  In the case of ubldr, it's because
u-boot doesn't know how to do relocation, it can only load an image that
is pre-linked to run at a fixed address.  ubldr isn't built along with
the kernel, so there's nowhere to configure the load address on a
per-system basis, it has to be provided manually.

-- Ian



From erichsfreebsdlist at alogt.com  Thu Sep  4 10:11:46 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Thu, 4 Sep 2014 18:11:29 +0800
Subject: buildworld on a Raspberry
Message-ID: <20140904181129.5d38c1ef@X220.alogt.com>

Hi,

did anybody do a buildworld on the device itself?

How long will it take?

I estimate that it could take some days.

Erich

From erichsfreebsdlist at alogt.com  Thu Sep  4 11:28:44 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Thu, 4 Sep 2014 19:28:31 +0800
Subject: buildworld on a Raspberry
In-Reply-To: <20140904.201648.1532098598554690924.shigeru@os-hackers.jp>
References: <20140904181129.5d38c1ef@X220.alogt.com>
 <20140904.201648.1532098598554690924.shigeru@os-hackers.jp>
Message-ID: <20140904192831.5f483f3c@X220.alogt.com>

Hi,

On Thu, 04 Sep 2014 20:16:48 +0900 (JST)
YAMAMOTO Shigeru <shigeru at os-hackers.jp> wrote:

> >>>>> "Erich" == Erich Dollansky <erichsfreebsdlist at alogt.com> writes:
> Erich> Hi, did anybody do a buildworld on the device itself?
> Erich> How long will it take?
> Erich> I estimate that it could take some days.
> 
> I do sometime buildworld on RasbperryPi Type B.
> I use external USB HDD for work area.
> 
this is what I plan to do too after my initial tests and getting a bit
used to the device.

> In my case, a time for buildworld is 3 or 4 days.

This sounds much more like it. With other words, as long as I cannot
make sure that the machine can run for a week, I should not bother to
start building it on the device itself.

Erich

From shigeru at os-hackers.jp  Thu Sep  4 11:38:06 2014
From: shigeru at os-hackers.jp (YAMAMOTO Shigeru)
Date: Thu, 04 Sep 2014 20:16:48 +0900 (JST)
Subject: buildworld on a Raspberry
In-Reply-To: <20140904181129.5d38c1ef@X220.alogt.com>
References: <20140904181129.5d38c1ef@X220.alogt.com>
Message-ID: <20140904.201648.1532098598554690924.shigeru@os-hackers.jp>


Hi,

>>>>> "Erich" == Erich Dollansky <erichsfreebsdlist at alogt.com> writes:
Erich> Hi, did anybody do a buildworld on the device itself?
Erich> How long will it take?
Erich> I estimate that it could take some days.

I do sometime buildworld on RasbperryPi Type B.
I use external USB HDD for work area.

In my case, a time for buildworld is 3 or 4 days.

Thanks,
---
YAMAMOTO Shigeru <shigeru at os-hackers.jp>

From koverat at freemail.hu  Thu Sep  4 11:42:25 2014
From: koverat at freemail.hu (Kover Attila)
Date: Thu, 4 Sep 2014 13:42:22 +0200 (CEST)
Subject: buildworld on a Raspberry
Message-ID: <freemail.20140904134222.7093.1@fmxmldata07.freemail.hu>

 Hi, I made a self hosted image in April this year with HEAD r246986 on my PI-B, here is the relevant information (date is in yyyy.mm.dd hh:mm:ss format ): ***** DEBUG * 2014.04.27. 00:33:32 * buildworld begins
--
247588.40 real 155340.16 user 15553.08 sys
***** DEBUG * 2014.04.29. 21:20:00 * buildkernel begins
--
20382.90 real 11168.55 user 1936.28 sys
***** DEBUG * 2014.04.30. 02:59:43 * installkernel begins
--
459.26 real 60.40 user 69.29 sys
***** DEBUG * 2014.04.30. 03:07:22 * READY 1/3RegardsAttila
 > Hi,> did anybody do a buildworld on the device itself?> How long will it take?> I estimate that it could take some days.> Erich
 

From erichsfreebsdlist at alogt.com  Thu Sep  4 14:05:31 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Thu, 4 Sep 2014 22:05:23 +0800
Subject: buildworld on a Raspberry
In-Reply-To: <20140904.201648.1532098598554690924.shigeru@os-hackers.jp>
References: <20140904181129.5d38c1ef@X220.alogt.com>
 <20140904.201648.1532098598554690924.shigeru@os-hackers.jp>
Message-ID: <20140904220523.5e1a482f@X220.alogt.com>

Hi,

you wrote recently that your own kernel works with a Raspberry but not
the kernel from FreeBSD itself. You believe the old firmware might
be the problem.

I did not some tests. Of course, the kernel downloaded from your site
works. When I installed my own kernel with revision 271057 (from this
morning), I still do not get a running image.

I did these tests and all failed:

Use your firmware with the new kernel,
Use your kernel with the firmware from the new kernel.

The image works the moment I use the new kernel but copy your /boot and
your files from the FAT to the media.

My problem is that I lost my monitor cable and I am currently at a
location where they do not sell such things. So, all I can tell is that
an image comes to the state when I can log-on remotely.

The log files show always that ue0 is not recognised when the image
fails.

Do you have any idea what is wrong?

Erich

On Thu, 04 Sep 2014 20:16:48 +0900 (JST) YAMAMOTO Shigeru
<shigeru at os-hackers.jp> wrote:

> 
> Hi,
> 
> >>>>> "Erich" == Erich Dollansky <erichsfreebsdlist at alogt.com> writes:
> Erich> Hi, did anybody do a buildworld on the device itself?
> Erich> How long will it take?
> Erich> I estimate that it could take some days.
> 
> I do sometime buildworld on RasbperryPi Type B.
> I use external USB HDD for work area.
> 
> In my case, a time for buildworld is 3 or 4 days.
> 
> Thanks,
> ---
> YAMAMOTO Shigeru <shigeru at os-hackers.jp>


From freebsd.asc at strcmp.org  Thu Sep  4 15:30:14 2014
From: freebsd.asc at strcmp.org (Andreas Schwarz)
Date: Thu, 4 Sep 2014 17:29:47 +0200
Subject: buildworld on a Raspberry
In-Reply-To: <20140904181129.5d38c1ef@X220.alogt.com>
References: <20140904181129.5d38c1ef@X220.alogt.com>
Message-ID: <20140904172947.0ee838ae0249c80fdcbae3c2@strcmp.org>

On Thu, 4 Sep 2014 18:11:29 +0800
Erich Dollansky <erichsfreebsdlist at alogt.com> wrote:

Hi Erich,

> did anybody do a buildworld on the device itself?

I do this regularly, I've two RPI, one for "production" and
the other one for building and testing.

> How long will it take?

Depends on you setup (a little bit), I'm using tmpfs for /tmp and 
/var/tmp and there is also a difference with different SD Cards (some
of them are up to 50% faster).

My experiences :

  make kernel-toolchain : 1.5 days
  
  make buildkernel : 0.5 days

  make buildworld : 2 days


-- 
best regards
Andreas

From che at bein.link  Fri Sep  5 21:41:44 2014
From: che at bein.link (Maxim V FIlimonov)
Date: Sat, 06 Sep 2014 01:41:40 +0400
Subject: Cubieboard: load average above 2
Message-ID: <27116175.UDSoyStjsX@quad>

Recently, I installed FreeBSD-current to my Cubieboard2:
root at cubie:~ # uname -a
FreeBSD cubie 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r271182M: Sat Sep  6 
01:17:28 MSK 2014     root at quad:/usr/obj/arm.armv6/home/che/freebsd-
src/head/sys/CUBIEBOARD2  arm

And the system's load average keeps being above 2:
root at cubie:~ # uptime 
 8:31PM  up 19 mins, 1 user, load averages: 2.36, 1.89, 1.32

Everything is not really slow, but sometimes takes time.
What could be the problem here? What can I do with that?
-- 
wbr, Maxim Filimonov
che at bein.link

From che at bein.link  Fri Sep  5 21:43:33 2014
From: che at bein.link (Maxim V FIlimonov)
Date: Sat, 06 Sep 2014 01:43:23 +0400
Subject: Cubieboard: Spurious interrupt detected
Message-ID: <2279481.3MX4OEDuCl@quad>

And another problem: every now and then the kernel says something like that:
Sep  5 19:22:37  kernel: Spurious interrupt detected
Sep  5 19:22:37  kernel: Spurious interrupt detected
Sep  5 19:23:46  last message repeated 10 times

I've heard that FreeBSD happens to do that on ARM devices. What could be the 
problem here?
-- 
wbr, Maxim Filimonov
che at bein.link

From ticso at cicely7.cicely.de  Fri Sep  5 21:57:14 2014
From: ticso at cicely7.cicely.de (Bernd Walter)
Date: Fri, 5 Sep 2014 23:57:02 +0200
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <2279481.3MX4OEDuCl@quad>
References: <2279481.3MX4OEDuCl@quad>
Message-ID: <20140905215702.GL3196@cicely7.cicely.de>

On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote:
> And another problem: every now and then the kernel says something like that:
> Sep  5 19:22:37  kernel: Spurious interrupt detected
> Sep  5 19:22:37  kernel: Spurious interrupt detected
> Sep  5 19:23:46  last message repeated 10 times
> 
> I've heard that FreeBSD happens to do that on ARM devices. What could be the 
> problem here?

Means something generates inetrrupts, which are not handled by a driver.
Could be the cause for your load problem too.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

From che at bein.link  Fri Sep  5 22:02:33 2014
From: che at bein.link (Maxim V FIlimonov)
Date: Sat, 06 Sep 2014 02:02:29 +0400
Subject: Cubieboard: load average above 2
In-Reply-To: <20140905215555.GK3196@cicely7.cicely.de>
References: <27116175.UDSoyStjsX@quad>
 <20140905215555.GK3196@cicely7.cicely.de>
Message-ID: <6780316.UDbfH4Htdv@quad>

On Friday 05 September 2014 23:55:55 you wrote:
> On Sat, Sep 06, 2014 at 01:41:40AM +0400, Maxim V FIlimonov wrote:
> > Recently, I installed FreeBSD-current to my Cubieboard2:
> > root at cubie:~ # uname -a
> > FreeBSD cubie 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r271182M: Sat Sep  6
> > 01:17:28 MSK 2014     root at quad:/usr/obj/arm.armv6/home/che/freebsd-
> > src/head/sys/CUBIEBOARD2  arm
> > 
> > And the system's load average keeps being above 2:
> > root at cubie:~ # uptime
> > 
> >  8:31PM  up 19 mins, 1 user, load averages: 2.36, 1.89, 1.32
> > 
> > Everything is not really slow, but sometimes takes time.
> > What could be the problem here? What can I do with that?
> 
> top -SH is the first thing I do to find what's consuming CPU.
> Note that an idle thread consuming CPU means it's really idling.

It shows about 200% idle and about 0.5% per task for other tasks. That's 
weird.

-- 
wbr, Maxim Filimonov
che at bein.link

From ticso at cicely7.cicely.de  Fri Sep  5 22:03:18 2014
From: ticso at cicely7.cicely.de (Bernd Walter)
Date: Fri, 5 Sep 2014 23:55:55 +0200
Subject: Cubieboard: load average above 2
In-Reply-To: <27116175.UDSoyStjsX@quad>
References: <27116175.UDSoyStjsX@quad>
Message-ID: <20140905215555.GK3196@cicely7.cicely.de>

On Sat, Sep 06, 2014 at 01:41:40AM +0400, Maxim V FIlimonov wrote:
> Recently, I installed FreeBSD-current to my Cubieboard2:
> root at cubie:~ # uname -a
> FreeBSD cubie 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r271182M: Sat Sep  6 
> 01:17:28 MSK 2014     root at quad:/usr/obj/arm.armv6/home/che/freebsd-
> src/head/sys/CUBIEBOARD2  arm
> 
> And the system's load average keeps being above 2:
> root at cubie:~ # uptime 
>  8:31PM  up 19 mins, 1 user, load averages: 2.36, 1.89, 1.32
> 
> Everything is not really slow, but sometimes takes time.
> What could be the problem here? What can I do with that?

top -SH is the first thing I do to find what's consuming CPU.
Note that an idle thread consuming CPU means it's really idling.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

From che at bein.link  Fri Sep  5 22:08:24 2014
From: che at bein.link (Maxim V FIlimonov)
Date: Sat, 06 Sep 2014 02:08:22 +0400
Subject: Cubieboard: load average above 2
In-Reply-To: <20140905215555.GK3196@cicely7.cicely.de>
References: <27116175.UDSoyStjsX@quad>
 <20140905215555.GK3196@cicely7.cicely.de>
Message-ID: <6240427.cmkfEefv07@quad>

On Friday 05 September 2014 23:55:55 Bernd Walter wrote:
> On Sat, Sep 06, 2014 at 01:41:40AM +0400, Maxim V FIlimonov wrote:
> > Recently, I installed FreeBSD-current to my Cubieboard2:
> > root at cubie:~ # uname -a
> > FreeBSD cubie 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r271182M: Sat Sep  6
> > 01:17:28 MSK 2014     root at quad:/usr/obj/arm.armv6/home/che/freebsd-
> > src/head/sys/CUBIEBOARD2  arm
> > 
> > And the system's load average keeps being above 2:
> > root at cubie:~ # uptime
> > 
> >  8:31PM  up 19 mins, 1 user, load averages: 2.36, 1.89, 1.32
> > 
> > Everything is not really slow, but sometimes takes time.
> > What could be the problem here? What can I do with that?
> 
> top -SH is the first thing I do to find what's consuming CPU.
> Note that an idle thread consuming CPU means it's really idling.

I took away I2C support from the kernel config, and now LA is about 1.3 which 
is also a bit too much, but not that big, AFAIK. Could i2c be the problem 
here?
-- 
wbr, Maxim Filimonov
che at bein.link

From ian at FreeBSD.org  Fri Sep  5 23:12:05 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Fri, 05 Sep 2014 17:11:56 -0600
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <20140905215702.GL3196@cicely7.cicely.de>
References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de>
Message-ID: <1409958716.1150.321.camel@revolution.hippie.lan>

On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote:
> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote:
> > And another problem: every now and then the kernel says something like that:
> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> > Sep  5 19:23:46  last message repeated 10 times
> > 
> > I've heard that FreeBSD happens to do that on ARM devices. What could be the 
> > problem here?
> 
> Means something generates inetrrupts, which are not handled by a driver.
> Could be the cause for your load problem too.
> 

No, that would be stray interrupts.  Spurious interrupts happen when an
interrupt is asserted, but by time the processor asks the interrupt
controller for the current active interrupt, it is no longer active. 

One way it can happen is when an interrupt handler writes to a device to
clear a pending interrupt and that write takes a long time to complete
because the device is on a slow bus, and the interrupt controller is on
a faster bus.  The EOI to the controller outraces the device write that
would clear the pending interrupt condition, so the processor is
re-interrupted, but by time it asks for the next active interrupt the
device write has finally completed and the interrupt is no longer
pending.

That sequence used to happen a lot, and it was "fixed" by adding an
l2cache sync (basically a "drain write buffer") just before an EOI.  You
sometimes still see an occasional spurious interrupt, but it shouldn't
be happening multiple times per second as seen in the logging above.

-- Ian



From adrian at freebsd.org  Sat Sep  6 00:44:36 2014
From: adrian at freebsd.org (Adrian Chadd)
Date: Fri, 5 Sep 2014 17:44:34 -0700
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <1409958716.1150.321.camel@revolution.hippie.lan>
References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de>
 <1409958716.1150.321.camel@revolution.hippie.lan>
Message-ID: <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>

On 5 September 2014 16:11, Ian Lepore <ian at freebsd.org> wrote:
> On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote:
>> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote:
>> > And another problem: every now and then the kernel says something like that:
>> > Sep  5 19:22:37  kernel: Spurious interrupt detected
>> > Sep  5 19:22:37  kernel: Spurious interrupt detected
>> > Sep  5 19:23:46  last message repeated 10 times
>> >
>> > I've heard that FreeBSD happens to do that on ARM devices. What could be the
>> > problem here?
>>
>> Means something generates inetrrupts, which are not handled by a driver.
>> Could be the cause for your load problem too.
>>
>
> No, that would be stray interrupts.  Spurious interrupts happen when an
> interrupt is asserted, but by time the processor asks the interrupt
> controller for the current active interrupt, it is no longer active.
>
> One way it can happen is when an interrupt handler writes to a device to
> clear a pending interrupt and that write takes a long time to complete
> because the device is on a slow bus, and the interrupt controller is on
> a faster bus.  The EOI to the controller outraces the device write that
> would clear the pending interrupt condition, so the processor is
> re-interrupted, but by time it asks for the next active interrupt the
> device write has finally completed and the interrupt is no longer
> pending.
>
> That sequence used to happen a lot, and it was "fixed" by adding an
> l2cache sync (basically a "drain write buffer") just before an EOI.  You
> sometimes still see an occasional spurious interrupt, but it shouldn't
> be happening multiple times per second as seen in the logging above.

Hm, interesting. I remember your discussion about it on IRC. The
atheros code ends up working around this in the driver by doing a read
from the ISR after writing out bits to clear things, so the clear is
flushed out.

I wonder if we should be asking all device drivers to be doing their
own ISR flushing before returning from their interrupt handlers.


-a

From ian at FreeBSD.org  Sat Sep  6 01:13:06 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Fri, 05 Sep 2014 19:13:00 -0600
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>
References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de>
 <1409958716.1150.321.camel@revolution.hippie.lan>
 <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>
Message-ID: <1409965980.1150.327.camel@revolution.hippie.lan>

On Fri, 2014-09-05 at 17:44 -0700, Adrian Chadd wrote:
> On 5 September 2014 16:11, Ian Lepore <ian at freebsd.org> wrote:
> > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote:
> >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote:
> >> > And another problem: every now and then the kernel says something like that:
> >> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> >> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> >> > Sep  5 19:23:46  last message repeated 10 times
> >> >
> >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the
> >> > problem here?
> >>
> >> Means something generates inetrrupts, which are not handled by a driver.
> >> Could be the cause for your load problem too.
> >>
> >
> > No, that would be stray interrupts.  Spurious interrupts happen when an
> > interrupt is asserted, but by time the processor asks the interrupt
> > controller for the current active interrupt, it is no longer active.
> >
> > One way it can happen is when an interrupt handler writes to a device to
> > clear a pending interrupt and that write takes a long time to complete
> > because the device is on a slow bus, and the interrupt controller is on
> > a faster bus.  The EOI to the controller outraces the device write that
> > would clear the pending interrupt condition, so the processor is
> > re-interrupted, but by time it asks for the next active interrupt the
> > device write has finally completed and the interrupt is no longer
> > pending.
> >
> > That sequence used to happen a lot, and it was "fixed" by adding an
> > l2cache sync (basically a "drain write buffer") just before an EOI.  You
> > sometimes still see an occasional spurious interrupt, but it shouldn't
> > be happening multiple times per second as seen in the logging above.
> 
> Hm, interesting. I remember your discussion about it on IRC. The
> atheros code ends up working around this in the driver by doing a read
> from the ISR after writing out bits to clear things, so the clear is
> flushed out.
> 
> I wonder if we should be asking all device drivers to be doing their
> own ISR flushing before returning from their interrupt handlers.

That's a big job, it means modifying more or less every driver in the
system.  Quoting part of the comment block I added along with the fix:
        
        The right way to fix this problem is for every device driver to
        use the proper bus_space_barrier() calls in its interrupt
        handler.  For ARM a single barrier call at the end of the
        handler would work.  This would have to be done to every driver
        in the system, not just arm-specific drivers.  
        
        Another potential fix is to map all device memory as
        Strongly-Ordered rather than Device memory, which takes the
        store buffers out of the picture.  This has a pretty big impact
        on overall system performance, because each strongly ordered
        memory access causes all L2 store buffers to be drained.  
        
        A compromise solution is to have the interrupt controller
        implementation call this function to establish a barrier between
        writes to the interrupt-source device and writes to the
        interrupt controller device.  
        
        This takes the interrupt number as an argument, and currently
        doesn't use it.  The plan is that maybe some day there is a way
        to flag certain interrupts as "memory barrier safe" and we can
        avoid this overhead with them.  

-- Ian



From jmg at funkthat.com  Sat Sep  6 01:15:37 2014
From: jmg at funkthat.com (John-Mark Gurney)
Date: Fri, 5 Sep 2014 18:15:26 -0700
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>
References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de>
 <1409958716.1150.321.camel@revolution.hippie.lan>
 <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>
Message-ID: <20140906011526.GT82175@funkthat.com>

Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 17:44 -0700:
> On 5 September 2014 16:11, Ian Lepore <ian at freebsd.org> wrote:
> > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote:
> >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote:
> >> > And another problem: every now and then the kernel says something like that:
> >> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> >> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> >> > Sep  5 19:23:46  last message repeated 10 times
> >> >
> >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the
> >> > problem here?
> >>
> >> Means something generates inetrrupts, which are not handled by a driver.
> >> Could be the cause for your load problem too.
> >>
> >
> > No, that would be stray interrupts.  Spurious interrupts happen when an
> > interrupt is asserted, but by time the processor asks the interrupt
> > controller for the current active interrupt, it is no longer active.
> >
> > One way it can happen is when an interrupt handler writes to a device to
> > clear a pending interrupt and that write takes a long time to complete
> > because the device is on a slow bus, and the interrupt controller is on
> > a faster bus.  The EOI to the controller outraces the device write that
> > would clear the pending interrupt condition, so the processor is
> > re-interrupted, but by time it asks for the next active interrupt the
> > device write has finally completed and the interrupt is no longer
> > pending.
> >
> > That sequence used to happen a lot, and it was "fixed" by adding an
> > l2cache sync (basically a "drain write buffer") just before an EOI.  You
> > sometimes still see an occasional spurious interrupt, but it shouldn't
> > be happening multiple times per second as seen in the logging above.
> 
> Hm, interesting. I remember your discussion about it on IRC. The
> atheros code ends up working around this in the driver by doing a read
> from the ISR after writing out bits to clear things, so the clear is
> flushed out.
> 
> I wonder if we should be asking all device drivers to be doing their
> own ISR flushing before returning from their interrupt handlers.

This is required on PCI (that you do a read to clear the posted/pending
write)...    So, IMO, yes, all device drivers should do the proper
clearing of their writes to the ISR...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From ian at FreeBSD.org  Sat Sep  6 01:33:21 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Fri, 05 Sep 2014 19:33:17 -0600
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <20140906011526.GT82175@funkthat.com>
References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de>
 <1409958716.1150.321.camel@revolution.hippie.lan>
 <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>
 <20140906011526.GT82175@funkthat.com>
Message-ID: <1409967197.1150.339.camel@revolution.hippie.lan>

On Fri, 2014-09-05 at 18:15 -0700, John-Mark Gurney wrote:
> Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 17:44 -0700:
> > On 5 September 2014 16:11, Ian Lepore <ian at freebsd.org> wrote:
> > > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote:
> > >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote:
> > >> > And another problem: every now and then the kernel says something like that:
> > >> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> > >> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> > >> > Sep  5 19:23:46  last message repeated 10 times
> > >> >
> > >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the
> > >> > problem here?
> > >>
> > >> Means something generates inetrrupts, which are not handled by a driver.
> > >> Could be the cause for your load problem too.
> > >>
> > >
> > > No, that would be stray interrupts.  Spurious interrupts happen when an
> > > interrupt is asserted, but by time the processor asks the interrupt
> > > controller for the current active interrupt, it is no longer active.
> > >
> > > One way it can happen is when an interrupt handler writes to a device to
> > > clear a pending interrupt and that write takes a long time to complete
> > > because the device is on a slow bus, and the interrupt controller is on
> > > a faster bus.  The EOI to the controller outraces the device write that
> > > would clear the pending interrupt condition, so the processor is
> > > re-interrupted, but by time it asks for the next active interrupt the
> > > device write has finally completed and the interrupt is no longer
> > > pending.
> > >
> > > That sequence used to happen a lot, and it was "fixed" by adding an
> > > l2cache sync (basically a "drain write buffer") just before an EOI.  You
> > > sometimes still see an occasional spurious interrupt, but it shouldn't
> > > be happening multiple times per second as seen in the logging above.
> > 
> > Hm, interesting. I remember your discussion about it on IRC. The
> > atheros code ends up working around this in the driver by doing a read
> > from the ISR after writing out bits to clear things, so the clear is
> > flushed out.
> > 
> > I wonder if we should be asking all device drivers to be doing their
> > own ISR flushing before returning from their interrupt handlers.
> 
> This is required on PCI (that you do a read to clear the posted/pending
> write)...    So, IMO, yes, all device drivers should do the proper
> clearing of their writes to the ISR...
> 

But a driver can't assume that a read is sufficient on all architectures
it may run on.  bus_space_barrier() is the right way.  Also, it's not
just that a barrier is needed before exiting an isr... if the isr uses
locking to synchronize with hardware access by the non-isr part of the
driver, then the bus space barriers are needed in conjunction with the
locking, so that, for example, the isr's usage of the hardware is truly
complete before a lock is released.  

Scattered amongst 10 of the roughly 240 drivers in sys/dev there are 42
calls to bus_space_barrier().  Getting all the drivers fixed will be a
big job.  That's why I was thinking along the lines of an
architecture-wide workaround with potentially a way to mark a driver as
not needing the workaround once we get the fixing underway.

-- Ian



From jmg at funkthat.com  Sat Sep  6 04:54:15 2014
From: jmg at funkthat.com (John-Mark Gurney)
Date: Fri, 5 Sep 2014 21:54:03 -0700
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <1409967197.1150.339.camel@revolution.hippie.lan>
References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de>
 <1409958716.1150.321.camel@revolution.hippie.lan>
 <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>
 <20140906011526.GT82175@funkthat.com>
 <1409967197.1150.339.camel@revolution.hippie.lan>
Message-ID: <20140906045403.GU82175@funkthat.com>

Ian Lepore wrote this message on Fri, Sep 05, 2014 at 19:33 -0600:
> On Fri, 2014-09-05 at 18:15 -0700, John-Mark Gurney wrote:
> > Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 17:44 -0700:
> > > On 5 September 2014 16:11, Ian Lepore <ian at freebsd.org> wrote:
> > > > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote:
> > > >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote:
> > > >> > And another problem: every now and then the kernel says something like that:
> > > >> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> > > >> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> > > >> > Sep  5 19:23:46  last message repeated 10 times
> > > >> >
> > > >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the
> > > >> > problem here?
> > > >>
> > > >> Means something generates inetrrupts, which are not handled by a driver.
> > > >> Could be the cause for your load problem too.
> > > >>
> > > >
> > > > No, that would be stray interrupts.  Spurious interrupts happen when an
> > > > interrupt is asserted, but by time the processor asks the interrupt
> > > > controller for the current active interrupt, it is no longer active.
> > > >
> > > > One way it can happen is when an interrupt handler writes to a device to
> > > > clear a pending interrupt and that write takes a long time to complete
> > > > because the device is on a slow bus, and the interrupt controller is on
> > > > a faster bus.  The EOI to the controller outraces the device write that
> > > > would clear the pending interrupt condition, so the processor is
> > > > re-interrupted, but by time it asks for the next active interrupt the
> > > > device write has finally completed and the interrupt is no longer
> > > > pending.
> > > >
> > > > That sequence used to happen a lot, and it was "fixed" by adding an
> > > > l2cache sync (basically a "drain write buffer") just before an EOI.  You
> > > > sometimes still see an occasional spurious interrupt, but it shouldn't
> > > > be happening multiple times per second as seen in the logging above.
> > > 
> > > Hm, interesting. I remember your discussion about it on IRC. The
> > > atheros code ends up working around this in the driver by doing a read
> > > from the ISR after writing out bits to clear things, so the clear is
> > > flushed out.
> > > 
> > > I wonder if we should be asking all device drivers to be doing their
> > > own ISR flushing before returning from their interrupt handlers.
> > 
> > This is required on PCI (that you do a read to clear the posted/pending
> > write)...    So, IMO, yes, all device drivers should do the proper
> > clearing of their writes to the ISR...
> > 
> 
> But a driver can't assume that a read is sufficient on all architectures
> it may run on.  bus_space_barrier() is the right way.  Also, it's not

Except that I don't think even on PCI a bus_space_barrier is sufficient...

I was just looking at i386's implementation of bus_space_barrier and
it just does a stack access...  This won't be sufficient to clear any
PCI bridges that may have the write still pending...

There's also the issue that if __GNUCLIKE_ASM is not defined, the code
will compile w/o ANY barrier, not even a compiler_membar...  We should
probably add a #else #error please add your compilers equivalent...

> just that a barrier is needed before exiting an isr... if the isr uses
> locking to synchronize with hardware access by the non-isr part of the
> driver, then the bus space barriers are needed in conjunction with the
> locking, so that, for example, the isr's usage of the hardware is truly
> complete before a lock is released.  
> 
> Scattered amongst 10 of the roughly 240 drivers in sys/dev there are 42
> calls to bus_space_barrier().  Getting all the drivers fixed will be a
> big job.  That's why I was thinking along the lines of an
> architecture-wide workaround with potentially a way to mark a driver as
> not needing the workaround once we get the fixing underway.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From adrian at freebsd.org  Sat Sep  6 06:45:59 2014
From: adrian at freebsd.org (Adrian Chadd)
Date: Fri, 5 Sep 2014 23:45:57 -0700
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <20140906045403.GU82175@funkthat.com>
References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de>
 <1409958716.1150.321.camel@revolution.hippie.lan>
 <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>
 <20140906011526.GT82175@funkthat.com>
 <1409967197.1150.339.camel@revolution.hippie.lan>
 <20140906045403.GU82175@funkthat.com>
Message-ID: <CAJ-VmonPttv58SGziDda--GooyLJdCcsGXCzP-UyGkO5oO2i=Q@mail.gmail.com>

On 5 September 2014 21:54, John-Mark Gurney <jmg at funkthat.com> wrote:
> Ian Lepore wrote this message on Fri, Sep 05, 2014 at 19:33 -0600:
>> On Fri, 2014-09-05 at 18:15 -0700, John-Mark Gurney wrote:
>> > Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 17:44 -0700:
>> > > On 5 September 2014 16:11, Ian Lepore <ian at freebsd.org> wrote:
>> > > > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote:
>> > > >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote:
>> > > >> > And another problem: every now and then the kernel says something like that:
>> > > >> > Sep  5 19:22:37  kernel: Spurious interrupt detected
>> > > >> > Sep  5 19:22:37  kernel: Spurious interrupt detected
>> > > >> > Sep  5 19:23:46  last message repeated 10 times
>> > > >> >
>> > > >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the
>> > > >> > problem here?
>> > > >>
>> > > >> Means something generates inetrrupts, which are not handled by a driver.
>> > > >> Could be the cause for your load problem too.
>> > > >>
>> > > >
>> > > > No, that would be stray interrupts.  Spurious interrupts happen when an
>> > > > interrupt is asserted, but by time the processor asks the interrupt
>> > > > controller for the current active interrupt, it is no longer active.
>> > > >
>> > > > One way it can happen is when an interrupt handler writes to a device to
>> > > > clear a pending interrupt and that write takes a long time to complete
>> > > > because the device is on a slow bus, and the interrupt controller is on
>> > > > a faster bus.  The EOI to the controller outraces the device write that
>> > > > would clear the pending interrupt condition, so the processor is
>> > > > re-interrupted, but by time it asks for the next active interrupt the
>> > > > device write has finally completed and the interrupt is no longer
>> > > > pending.
>> > > >
>> > > > That sequence used to happen a lot, and it was "fixed" by adding an
>> > > > l2cache sync (basically a "drain write buffer") just before an EOI.  You
>> > > > sometimes still see an occasional spurious interrupt, but it shouldn't
>> > > > be happening multiple times per second as seen in the logging above.
>> > >
>> > > Hm, interesting. I remember your discussion about it on IRC. The
>> > > atheros code ends up working around this in the driver by doing a read
>> > > from the ISR after writing out bits to clear things, so the clear is
>> > > flushed out.
>> > >
>> > > I wonder if we should be asking all device drivers to be doing their
>> > > own ISR flushing before returning from their interrupt handlers.
>> >
>> > This is required on PCI (that you do a read to clear the posted/pending
>> > write)...    So, IMO, yes, all device drivers should do the proper
>> > clearing of their writes to the ISR...
>> >
>>
>> But a driver can't assume that a read is sufficient on all architectures
>> it may run on.  bus_space_barrier() is the right way.  Also, it's not
>
> Except that I don't think even on PCI a bus_space_barrier is sufficient...

It isn't.

The device itself may have FIFOs and internal busses that also need to
be flushed.

> I was just looking at i386's implementation of bus_space_barrier and
> it just does a stack access...  This won't be sufficient to clear any
> PCI bridges that may have the write still pending...

Right. The memory barrier semantics right now don't at all guarantee
that bus and device FIFOs have actually been flushed.

So I don't think doing it using the existing bus space barrier
semantics is 'right'. For interrupts, it's highly likely that we do
actually need device drivers to read from their interrupt register to
ensure the update has been posted before returning. That's better than
causing entire L2 cache flushes.

Question is - can we expose this somehow as a generic device method,
so the higher bus layers can actually do something with it, or should
we just leave it to device drivers to correctly do?

(Also - do any of the freebsd device driver books or the handbook mention this?)



-a

From adrian at freebsd.org  Sat Sep  6 06:46:51 2014
From: adrian at freebsd.org (Adrian Chadd)
Date: Fri, 5 Sep 2014 23:46:49 -0700
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <CAJ-VmonPttv58SGziDda--GooyLJdCcsGXCzP-UyGkO5oO2i=Q@mail.gmail.com>
References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de>
 <1409958716.1150.321.camel@revolution.hippie.lan>
 <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>
 <20140906011526.GT82175@funkthat.com>
 <1409967197.1150.339.camel@revolution.hippie.lan>
 <20140906045403.GU82175@funkthat.com>
 <CAJ-VmonPttv58SGziDda--GooyLJdCcsGXCzP-UyGkO5oO2i=Q@mail.gmail.com>
Message-ID: <CAJ-Vmo==B76P3NtrcedSCHrxHSU8DyOOXNEY=EWSTpTiag+VQw@mail.gmail.com>

seems not:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/driverbasics-net.html

 ... is very, very bare.

:(



-a

From jmg at funkthat.com  Sat Sep  6 07:11:06 2014
From: jmg at funkthat.com (John-Mark Gurney)
Date: Sat, 6 Sep 2014 00:10:55 -0700
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <CAJ-VmonPttv58SGziDda--GooyLJdCcsGXCzP-UyGkO5oO2i=Q@mail.gmail.com>
References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de>
 <1409958716.1150.321.camel@revolution.hippie.lan>
 <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>
 <20140906011526.GT82175@funkthat.com>
 <1409967197.1150.339.camel@revolution.hippie.lan>
 <20140906045403.GU82175@funkthat.com>
 <CAJ-VmonPttv58SGziDda--GooyLJdCcsGXCzP-UyGkO5oO2i=Q@mail.gmail.com>
Message-ID: <20140906071055.GW82175@funkthat.com>

Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 23:45 -0700:
> On 5 September 2014 21:54, John-Mark Gurney <jmg at funkthat.com> wrote:
> > Ian Lepore wrote this message on Fri, Sep 05, 2014 at 19:33 -0600:
> >> On Fri, 2014-09-05 at 18:15 -0700, John-Mark Gurney wrote:
> >> > Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 17:44 -0700:
> >> > > On 5 September 2014 16:11, Ian Lepore <ian at freebsd.org> wrote:
> >> > > > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote:
> >> > > >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote:
> >> > > >> > And another problem: every now and then the kernel says something like that:
> >> > > >> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> >> > > >> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> >> > > >> > Sep  5 19:23:46  last message repeated 10 times
> >> > > >> >
> >> > > >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the
> >> > > >> > problem here?
> >> > > >>
> >> > > >> Means something generates inetrrupts, which are not handled by a driver.
> >> > > >> Could be the cause for your load problem too.
> >> > > >>
> >> > > >
> >> > > > No, that would be stray interrupts.  Spurious interrupts happen when an
> >> > > > interrupt is asserted, but by time the processor asks the interrupt
> >> > > > controller for the current active interrupt, it is no longer active.
> >> > > >
> >> > > > One way it can happen is when an interrupt handler writes to a device to
> >> > > > clear a pending interrupt and that write takes a long time to complete
> >> > > > because the device is on a slow bus, and the interrupt controller is on
> >> > > > a faster bus.  The EOI to the controller outraces the device write that
> >> > > > would clear the pending interrupt condition, so the processor is
> >> > > > re-interrupted, but by time it asks for the next active interrupt the
> >> > > > device write has finally completed and the interrupt is no longer
> >> > > > pending.
> >> > > >
> >> > > > That sequence used to happen a lot, and it was "fixed" by adding an
> >> > > > l2cache sync (basically a "drain write buffer") just before an EOI.  You
> >> > > > sometimes still see an occasional spurious interrupt, but it shouldn't
> >> > > > be happening multiple times per second as seen in the logging above.
> >> > >
> >> > > Hm, interesting. I remember your discussion about it on IRC. The
> >> > > atheros code ends up working around this in the driver by doing a read
> >> > > from the ISR after writing out bits to clear things, so the clear is
> >> > > flushed out.
> >> > >
> >> > > I wonder if we should be asking all device drivers to be doing their
> >> > > own ISR flushing before returning from their interrupt handlers.
> >> >
> >> > This is required on PCI (that you do a read to clear the posted/pending
> >> > write)...    So, IMO, yes, all device drivers should do the proper
> >> > clearing of their writes to the ISR...
> >> >
> >>
> >> But a driver can't assume that a read is sufficient on all architectures
> >> it may run on.  bus_space_barrier() is the right way.  Also, it's not
> >
> > Except that I don't think even on PCI a bus_space_barrier is sufficient...
> 
> It isn't.
> 
> The device itself may have FIFOs and internal busses that also need to
> be flushed.

Partly this depends upon which bus the device is on...  Though we'd
like our drivers to be bus agnostic, items like these force them not
to be...

> > I was just looking at i386's implementation of bus_space_barrier and
> > it just does a stack access...  This won't be sufficient to clear any
> > PCI bridges that may have the write still pending...
> 
> Right. The memory barrier semantics right now don't at all guarantee
> that bus and device FIFOs have actually been flushed.
> 
> So I don't think doing it using the existing bus space barrier
> semantics is 'right'. For interrupts, it's highly likely that we do
> actually need device drivers to read from their interrupt register to
> ensure the update has been posted before returning. That's better than
> causing entire L2 cache flushes.
> 
> Question is - can we expose this somehow as a generic device method,
> so the higher bus layers can actually do something with it, or should
> we just leave it to device drivers to correctly do?

Sadly, I really think it's up to the device driver...  Are we going to
require the driver to expose a register that gets read before we EOI
the interrupt?  what if another bus does it differently?

> (Also - do any of the freebsd device driver books or the handbook mention this?)

Well, when I did a quick search, I found an HP Writing PCI Driver
guide...  Googled: "pci read after write isr" and the first link was:
http://h21007.www2.hp.com/portal/download/files/unprot/ddk/ddg/chap8.pdf

PCI Transaction Ordering - Write Side Effects

And I just checked the old D&I (haven't gotten my new one yet) and
it's device driver section is quite small and doesn't mention this
issue...  But it also doesn't talk about how to setup interrupts or
resources...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From jmg at funkthat.com  Sat Sep  6 07:14:41 2014
From: jmg at funkthat.com (John-Mark Gurney)
Date: Sat, 6 Sep 2014 00:14:32 -0700
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <CAJ-Vmo==B76P3NtrcedSCHrxHSU8DyOOXNEY=EWSTpTiag+VQw@mail.gmail.com>
References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de>
 <1409958716.1150.321.camel@revolution.hippie.lan>
 <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>
 <20140906011526.GT82175@funkthat.com>
 <1409967197.1150.339.camel@revolution.hippie.lan>
 <20140906045403.GU82175@funkthat.com>
 <CAJ-VmonPttv58SGziDda--GooyLJdCcsGXCzP-UyGkO5oO2i=Q@mail.gmail.com>
 <CAJ-Vmo==B76P3NtrcedSCHrxHSU8DyOOXNEY=EWSTpTiag+VQw@mail.gmail.com>
Message-ID: <20140906071432.GX82175@funkthat.com>

Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 23:46 -0700:
> seems not:
> 
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/driverbasics-net.html
> 
>  ... is very, very bare.
> 
> :(

You need to look at:
https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/pci.html

and:
https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/isa-driver-intr.html

At least there's a bit more info, but not much...

Device drivers are hard.. :(

That's why I don't use one for my ATSC tuner...  It's ethernet attached..

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From che at bein.link  Sat Sep  6 07:53:33 2014
From: che at bein.link (Maxim V FIlimonov)
Date: Sat, 06 Sep 2014 11:53:30 +0400
Subject: Cubieboard: load average above 2
In-Reply-To: <6240427.cmkfEefv07@quad>
References: <27116175.UDSoyStjsX@quad>
 <20140905215555.GK3196@cicely7.cicely.de> <6240427.cmkfEefv07@quad>
Message-ID: <1559689.QT1haudsVa@quad>

On Saturday 06 September 2014 02:08:22 Maxim V FIlimonov wrote:
> I took away I2C support from the kernel config, and now LA is about 1.3
> which is also a bit too much, but not that big, AFAIK. Could i2c be the
> problem here?

That's funny: after a couple of buildkernels without i2c support, the load 
average is over 2 again.
-- 
wbr, Maxim Filimonov
che at bein.link

From ian at FreeBSD.org  Sat Sep  6 14:54:34 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Sat, 06 Sep 2014 08:54:28 -0600
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <CAJ-VmonPttv58SGziDda--GooyLJdCcsGXCzP-UyGkO5oO2i=Q@mail.gmail.com>
References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de>
 <1409958716.1150.321.camel@revolution.hippie.lan>
 <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>
 <20140906011526.GT82175@funkthat.com>
 <1409967197.1150.339.camel@revolution.hippie.lan>
 <20140906045403.GU82175@funkthat.com>
 <CAJ-VmonPttv58SGziDda--GooyLJdCcsGXCzP-UyGkO5oO2i=Q@mail.gmail.com>
Message-ID: <1410015268.1150.351.camel@revolution.hippie.lan>

On Fri, 2014-09-05 at 23:45 -0700, Adrian Chadd wrote:
> On 5 September 2014 21:54, John-Mark Gurney <jmg at funkthat.com> wrote:
> > Ian Lepore wrote this message on Fri, Sep 05, 2014 at 19:33 -0600:
> >> On Fri, 2014-09-05 at 18:15 -0700, John-Mark Gurney wrote:
> >> > Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 17:44 -0700:
> >> > > On 5 September 2014 16:11, Ian Lepore <ian at freebsd.org> wrote:
> >> > > > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote:
> >> > > >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote:
> >> > > >> > And another problem: every now and then the kernel says something like that:
> >> > > >> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> >> > > >> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> >> > > >> > Sep  5 19:23:46  last message repeated 10 times
> >> > > >> >
> >> > > >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the
> >> > > >> > problem here?
> >> > > >>
> >> > > >> Means something generates inetrrupts, which are not handled by a driver.
> >> > > >> Could be the cause for your load problem too.
> >> > > >>
> >> > > >
> >> > > > No, that would be stray interrupts.  Spurious interrupts happen when an
> >> > > > interrupt is asserted, but by time the processor asks the interrupt
> >> > > > controller for the current active interrupt, it is no longer active.
> >> > > >
> >> > > > One way it can happen is when an interrupt handler writes to a device to
> >> > > > clear a pending interrupt and that write takes a long time to complete
> >> > > > because the device is on a slow bus, and the interrupt controller is on
> >> > > > a faster bus.  The EOI to the controller outraces the device write that
> >> > > > would clear the pending interrupt condition, so the processor is
> >> > > > re-interrupted, but by time it asks for the next active interrupt the
> >> > > > device write has finally completed and the interrupt is no longer
> >> > > > pending.
> >> > > >
> >> > > > That sequence used to happen a lot, and it was "fixed" by adding an
> >> > > > l2cache sync (basically a "drain write buffer") just before an EOI.  You
> >> > > > sometimes still see an occasional spurious interrupt, but it shouldn't
> >> > > > be happening multiple times per second as seen in the logging above.
> >> > >
> >> > > Hm, interesting. I remember your discussion about it on IRC. The
> >> > > atheros code ends up working around this in the driver by doing a read
> >> > > from the ISR after writing out bits to clear things, so the clear is
> >> > > flushed out.
> >> > >
> >> > > I wonder if we should be asking all device drivers to be doing their
> >> > > own ISR flushing before returning from their interrupt handlers.
> >> >
> >> > This is required on PCI (that you do a read to clear the posted/pending
> >> > write)...    So, IMO, yes, all device drivers should do the proper
> >> > clearing of their writes to the ISR...
> >> >
> >>
> >> But a driver can't assume that a read is sufficient on all architectures
> >> it may run on.  bus_space_barrier() is the right way.  Also, it's not
> >
> > Except that I don't think even on PCI a bus_space_barrier is sufficient...
> 
> It isn't.
> 
> The device itself may have FIFOs and internal busses that also need to
> be flushed.
> 

The question isn't whether or not it's sufficient, because it's
necessary.  The device driver knows what its hardware requirements are
and should meet them.  It doesn't not know what its parent bus
requirements are, and that's why it must call bus_space_barrier() to
handle architecture needs above the level of the device itself.

> > I was just looking at i386's implementation of bus_space_barrier and
> > it just does a stack access...  This won't be sufficient to clear any
> > PCI bridges that may have the write still pending...
> 
> Right. The memory barrier semantics right now don't at all guarantee
> that bus and device FIFOs have actually been flushed.
> 

The fact that some architectures don't implement bus_space_barrier() in
a way that's useful for that architecture is just a bug.  It doesn't
change the fact that bus_space_barrier() is currently our only defined
MI interface to barriers in device space.

> So I don't think doing it using the existing bus space barrier
> semantics is 'right'. For interrupts, it's highly likely that we do
> actually need device drivers to read from their interrupt register to
> ensure the update has been posted before returning. That's better than
> causing entire L2 cache flushes.
> 

Where did you see code that does an "entire L2 cache flush"?  You
didn't, you just saw a function name and made assumptions about what it
does.  The fact is, it does what is necessary for the architecture.  It
also happens to do what a write-then-read does on armv6, but that's
exactly the sort of assumption that should NOT be written into MI
code.  

> Question is - can we expose this somehow as a generic device method,
> so the higher bus layers can actually do something with it, or should
> we just leave it to device drivers to correctly do?
> 

In what way is that not EXACTLY whas bus_space_barrier() is defined to
do?

I've got to say, I don't understand all this pushback.  We have one
function defined already that's intended to be the machine-independant
way to ensure that any previous access to hardware using bus_space reads
and writes has completed, so why all this argument that it is not the
function to use?

-- Ian

> (Also - do any of the freebsd device driver books or the handbook mention this?)
> 
> 
> 
> -a



From che at bein.link  Sat Sep  6 16:20:09 2014
From: che at bein.link (Maxim V FIlimonov)
Date: Sat, 06 Sep 2014 20:20:05 +0400
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <2279481.3MX4OEDuCl@quad>
References: <2279481.3MX4OEDuCl@quad>
Message-ID: <42729580.BghYiSHhz3@quad>

On Saturday 06 September 2014 01:43:23 Maxim V FIlimonov wrote:
> And another problem: every now and then the kernel says something like that:
> Sep  5 19:22:37  kernel: Spurious interrupt detected
> Sep  5 19:22:37  kernel: Spurious interrupt detected
> Sep  5 19:23:46  last message repeated 10 times
> 
> I've heard that FreeBSD happens to do that on ARM devices. What could be the
> problem here?

A small detail: when I turn off SMP in the kernel config, the message 
disappears, but everything becomes too slow to operate.
-- 
wbr, Maxim Filimonov
che at bein.link

From ian at FreeBSD.org  Sat Sep  6 16:47:21 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Sat, 06 Sep 2014 10:47:17 -0600
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <42729580.BghYiSHhz3@quad>
References: <2279481.3MX4OEDuCl@quad>  <42729580.BghYiSHhz3@quad>
Message-ID: <1410022037.1150.360.camel@revolution.hippie.lan>

On Sat, 2014-09-06 at 20:20 +0400, Maxim V FIlimonov wrote:
> On Saturday 06 September 2014 01:43:23 Maxim V FIlimonov wrote:
> > And another problem: every now and then the kernel says something like that:
> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> > Sep  5 19:22:37  kernel: Spurious interrupt detected
> > Sep  5 19:23:46  last message repeated 10 times
> > 
> > I've heard that FreeBSD happens to do that on ARM devices. What could be the
> > problem here?
> 
> A small detail: when I turn off SMP in the kernel config, the message 
> disappears, but everything becomes too slow to operate.

Post the output of 'vmstat -i' -- it sounds like maybe there's an
interrupt handler monopolizing the system, or a timer that's firing at
way too high a rate, or something like that.

-- Ian



From che at bein.link  Sat Sep  6 16:52:56 2014
From: che at bein.link (Maxim V FIlimonov)
Date: Sat, 06 Sep 2014 20:52:53 +0400
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <1410022037.1150.360.camel@revolution.hippie.lan>
References: <2279481.3MX4OEDuCl@quad> <42729580.BghYiSHhz3@quad>
 <1410022037.1150.360.camel@revolution.hippie.lan>
Message-ID: <2229212.jhyveZzD6x@quad>

On Saturday 06 September 2014 10:47:17 Ian Lepore wrote:
> On Sat, 2014-09-06 at 20:20 +0400, Maxim V FIlimonov wrote:
> > On Saturday 06 September 2014 01:43:23 Maxim V FIlimonov wrote:
> > > And another problem: every now and then the kernel says something like
> > > that: Sep  5 19:22:37  kernel: Spurious interrupt detected
> > > Sep  5 19:22:37  kernel: Spurious interrupt detected
> > > Sep  5 19:23:46  last message repeated 10 times
> > > 
> > > I've heard that FreeBSD happens to do that on ARM devices. What could be
> > > the problem here?
> > 
> > A small detail: when I turn off SMP in the kernel config, the message
> > disappears, but everything becomes too slow to operate.
> 
> Post the output of 'vmstat -i' -- it sounds like maybe there's an
> interrupt handler monopolizing the system, or a timer that's firing at
> way too high a rate, or something like that.
Here it is:
root at cubie:~ # vmstat -i
interrupt                          total       rate
irq0: ipi                          10968         15
irq3: ipi                            293          0
irq6: ipi                            786          1
irq33: uart0                         217          0
irq54: a10_timer0                   1629          2
irq71: ehci0                        5791          8
irq87: emac0                         308          0
Total                              19992         28

-- 
wbr, Maxim Filimonov
che at bein.link

From imp at bsdimp.com  Sat Sep  6 20:21:52 2014
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 6 Sep 2014 14:20:51 -0600
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <1410015268.1150.351.camel@revolution.hippie.lan>
References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de>
 <1409958716.1150.321.camel@revolution.hippie.lan>
 <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>
 <20140906011526.GT82175@funkthat.com>
 <1409967197.1150.339.camel@revolution.hippie.lan>
 <20140906045403.GU82175@funkthat.com>
 <CAJ-VmonPttv58SGziDda--GooyLJdCcsGXCzP-UyGkO5oO2i=Q@mail.gmail.com>
 <1410015268.1150.351.camel@revolution.hippie.lan>
Message-ID: <AEEF4E90-27E9-43C7-8437-C593BE886846@bsdimp.com>


On Sep 6, 2014, at 8:54 AM, Ian Lepore <ian at FreeBSD.org> wrote:

> On Fri, 2014-09-05 at 23:45 -0700, Adrian Chadd wrote:
>> The device itself may have FIFOs and internal busses that also need to
>> be flushed.
>> 
> 
> The question isn't whether or not it's sufficient, because it's
> necessary.  The device driver knows what its hardware requirements are
> and should meet them.  It doesn't not know what its parent bus
> requirements are, and that's why it must call bus_space_barrier() to
> handle architecture needs above the level of the device itself.

Yea, all that bus_space_barrier() does is say ?We?ve made sure that
the CPU and all other bridges between the CPU and the device have
any buffered writes pushed to the device.? If the device has additional FIFOs
and other things, that?s 100% on the device writer.

>>> I was just looking at i386's implementation of bus_space_barrier and
>>> it just does a stack access...  This won't be sufficient to clear any
>>> PCI bridges that may have the write still pending...
>> 
>> Right. The memory barrier semantics right now don't at all guarantee
>> that bus and device FIFOs have actually been flushed.
>> 
> The fact that some architectures don't implement bus_space_barrier() in
> a way that's useful for that architecture is just a bug.  It doesn't
> change the fact that bus_space_barrier() is currently our only defined
> MI interface to barriers in device space.

Agreed. But PCI defines that reads flush out all prior writes.

>> So I don't think doing it using the existing bus space barrier
>> semantics is 'right'. For interrupts, it's highly likely that we do
>> actually need device drivers to read from their interrupt register to
>> ensure the update has been posted before returning. That's better than
>> causing entire L2 cache flushes.
>> 
> 
> Where did you see code that does an "entire L2 cache flush"?  You
> didn't, you just saw a function name and made assumptions about what it
> does.  The fact is, it does what is necessary for the architecture.  It
> also happens to do what a write-then-read does on armv6, but that's
> exactly the sort of assumption that should NOT be written into MI
> code.  

Yea, a bus barrier just means a temporal ordering. The exact strength
of that guarantee is a bit fuzzy, but generally it means we know things
are done. L2 is usually not an issue, because we have the devices mapped
uncached.

As for reading the ISR, that is device dependent. When using MSI things are
different because the status is pushed to the host and you get the info from reading
the host memory. Ideally, you?d want to write to ack them without having to do
a read over PCIe, but even that?s not always required (and on such devices
they would correct without bus barriers). Newer devices have been designed
to avoid round-trips over the PCIe bus and having semantics that matter.

>> Question is - can we expose this somehow as a generic device method,
>> so the higher bus layers can actually do something with it, or should
>> we just leave it to device drivers to correctly do?
>> 
> 
> In what way is that not EXACTLY whas bus_space_barrier() is defined to
> do?
> 
> I've got to say, I don't understand all this pushback.  We have one
> function defined already that's intended to be the machine-independant
> way to ensure that any previous access to hardware using bus_space reads
> and writes has completed, so why all this argument that it is not the
> function to use?

I agree with Ian here. If we?ve messed up, we need to fix that. But for the most
part, devices that are in embedded land actually do the right thing (more often
than not). If we?re doing something wrong on coherent architectures that accidentally
works, we should fix that.

I may disagree with Ian about the need for some of the flushing based on the notion
that we should fix the drivers. I feel it just makes the problem persist. Things should
be more visibly broken. Ian thinks things should work, and I have a hard time arguing
with that position even if I disagree :).

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140906/0fd4648a/attachment.sig>

From ian at FreeBSD.org  Sat Sep  6 21:19:03 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Sat, 06 Sep 2014 15:18:59 -0600
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <AEEF4E90-27E9-43C7-8437-C593BE886846@bsdimp.com>
References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de>
 <1409958716.1150.321.camel@revolution.hippie.lan>
 <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>
 <20140906011526.GT82175@funkthat.com>
 <1409967197.1150.339.camel@revolution.hippie.lan>
 <20140906045403.GU82175@funkthat.com>
 <CAJ-VmonPttv58SGziDda--GooyLJdCcsGXCzP-UyGkO5oO2i=Q@mail.gmail.com>
 <1410015268.1150.351.camel@revolution.hippie.lan>
 <AEEF4E90-27E9-43C7-8437-C593BE886846@bsdimp.com>
Message-ID: <1410038339.1150.381.camel@revolution.hippie.lan>

On Sat, 2014-09-06 at 14:20 -0600, Warner Losh wrote:
> On Sep 6, 2014, at 8:54 AM, Ian Lepore <ian at FreeBSD.org> wrote:
> 
> > On Fri, 2014-09-05 at 23:45 -0700, Adrian Chadd wrote:
> >> The device itself may have FIFOs and internal busses that also need to
> >> be flushed.
> >> 
> > 
> > The question isn't whether or not it's sufficient, because it's
> > necessary.  The device driver knows what its hardware requirements are
> > and should meet them.  It doesn't not know what its parent bus
> > requirements are, and that's why it must call bus_space_barrier() to
> > handle architecture needs above the level of the device itself.
> 
> Yea, all that bus_space_barrier() does is say ?We?ve made sure that
> the CPU and all other bridges between the CPU and the device have
> any buffered writes pushed to the device.? If the device has additional FIFOs
> and other things, that?s 100% on the device writer.
> 
> >>> I was just looking at i386's implementation of bus_space_barrier and
> >>> it just does a stack access...  This won't be sufficient to clear any
> >>> PCI bridges that may have the write still pending...
> >> 
> >> Right. The memory barrier semantics right now don't at all guarantee
> >> that bus and device FIFOs have actually been flushed.
> >> 
> > The fact that some architectures don't implement bus_space_barrier() in
> > a way that's useful for that architecture is just a bug.  It doesn't
> > change the fact that bus_space_barrier() is currently our only defined
> > MI interface to barriers in device space.
> 
> Agreed. But PCI defines that reads flush out all prior writes.
> 
> >> So I don't think doing it using the existing bus space barrier
> >> semantics is 'right'. For interrupts, it's highly likely that we do
> >> actually need device drivers to read from their interrupt register to
> >> ensure the update has been posted before returning. That's better than
> >> causing entire L2 cache flushes.
> >> 
> > 
> > Where did you see code that does an "entire L2 cache flush"?  You
> > didn't, you just saw a function name and made assumptions about what it
> > does.  The fact is, it does what is necessary for the architecture.  It
> > also happens to do what a write-then-read does on armv6, but that's
> > exactly the sort of assumption that should NOT be written into MI
> > code.  
> 
> Yea, a bus barrier just means a temporal ordering. The exact strength
> of that guarantee is a bit fuzzy, but generally it means we know things
> are done. L2 is usually not an issue, because we have the devices mapped
> uncached.
> 

It more complicated than that in the armv6/7 world.  They are mapped as
Device memory which means uncached but writes are buffered (using some
rules specifically designed to work for memory mapped devices, such as
disabling write-combining so that N writes issued results in N writes at
the device).  The buffering happens at the L2 cache controller, so when
you need to ensure that the write has reached the hardware you can make
a call to an L2 routine that blocks until the write has completed.

On armv7 you can also do a read of any address within the same 1K
address block as the write you want to have completed, but I don't think
any driver should contain code like that unless it's for soc-specific
hardware.  Like code for an on-chip timer might be able to make that
assumption, but an EHCI driver couldn't.

> As for reading the ISR, that is device dependent. When using MSI things are
> different because the status is pushed to the host and you get the info from reading
> the host memory. Ideally, you?d want to write to ack them without having to do
> a read over PCIe, but even that?s not always required (and on such devices
> they would correct without bus barriers). Newer devices have been designed
> to avoid round-trips over the PCIe bus and having semantics that matter.
> 
> >> Question is - can we expose this somehow as a generic device method,
> >> so the higher bus layers can actually do something with it, or should
> >> we just leave it to device drivers to correctly do?
> >> 
> > 
> > In what way is that not EXACTLY whas bus_space_barrier() is defined to
> > do?
> > 
> > I've got to say, I don't understand all this pushback.  We have one
> > function defined already that's intended to be the machine-independant
> > way to ensure that any previous access to hardware using bus_space reads
> > and writes has completed, so why all this argument that it is not the
> > function to use?
> 
> I agree with Ian here. If we?ve messed up, we need to fix that. But for the most
> part, devices that are in embedded land actually do the right thing (more often
> than not). If we?re doing something wrong on coherent architectures that accidentally
> works, we should fix that.
> 
> I may disagree with Ian about the need for some of the flushing based on the notion
> that we should fix the drivers. I feel it just makes the problem persist. Things should
> be more visibly broken. Ian thinks things should work, and I have a hard time arguing
> with that position even if I disagree :).

It has to work because if it doesn't then they'll start running linux on
imx6 at work and I'll have to look for a new job. :)

-- Ian



From imp at bsdimp.com  Sat Sep  6 23:09:43 2014
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 6 Sep 2014 17:03:14 -0600
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <1410038339.1150.381.camel@revolution.hippie.lan>
References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de>
 <1409958716.1150.321.camel@revolution.hippie.lan>
 <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>
 <20140906011526.GT82175@funkthat.com>
 <1409967197.1150.339.camel@revolution.hippie.lan>
 <20140906045403.GU82175@funkthat.com>
 <CAJ-VmonPttv58SGziDda--GooyLJdCcsGXCzP-UyGkO5oO2i=Q@mail.gmail.com>
 <1410015268.1150.351.camel@revolution.hippie.lan>
 <AEEF4E90-27E9-43C7-8437-C593BE886846@bsdimp.com>
 <1410038339.1150.381.camel@revolution.hippie.lan>
Message-ID: <39CA4EF7-10CD-4BF5-B1FC-74107FDF5525@bsdimp.com>


On Sep 6, 2014, at 3:18 PM, Ian Lepore <ian at FreeBSD.org> wrote:

> On Sat, 2014-09-06 at 14:20 -0600, Warner Losh wrote:
>> On Sep 6, 2014, at 8:54 AM, Ian Lepore <ian at FreeBSD.org> wrote:
>> 
>>> On Fri, 2014-09-05 at 23:45 -0700, Adrian Chadd wrote:
>>>> The device itself may have FIFOs and internal busses that also need to
>>>> be flushed.
>>>> 
>>> 
>>> The question isn't whether or not it's sufficient, because it's
>>> necessary.  The device driver knows what its hardware requirements are
>>> and should meet them.  It doesn't not know what its parent bus
>>> requirements are, and that's why it must call bus_space_barrier() to
>>> handle architecture needs above the level of the device itself.
>> 
>> Yea, all that bus_space_barrier() does is say ?We?ve made sure that
>> the CPU and all other bridges between the CPU and the device have
>> any buffered writes pushed to the device.? If the device has additional FIFOs
>> and other things, that?s 100% on the device writer.
>> 
>>>>> I was just looking at i386's implementation of bus_space_barrier and
>>>>> it just does a stack access...  This won't be sufficient to clear any
>>>>> PCI bridges that may have the write still pending...
>>>> 
>>>> Right. The memory barrier semantics right now don't at all guarantee
>>>> that bus and device FIFOs have actually been flushed.
>>>> 
>>> The fact that some architectures don't implement bus_space_barrier() in
>>> a way that's useful for that architecture is just a bug.  It doesn't
>>> change the fact that bus_space_barrier() is currently our only defined
>>> MI interface to barriers in device space.
>> 
>> Agreed. But PCI defines that reads flush out all prior writes.
>> 
>>>> So I don't think doing it using the existing bus space barrier
>>>> semantics is 'right'. For interrupts, it's highly likely that we do
>>>> actually need device drivers to read from their interrupt register to
>>>> ensure the update has been posted before returning. That's better than
>>>> causing entire L2 cache flushes.
>>>> 
>>> 
>>> Where did you see code that does an "entire L2 cache flush"?  You
>>> didn't, you just saw a function name and made assumptions about what it
>>> does.  The fact is, it does what is necessary for the architecture.  It
>>> also happens to do what a write-then-read does on armv6, but that's
>>> exactly the sort of assumption that should NOT be written into MI
>>> code.  
>> 
>> Yea, a bus barrier just means a temporal ordering. The exact strength
>> of that guarantee is a bit fuzzy, but generally it means we know things
>> are done. L2 is usually not an issue, because we have the devices mapped
>> uncached.
>> 
> 
> It more complicated than that in the armv6/7 world.  They are mapped as
> Device memory which means uncached but writes are buffered (using some
> rules specifically designed to work for memory mapped devices, such as
> disabling write-combining so that N writes issued results in N writes at
> the device).  The buffering happens at the L2 cache controller, so when
> you need to ensure that the write has reached the hardware you can make
> a call to an L2 routine that blocks until the write has completed.
> 
> On armv7 you can also do a read of any address within the same 1K
> address block as the write you want to have completed, but I don't think
> any driver should contain code like that unless it's for soc-specific
> hardware.  Like code for an on-chip timer might be able to make that
> assumption, but an EHCI driver couldn?t.

Wouldn?t the bus_space_barrier() block until the write to the bus space area
flushes? Or does our API make that kinda tough to implement?

>> As for reading the ISR, that is device dependent. When using MSI things are
>> different because the status is pushed to the host and you get the info from reading
>> the host memory. Ideally, you?d want to write to ack them without having to do
>> a read over PCIe, but even that?s not always required (and on such devices
>> they would correct without bus barriers). Newer devices have been designed
>> to avoid round-trips over the PCIe bus and having semantics that matter.
>> 
>>>> Question is - can we expose this somehow as a generic device method,
>>>> so the higher bus layers can actually do something with it, or should
>>>> we just leave it to device drivers to correctly do?
>>>> 
>>> 
>>> In what way is that not EXACTLY whas bus_space_barrier() is defined to
>>> do?
>>> 
>>> I've got to say, I don't understand all this pushback.  We have one
>>> function defined already that's intended to be the machine-independant
>>> way to ensure that any previous access to hardware using bus_space reads
>>> and writes has completed, so why all this argument that it is not the
>>> function to use?
>> 
>> I agree with Ian here. If we?ve messed up, we need to fix that. But for the most
>> part, devices that are in embedded land actually do the right thing (more often
>> than not). If we?re doing something wrong on coherent architectures that accidentally
>> works, we should fix that.
>> 
>> I may disagree with Ian about the need for some of the flushing based on the notion
>> that we should fix the drivers. I feel it just makes the problem persist. Things should
>> be more visibly broken. Ian thinks things should work, and I have a hard time arguing
>> with that position even if I disagree :).
> 
> It has to work because if it doesn't then they'll start running linux on
> imx6 at work and I'll have to look for a new job. :)

Like I said, it is hard to argue with it?

I?m curious if you know which drivers are broken? Is this list of known broken long, or is
this just a case of ?at least one was broken, so let?s be conservative for now to get the
thing working?? If the latter, is there any way we can see what?s broken and get bugzillas
going on them?

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140906/449a1734/attachment.sig>

From jmg at funkthat.com  Sun Sep  7 06:15:27 2014
From: jmg at funkthat.com (John-Mark Gurney)
Date: Sat, 6 Sep 2014 23:15:09 -0700
Subject: Cubieboard: Spurious interrupt detected
In-Reply-To: <AEEF4E90-27E9-43C7-8437-C593BE886846@bsdimp.com>
References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de>
 <1409958716.1150.321.camel@revolution.hippie.lan>
 <CAJ-Vmo=EJVFqNnMo_dzevGvFWLSR6LVfYbYmOot1bLZbCvVMTQ@mail.gmail.com>
 <20140906011526.GT82175@funkthat.com>
 <1409967197.1150.339.camel@revolution.hippie.lan>
 <20140906045403.GU82175@funkthat.com>
 <CAJ-VmonPttv58SGziDda--GooyLJdCcsGXCzP-UyGkO5oO2i=Q@mail.gmail.com>
 <1410015268.1150.351.camel@revolution.hippie.lan>
 <AEEF4E90-27E9-43C7-8437-C593BE886846@bsdimp.com>
Message-ID: <20140907061508.GY82175@funkthat.com>

Warner Losh wrote this message on Sat, Sep 06, 2014 at 14:20 -0600:
> 
> On Sep 6, 2014, at 8:54 AM, Ian Lepore <ian at FreeBSD.org> wrote:
> 
> > On Fri, 2014-09-05 at 23:45 -0700, Adrian Chadd wrote:
> >> The device itself may have FIFOs and internal busses that also need to
> >> be flushed.
> >> 
> > 
> > The question isn't whether or not it's sufficient, because it's
> > necessary.  The device driver knows what its hardware requirements are
> > and should meet them.  It doesn't not know what its parent bus
> > requirements are, and that's why it must call bus_space_barrier() to
> > handle architecture needs above the level of the device itself.
> 
> Yea, all that bus_space_barrier() does is say ?We?ve made sure that
> the CPU and all other bridges between the CPU and the device have
> any buffered writes pushed to the device.? If the device has additional FIFOs
> and other things, that?s 100% on the device writer.

Except that doesn't happen right now...  bus_space_barrier on amd64
does a locked stack access, but that won't cause any write buffers
on bridges to flush...

> >>> I was just looking at i386's implementation of bus_space_barrier and
> >>> it just does a stack access...  This won't be sufficient to clear any
> >>> PCI bridges that may have the write still pending...
> >> 
> >> Right. The memory barrier semantics right now don't at all guarantee
> >> that bus and device FIFOs have actually been flushed.
> >> 
> > The fact that some architectures don't implement bus_space_barrier() in
> > a way that's useful for that architecture is just a bug.  It doesn't
> > change the fact that bus_space_barrier() is currently our only defined
> > MI interface to barriers in device space.

I agree...  Now if you convince people on the correct way to fix
bus_space_barrier to do the correct thing, then I don't have a problem
having drivers use bus_space_barrier...  My only issue is that as things
are now, adding bus_space_barrier will not fix PCI devices...

> Agreed. But PCI defines that reads flush out all prior writes.
> 
> >> So I don't think doing it using the existing bus space barrier
> >> semantics is 'right'. For interrupts, it's highly likely that we do
> >> actually need device drivers to read from their interrupt register to
> >> ensure the update has been posted before returning. That's better than
> >> causing entire L2 cache flushes.
> >> 
> > 
> > Where did you see code that does an "entire L2 cache flush"?  You
> > didn't, you just saw a function name and made assumptions about what it
> > does.  The fact is, it does what is necessary for the architecture.  It
> > also happens to do what a write-then-read does on armv6, but that's
> > exactly the sort of assumption that should NOT be written into MI
> > code.  
> 
> Yea, a bus barrier just means a temporal ordering. The exact strength
> of that guarantee is a bit fuzzy, but generally it means we know things
> are done. L2 is usually not an issue, because we have the devices mapped
> uncached.
> 
> As for reading the ISR, that is device dependent. When using MSI things are
> different because the status is pushed to the host and you get the info from reading
> the host memory. Ideally, you?d want to write to ack them without having to do
> a read over PCIe, but even that?s not always required (and on such devices
> they would correct without bus barriers). Newer devices have been designed
> to avoid round-trips over the PCIe bus and having semantics that matter.
> 
> >> Question is - can we expose this somehow as a generic device method,
> >> so the higher bus layers can actually do something with it, or should
> >> we just leave it to device drivers to correctly do?
> >> 
> > 
> > In what way is that not EXACTLY whas bus_space_barrier() is defined to
> > do?
> > 
> > I've got to say, I don't understand all this pushback.  We have one
> > function defined already that's intended to be the machine-independant
> > way to ensure that any previous access to hardware using bus_space reads
> > and writes has completed, so why all this argument that it is not the
> > function to use?

The argument isn't that it's not the function to use, the argument is
that the function is broken, or doesn't do what it says in the docs...

Actually, the docs don't guarantee that the writes will be completed
after the call, the docs say:
     All of the specified type(s) of operation which are done to the region
     before the barrier operation are guaranteed to complete before any of the
     specified type(s) of operation done after the barrier.

So that means a following read will return correct results... so, per
bus_space_barrier docs, all ISRs should probably be:

	write to clear ISR
	bus_space_barrier
	read to clear ISR so that the write w/ bus_space_barrier is
	  known to complete

So, sounds like we still need the read even w/ the bus_space_barrier.

Now it could be our docs are wrong, but in that case, they should be
fixed...

> I agree with Ian here. If we?ve messed up, we need to fix that. But for the most
> part, devices that are in embedded land actually do the right thing (more often
> than not). If we?re doing something wrong on coherent architectures that accidentally
> works, we should fix that.
> 
> I may disagree with Ian about the need for some of the flushing based on the notion
> that we should fix the drivers. I feel it just makes the problem persist. Things should
> be more visibly broken. Ian thinks things should work, and I have a hard time arguing
> with that position even if I disagree :).

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From bugzilla-noreply at freebsd.org  Sun Sep  7 17:56:30 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 07 Sep 2014 17:56:30 +0000
Subject: [Bug 193437] New: Cubieboard2: lock order reversal on poweroff
Message-ID: <bug-193437-7@https.bugs.freebsd.org/bugzilla/>

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193437

            Bug ID: 193437
           Summary: Cubieboard2: lock order reversal on poweroff
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: Any
                OS: Any
            Status: Needs Triage
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm at FreeBSD.org
          Reporter: che at bein.link

Gave poweroff command to my cubieboard, it begins to power off, syncs disks and
I get the following:

All buffers synced.
lock order reversal:
1st 0xc3d8c274 ufs (ufs) @ /home/che/freebsd-src/head/sys/kern/vfs_mount.c:1223
2nd 0xc3d8c5d4 devfs (devfs) @
/home/che/freebsd-src/head/sys/kern/vfs_subr.c:2137
KDB: stack backtrace:
db_trace_self() at db_trace_self
pc = 0xc0509484  lr = 0xc02347e0 (X_db_symbol_values+0x11c)
sp = 0xebbcaa00  fp = 0xebbcab18
r10 = 0xc3d8c5d4
X_db_symbol_values() at X_db_symbol_values+0x11c
pc = 0xc02347e0  lr = 0xc0370d60 (kdb_backtrace+0x38)
sp = 0xebbcab20  fp = 0xebbcab28
r4 = 0xc0639a94  r5 = 0xc0550f1e
r6 = 0xc0573682  r7 = 0xc0572c46
kdb_backtrace() at kdb_backtrace+0x38
pc = 0xc0370d60  lr = 0xc038c608 (witness_checkorder+0xe58)
sp = 0xebbcab30  fp = 0xebbcab80
r4 = 0xc055e3ff
witness_checkorder() at witness_checkorder+0xe58
pc = 0xc038c608  lr = 0xc031adb8 (__lockmgr_args+0x8b4)
sp = 0xebbcab88  fp = 0xebbcabf0
r4 = 0x00000100  r5 = 0x00080500
r6 = 0x00000859  r7 = 0xc3d8c5f4
r8 = 0xc3d8c5d4  r9 = 0x00080000
r10 = 0xc057367f
__lockmgr_args() at __lockmgr_args+0x8b4
pc = 0xc031adb8  lr = 0xc03d18b0 (vop_stdlock+0x3c)
sp = 0xebbcabf8  fp = 0xebbcac08
r4 = 0xebbcac28  r5 = 0xc0613f40
r6 = 0x00000000  r7 = 0x00080500
r8 = 0xebbcac28  r9 = 0xc05512fb
r10 = 0x00000859
vop_stdlock() at vop_stdlock+0x3c
pc = 0xc03d18b0  lr = 0xc052ba20 (VOP_LOCK1_APV+0xd8)
sp = 0xebbcac10  fp = 0xebbcac20
VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd8
pc = 0xc052ba20  lr = 0xc03efc14 (_vn_lock+0x44)
sp = 0xebbcac28  fp = 0xebbcac58
r4 = 0xc3d8c5a0  r5 = 0xc3d45500
r6 = 0xc057367f
_vn_lock() at _vn_lock+0x44
pc = 0xc03efc14  lr = 0xc03e048c (vget+0x60)
sp = 0xebbcac60  fp = 0xebbcac80
r4 = 0xc3d8c5a0  r5 = 0xc3d45500
r6 = 0x00080500  r7 = 0xc3d45514
r8 = 0xc3a87640  r9 = 0xc05512fb
r10 = 0x00000000
vget() at vget+0x60
pc = 0xc03e048c  lr = 0xc02952b8 (devfs_allocv+0xf8)
sp = 0xebbcac88  fp = 0xebbcacb0
r4 = 0xc08de4ac  r5 = 0xc3d45500
r6 = 0xc3d6f100  r7 = 0xc3d45514
r8 = 0x00080500
devfs_allocv() at devfs_allocv+0xf8
pc = 0xc02952b8  lr = 0xc0294d80 (devfs_unmount_final+0x4ec)
sp = 0xebbcacb8  fp = 0xebbcacc8
r4 = 0xebbcace8  r5 = 0xc3d8a560
r6 = 0xc3d45500  r7 = 0x00000000
r8 = 0xc3a87640  r9 = 0x00080000
r10 = 0x00080000
devfs_unmount_final() at devfs_unmount_final+0x4ec
pc = 0xc0294d80  lr = 0xc03d9c78 (dounmount+0x3a0)
sp = 0xebbcacd0  fp = 0xebbcad18
r4 = 0xc3d8c240  r5 = 0x00001000
r6 = 0xc0572c43
dounmount() at dounmount+0x3a0
pc = 0xc03d9c78  lr = 0xc03e2688 (vfs_unmountall+0x48)
sp = 0xebbcad20  fp = 0xebbcad40
r4 = 0xc3a87640  r5 = 0xc055e3ff
r6 = 0xc0562bd0  r7 = 0xc3d8a560
r8 = 0xc06141e0  r9 = 0xc056a980
r10 = 0xc0573d14
vfs_unmountall() at vfs_unmountall+0x48
pc = 0xc03e2688  lr = 0xc03377b4 (kern_reboot+0x4d4)
sp = 0xebbcad48  fp = 0xebbcada8
r4 = 0xc0620474  r5 = 0x00000000
r6 = 0xc0562bd0  r7 = 0xd91156a8
r8 = 0xc062b610  r9 = 0x00004008
r10 = 0xc08dfa9c
kern_reboot() at kern_reboot+0x4d4
pc = 0xc03377b4  lr = 0xc03372d8 (sys_reboot+0x44)
sp = 0xebbcadb0  fp = 0xebbcadb8
r4 = 0xebbcae18  r5 = 0xc3a84640
r6 = 0x00000000  r7 = 0x00000000
r8 = 0x0000001f  r9 = 0xebbcae10
r10 = 0x0000001e
sys_reboot() at sys_reboot+0x44
pc = 0xc03372d8  lr = 0xc051f4ec (swi_handler+0x290)
sp = 0xebbcadc0  fp = 0xebbcae58
r4 = 0xc3a87640
swi_handler() at swi_handler+0x290
pc = 0xc051f4ec  lr = 0xc050b0fc (swi_exit)
sp = 0xebbcae60  fp = 0xbffff938
r4 = 0x000de700  r5 = 0x000dc0c0
r6 = 0x00000034  r7 = 0x00000037
r8 = 0x0000001f  r9 = 0x0000000e
swi_exit() at swi_exit
pc = 0xc050b0fc  lr = 0xc050b0fc (swi_exit)
sp = 0xebbcae60  fp = 0xbffff938
Unable to unwind further
Uptime: 5m47s

The operating system has halted.
Please press any key to reboot.

-- 
You are receiving this mail because:
You are the assignee for the bug.

From bugzilla-noreply at freebsd.org  Sun Sep  7 17:56:53 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 07 Sep 2014 17:56:53 +0000
Subject: [Bug 193437] Cubieboard2: lock order reversal on poweroff
In-Reply-To: <bug-193437-7@https.bugs.freebsd.org/bugzilla/>
References: <bug-193437-7@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-193437-7-C1FhW4sptw@https.bugs.freebsd.org/bugzilla/>

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193437

Maxim Filimonov <che at bein.link> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Hardware|Any                         |arm

-- 
You are receiving this mail because:
You are the assignee for the bug.

From alexander.tarasikov at gmail.com  Sun Sep  7 18:01:13 2014
From: alexander.tarasikov at gmail.com (Alexander Tarasikov)
Date: Sun, 7 Sep 2014 22:01:10 +0400
Subject: Android Emulator for FreeBSD + FreeBSD/ARM port
Message-ID: <CAMChaFyKff2W4_caU86=trdC9ZhGF9xYJBtV+Cma7pAuiwa79g@mail.gmail.com>

Hi, FreeBSD crowd!

During summer as part of GSoC program I was working on porting FreeBSD
to the Android Emulator.
Besides, I have ported Android Emulator to run natively on x86_64 as opposed to
using linuxulator for 32-bit support.

As for the kernel side, I have implemented the support for the
following hardware:
 *IRQ, Timer, UART
 *MMC
 *Ethernet
 *Framebuffer (using NEWCONS)

It allows to mount rootfs and boot up to login prompt with raspberry
pi sd card image.

As for the emulator, it's a bit complicated. FreeBSD boots fine if you
launch the emulator on Linux or Mac OS X. I have fixed some parts of
the build system and headers to make it compile and pass the tests on
FreeBSD. Unfortunately, the GUI doesn't work right now and only
console output (virtual UART) works.

If anyone is interested, I would like that you read my blog post,
review my kernel commit and suggest ways to improve and push the
changes upstream. As for the Emulator, I think we can get it running
with GUI and everything because it just has too many "#ifdef
__linux__" stuff around the code which should compile and run on
FreeBSD as well, we just need to gradually uncomment each of these
sections.

Relevant links:
[kernel code commit]
https://github.com/astarasikov/freebsd/commit/514be1f08a552f54abef83232498559c72e1d33b
[README, compilation instructions]
https://github.com/astarasikov/freebsd/blob/android_goldfish_arm_master/sys/arm/goldfish/README
[Emulator with patches]
https://github.com/astarasikov/qemu/tree/l-preview-freebsd
[blog] http://allsoftwaresucks.blogspot.ru/2014/09/gsoc-results-or-how-i-nearly-wasted.html

-- 
Regards, Alexander

From adrian at freebsd.org  Sun Sep  7 20:32:50 2014
From: adrian at freebsd.org (Adrian Chadd)
Date: Sun, 7 Sep 2014 13:32:48 -0700
Subject: Android Emulator for FreeBSD + FreeBSD/ARM port
In-Reply-To: <CAMChaFyKff2W4_caU86=trdC9ZhGF9xYJBtV+Cma7pAuiwa79g@mail.gmail.com>
References: <CAMChaFyKff2W4_caU86=trdC9ZhGF9xYJBtV+Cma7pAuiwa79g@mail.gmail.com>
Message-ID: <CAJ-Vmone+T1JEv-Pq6Mr_SFC5XP1qwGmrb80rW1tw3Vwm+fGNQ@mail.gmail.com>

On 7 September 2014 11:01, Alexander Tarasikov
<alexander.tarasikov at gmail.com> wrote:
> Hi, FreeBSD crowd!
>
> During summer as part of GSoC program I was working on porting FreeBSD
> to the Android Emulator.

Cool!

> Besides, I have ported Android Emulator to run natively on x86_64 as opposed to
> using linuxulator for 32-bit support.

Double cool!

> As for the kernel side, I have implemented the support for the
> following hardware:
>  *IRQ, Timer, UART
>  *MMC
>  *Ethernet
>  *Framebuffer (using NEWCONS)

Triple cool!

> It allows to mount rootfs and boot up to login prompt with raspberry
> pi sd card image.
>
> As for the emulator, it's a bit complicated. FreeBSD boots fine if you
> launch the emulator on Linux or Mac OS X. I have fixed some parts of
> the build system and headers to make it compile and pass the tests on
> FreeBSD. Unfortunately, the GUI doesn't work right now and only
> console output (virtual UART) works.
>
> If anyone is interested, I would like that you read my blog post,
> review my kernel commit and suggest ways to improve and push the
> changes upstream. As for the Emulator, I think we can get it running
> with GUI and everything because it just has too many "#ifdef
> __linux__" stuff around the code which should compile and run on
> FreeBSD as well, we just need to gradually uncomment each of these
> sections.
>
> Relevant links:
> [kernel code commit]
> https://github.com/astarasikov/freebsd/commit/514be1f08a552f54abef83232498559c72e1d33b
> [README, compilation instructions]
> https://github.com/astarasikov/freebsd/blob/android_goldfish_arm_master/sys/arm/goldfish/README
> [Emulator with patches]
> https://github.com/astarasikov/qemu/tree/l-preview-freebsd
> [blog] http://allsoftwaresucks.blogspot.ru/2014/09/gsoc-results-or-how-i-nearly-wasted.html

This work is awesome. I'll see if I can spin it up!



-a

From ticso at cicely7.cicely.de  Tue Sep  9 00:30:17 2014
From: ticso at cicely7.cicely.de (Bernd Walter)
Date: Tue, 9 Sep 2014 02:29:54 +0200
Subject: Crochet partition alignment
Message-ID: <20140909002954.GB24276@cicely7.cicely.de>

[67]wandboard# gpart list 
Geom name: mmcsd0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 61497343
first: 63
entries: 4
scheme: MBR
Providers:
1. Name: mmcsd0s1
   Mediasize: 52416000 (50M)
   Sectorsize: 512
   Stripesize: 4194304
   Stripeoffset: 30208
   Mode: r1w1e1
   attrib: active
   rawtype: 12
   length: 52416000
   offset: 8418816
   type: !12
   index: 1
   end: 118817
   start: 16443
2. Name: mmcsd0s2
   Mediasize: 31425805312 (29G)
   Sectorsize: 512
   Stripesize: 4194304
   Stripeoffset: 2114560
   Mode: r1w1e2
   rawtype: 165
   length: 31425805312
   offset: 60834816
   type: freebsd
   index: 2
   end: 61497343
   start: 118818
Consumers:
1. Name: mmcsd0
   Mediasize: 31486640128 (29G)
   Sectorsize: 512
   Stripesize: 4194304
   Stripeoffset: 0
   Mode: r2w2e5

Geom name: mmcsd0s2
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 61378525
first: 0
entries: 8
scheme: BSD
Providers:
1. Name: mmcsd0s2a
   Mediasize: 31425757184 (29G)
   Sectorsize: 512
   Stripesize: 4194304
   Stripeoffset: 2162688
   Mode: r1w1e1
   rawtype: 7
   length: 31425757184
   offset: 48128
   type: freebsd-ufs
   index: 1
   end: 61378525
   start: 94
Consumers:
1. Name: mmcsd0s2
   Mediasize: 31425805312 (29G)
   Sectorsize: 512
   Stripesize: 4194304
   Stripeoffset: 2114560
   Mode: r1w1e2

There are 63 sectors per track in MBR table.
s1 starts at sector 16443 in track 261.
This is an uneven 512 byte sector number, so it starts at 512 Byte
alignment only.
Leaves the question why 261 tracks are left out when it still isn't
aligned?

s2, which is what I care most about, starts at 118818.
This is even, but only once divideable by 2.
It is at a 1024 alignment - still not the needed >= 4k for SD cards.

Inside s2 the a partition starts at 48128 (+118818 from provider).
Again lost space.
By itself it would be a 512k alignment - more than perfect, though I
don't think it requires such a big waste, but with the mmcsd0s2 provider
alignemt it's still only 1k.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

From tim at kientzle.com  Tue Sep  9 01:51:50 2014
From: tim at kientzle.com (Tim Kientzle)
Date: Mon, 8 Sep 2014 18:08:33 -0700
Subject: Crochet partition alignment
In-Reply-To: <20140909002954.GB24276@cicely7.cicely.de>
References: <20140909002954.GB24276@cicely7.cicely.de>
Message-ID: <5053828F-435E-4ED0-AF8E-F0D4F9C3BF5C@kientzle.com>

Do you disagree with this commit?

https://github.com/kientzle/crochet-freebsd/commit/3f4818b6ad668eb4a1d7a55bd1634719a18d7729

If so, what do you propose here?

Cheers,

Tim



From ticso at cicely7.cicely.de  Tue Sep  9 02:01:02 2014
From: ticso at cicely7.cicely.de (Bernd Walter)
Date: Tue, 9 Sep 2014 04:00:46 +0200
Subject: Crochet partition alignment
In-Reply-To: <5053828F-435E-4ED0-AF8E-F0D4F9C3BF5C@kientzle.com>
References: <20140909002954.GB24276@cicely7.cicely.de>
 <5053828F-435E-4ED0-AF8E-F0D4F9C3BF5C@kientzle.com>
Message-ID: <20140909020046.GC24276@cicely7.cicely.de>

On Mon, Sep 08, 2014 at 06:08:33PM -0700, Tim Kientzle wrote:
> Do you disagree with this commit?
> 
> https://github.com/kientzle/crochet-freebsd/commit/3f4818b6ad668eb4a1d7a55bd1634719a18d7729
> 
> If so, what do you propose here?

No sorry - no serious problem exists.
It was my fault - I took the wrong numbers.
You request 64k alignment for the UFS partition and that's what we get.
I added 118818 of the slice and 48128 for the partition.
This was adding two different things - first number is sector offset and
the later is byte offset.
In fact it is 118818 + 94, which is perfectly 64k aligned.
94 sectors is the smallest loss to get to the next 64k - perfect.
The msdosfs slice is unaligned but it isn't updated very often, so
it's probably Ok with that.
There is still that big 8M gap in front of the msdos slice, which I
can't explain with crochet.
You request an 63 Byte alignment for that slice - odd requirement IMHO,
but should be fullfilled starting with second 63 sector track.
But this would be just ~32k and not 8M.
Not that this 8M loss is important with nGbyte media, but still 
unexpected.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

From ticso at cicely7.cicely.de  Tue Sep  9 04:03:05 2014
From: ticso at cicely7.cicely.de (Bernd Walter)
Date: Tue, 9 Sep 2014 06:02:42 +0200
Subject: compile error in atomic.h when compiling c++
Message-ID: <20140909040224.GA26202@cicely7.cicely.de>

System is r271289M with clang.

[114]wandboard# cat test.cc 
#include <sys/types.h>
#include <machine/atomic.h>

int
main(int argc, char *argv[])
{
        return 0;
}

[115]wandboard# c++ -Wall test.cc
In file included from test.cc:2:
/usr/include/machine/atomic.h:286:8: error: expected identifier
                    [new]    "r"    (newval)
                     ^
/usr/include/machine/atomic.h:286:11: error: expected expression
                    [new]    "r"    (newval)
                        ^
2 errors generated.
Exit 1

I assume it has problems with "new" used here, which is a special
keyword in C++.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

From ian at FreeBSD.org  Tue Sep  9 13:51:55 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Tue, 09 Sep 2014 07:51:51 -0600
Subject: compile error in atomic.h when compiling c++
In-Reply-To: <20140909040224.GA26202@cicely7.cicely.de>
References: <20140909040224.GA26202@cicely7.cicely.de>
Message-ID: <1410270711.1150.409.camel@revolution.hippie.lan>

On Tue, 2014-09-09 at 06:02 +0200, Bernd Walter wrote:
> System is r271289M with clang.
> 
> [114]wandboard# cat test.cc 
> #include <sys/types.h>
> #include <machine/atomic.h>
> 
> int
> main(int argc, char *argv[])
> {
>         return 0;
> }
> 
> [115]wandboard# c++ -Wall test.cc
> In file included from test.cc:2:
> /usr/include/machine/atomic.h:286:8: error: expected identifier
>                     [new]    "r"    (newval)
>                      ^
> /usr/include/machine/atomic.h:286:11: error: expected expression
>                     [new]    "r"    (newval)
>                         ^
> 2 errors generated.
> Exit 1
> 
> I assume it has problems with "new" used here, which is a special
> keyword in C++.
> 

My bad, fixed in r271310.

Jeez, I used to be able to call myself "mostly a C++ programmer" and
would automatically not make such a mistake.  For the past couple years
it seems all I've written is C.

-- Ian



From ticso at cicely7.cicely.de  Wed Sep 10 11:16:47 2014
From: ticso at cicely7.cicely.de (Bernd Walter)
Date: Wed, 10 Sep 2014 13:16:16 +0200
Subject: buildworld selfbuild failure
Message-ID: <20140910111616.GA31990@cicely7.cicely.de>

The same source code was used to build with crochet and is running on
the system.
It's a Wandboard Quad with a -j8 buildworld run.
Source tree is on NFS /usr/obj on local SD.

...
--- lib_tputs.So ---
cc  -fpic -DPIC  -O -pipe   -I. -I/usr/obj/home/builder/arm-build/head/lib/ncurses/ncurses/../ncurses -I/home/builder/arm-build/head/lib/ncurses/ncurses/../ncurses -I/home/builder/arm-build/head/lib/ncurses/ncurses/../ncurses -I/home/builder/arm-build/head/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/home/builder/arm-build/head/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Qunused-arguments -c /home/builder/arm-build/head/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/lib_tputs.c -o lib_tputs.So
--- lib/ncurses/ncursesw__L ---
--- free_ttype.So ---
cc  -fpic -DPIC  -O -pipe   -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/home/builder/arm-build/head/lib/ncurses/ncursesw/../ncursesw -I/home/builder/arm-build/head/lib/ncurses/ncursesw/../ncursesw -I/home/builder/arm-build/head/lib/ncurses/ncursesw/../ncurses -I/home/builder/arm-build/head/lib/ncurses/ncursesw/../../../contrib/ncurses/include -I/home/builder/arm-build/head/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Qunused-arguments -c /home/builder/arm-build/head/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/tinfo/free_ttype.c -o free_ttype.So
--- kerberos5/lib/libheimsqlite__L ---
cc: error: unable to execute command: Bus error (core dumped)
cc: error: clang frontend command failed due to signal (use -v to see invocation)
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: armv6--freebsd11.0-gnueabi
Thread model: posix
cc: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
cc: note: diagnostic msg: Error generating preprocessed source(s).
*** [sqlite3.o] Error code 254

make[4]: stopped in /home/builder/arm-build/head/kerberos5/lib/libheimsqlite
--- lib/msun__L ---
A failure has been detected in another branch of the parallel make

make[4]: stopped in /home/builder/arm-build/head/lib/msun
--- lib/ncurses/ncursesw__L ---
A failure has been detected in another branch of the parallel make

make[4]: stopped in /home/builder/arm-build/head/lib/ncurses/ncursesw
--- lib/ncurses/ncurses__L ---
A failure has been detected in another branch of the parallel make

make[4]: stopped in /home/builder/arm-build/head/lib/ncurses/ncurses
--- kerberos5/lib/libheimsqlite__L ---
1 error

make[4]: stopped in /home/builder/arm-build/head/kerberos5/lib/libheimsqlite
--- secure/lib/libcrypto__L ---
A failure has been detected in another branch of the parallel make

make[4]: stopped in /home/builder/arm-build/head/secure/lib/libcrypto
A failure has been detected in another branch of the parallel make

make[3]: stopped in /home/builder/arm-build/head
*** [libraries] Error code 2

make[2]: stopped in /home/builder/arm-build/head
1 error

make[2]: stopped in /home/builder/arm-build/head
*** [_libraries] Error code 2

make[1]: stopped in /home/builder/arm-build/head
1 error

make[1]: stopped in /home/builder/arm-build/head
*** [buildworld] Error code 2

make: stopped in /home/builder/arm-build/head
1 error

make: stopped in /home/builder/arm-build/head
71773.091u 36752.279s 2:47:24.86 1080.4%        -40+98k 2728+6318io 4153pf+0w
Exit 2


[170]wandboard# gdb /usr/obj/home/builder/arm-build/head/tmp/usr/bin/cc cc.core 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "armv6-marcel-freebsd"...(no debugging symbols found)...
Core was generated by `cc'.
Program terminated with signal 10, Bus error.
#0  0x008dc410 in clang::SrcMgr::ContentCache::getBuffer ()
(gdb) bt
#0  0x008dc410 in clang::SrcMgr::ContentCache::getBuffer ()
#1  0x00914330 in clang::SourceManager::getBuffer ()
#2  0x00912260 in clang::Preprocessor::EnterSourceFile ()
#3  0x008f70e8 in clang::Preprocessor::EnterMainSourceFile ()
#4  0x0030e760 in clang::ParseAST ()
#5  0x000411bc in clang::ASTFrontendAction::ExecuteAction ()
#6  0x001c0998 in clang::CodeGenAction::ExecuteAction ()
#7  0x00040a38 in clang::FrontendAction::Execute ()
#8  0x00060120 in clang::CompilerInstance::ExecuteAction ()
#9  0x00010340 in $a ()
#10 0x00010340 in $a ()
(gdb) 


Retry without -j:
CC='cc ' mkdep -f .depend -a    -I/home/builder/arm-build/head/kerberos5/lib/libheimsqlite/../../../crypto/heimdal/lib/sqlite -DHAVE_CONFIG_H -I/home/builder/arm-build/head/kerberos5/lib/libheimsqlite/../../include -std=gnu99   /home/builder/arm-build/head/kerberos5/lib/libheimsqlite/../../../crypto/heimdal/lib/sqlite/sqlite3.c
Stack dump:
0.      Program arguments: /usr/obj/home/builder/arm-build/head/tmp/usr/bin/cc -cc1 -triple armv6--freebsd11.0-gnueabi -Eonly -disable-free -main-file-name sqlite3.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu arm1176jzf-s -target-feature +soft-float -target-feature +soft-float-abi -target-feature -neon -target-abi aapcs-linux -msoft-float -mfloat-abi soft -resource-dir /usr/obj/home/builder/arm-build/head/tmp/usr/bin/../lib/clang/3.4.1 -dependency-file - -MT sqlite3.o -sys-header-deps -D HAVE_CONFIG_H -I /home/builder/arm-build/head/kerberos5/lib/libheimsqlite/../../../crypto/heimdal/lib/sqlite -I /home/builder/arm-build/head/kerberos5/lib/libheimsqlite/../../include -isysroot /usr/obj/home/builder/arm-build/head/tmp -std=gnu99 -fno-dwarf-directory-asm -fdebug-compilation-dir /usr/obj/home/builder/arm-build/head/kerberos5/lib/libheimsqlite -ferror-limit 19 -fmessage-length 132 -mstackrealign -fno-signed-char -fobjc-runtime=gnustep -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -x c /home/builder/arm-build/head/kerberos5/lib/libheimsqlite/../../../crypto/heimdal/lib/sqlite/sqlite3.c 
cc: error: unable to execute command: Bus error (core dumped)
cc: error: clang frontend command failed due to signal (use -v to see invocation)
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: armv6--freebsd11.0-gnueabi
Thread model: posix
cc: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
cc: error: unable to execute command: Bus error (core dumped)
cc: note: diagnostic msg: Error generating preprocessed source(s).
mkdep: compile failed
*** Error code 1

Stop.
make[4]: stopped in /home/builder/arm-build/head/kerberos5/lib/libheimsqlite
*** Error code 1

Stop.
make[3]: stopped in /home/builder/arm-build/head
*** Error code 1

Stop.
make[2]: stopped in /home/builder/arm-build/head
*** Error code 1

Stop.
make[1]: stopped in /home/builder/arm-build/head
*** Error code 1

Stop.
make: stopped in /home/builder/arm-build/head
24569.709u 5898.985s 6:06:54.09 138.4%  116+219k 2557+11302io 77pf+0w
Exit 1
[175]wandboard# 

[180]wandboard# date
Wed Sep 10 10:20:14 UTC 2014
[181]wandboard# gdb /usr/obj/home/builder/arm-build/head/tmp/usr/bin/cc cc.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "armv6-marcel-freebsd"...(no debugging symbols found)...
Core was generated by `cc'.
Program terminated with signal 10, Bus error.
#0  0x008dc410 in clang::SrcMgr::ContentCache::getBuffer ()
(gdb) bt
#0  0x008dc410 in clang::SrcMgr::ContentCache::getBuffer ()
#1  0x00914330 in clang::SourceManager::getBuffer ()
#2  0x00912260 in clang::Preprocessor::EnterSourceFile ()
#3  0x008f70e8 in clang::Preprocessor::EnterMainSourceFile ()
#4  0x00013ac8 in clang::PreprocessOnlyAction::ExecuteAction ()
#5  0x00040a38 in clang::FrontendAction::Execute ()
#6  0x00060120 in clang::CompilerInstance::ExecuteAction ()
#7  0x00010340 in $a ()
#8  0x00010340 in $a ()


It's not obvious from -j8 run, but it happened when compiling in the same
directory, maybe even the same file.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

From daniloegea at yahoo.com.br  Wed Sep 10 20:54:03 2014
From: daniloegea at yahoo.com.br (Danilo Egea)
Date: Wed, 10 Sep 2014 13:52:02 -0700
Subject: panic: run_interrupt_driven_config_hooks: waited to long on
 10.1-PRERELEASE + RPI-B
Message-ID: <1410382322.23950.YahooMailNeo@web162003.mail.bf1.yahoo.com>

Hi all,

I updated my system on raspberry to 10.0-PRERELEASE (r271400) and now the system is stopping at this point [1].
This is a known problem?

Sorry the bad quality picture...

[1] - https://www.dropbox.com/sc/r89hs2wal7dpn44/AABCKqJzAB7FzlHugfUvQrUva

From daniloegea at yahoo.com.br  Wed Sep 10 21:00:00 2014
From: daniloegea at yahoo.com.br (Danilo Egea)
Date: Wed, 10 Sep 2014 13:56:36 -0700
Subject: panic: run_interrupt_driven_config_hooks: waited to long on
 10.1-PRERELEASE + RPI-B
In-Reply-To: <1410382322.23950.YahooMailNeo@web162003.mail.bf1.yahoo.com>
References: <1410382322.23950.YahooMailNeo@web162003.mail.bf1.yahoo.com> 
Message-ID: <1410382596.45838.YahooMailNeo@web162005.mail.bf1.yahoo.com>

Hi all,






I updated my system on raspberry to 10.0-PRERELEASE (r271400) and now the system is stopping at this point [1].
This is a known problem?

Sorry the bad quality picture...

[1] - https://www.dropbox.com/sc/r89hs2wal7dpn44/AABCKqJzAB7FzlHugfUvQrUva



Oops, sorry. The correct is 10.1-PRERELEASE, of course.

From hps at selasky.org  Wed Sep 10 21:04:55 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Wed, 10 Sep 2014 23:04:42 +0200
Subject: panic: run_interrupt_driven_config_hooks: waited to long on
 10.1-PRERELEASE + RPI-B
In-Reply-To: <1410382596.45838.YahooMailNeo@web162005.mail.bf1.yahoo.com>
References: <1410382322.23950.YahooMailNeo@web162003.mail.bf1.yahoo.com>
 <1410382596.45838.YahooMailNeo@web162005.mail.bf1.yahoo.com>
Message-ID: <5410BCEA.8060100@selasky.org>

On 09/10/14 22:56, Danilo Egea wrote:
> Hi all,
>
>
>
>
>
>
> I updated my system on raspberry to 10.0-PRERELEASE (r271400) and now the system is stopping at this point [1].
> This is a known problem?
>
> Sorry the bad quality picture...
>
> [1] - https://www.dropbox.com/sc/r89hs2wal7dpn44/AABCKqJzAB7FzlHugfUvQrUva
>
>
>
> Oops, sorry. The correct is 10.1-PRERELEASE, of course.

Hi,

What does "bt" say?

--HPS

From daniloegea at yahoo.com.br  Wed Sep 10 21:11:49 2014
From: daniloegea at yahoo.com.br (Danilo Egea)
Date: Wed, 10 Sep 2014 14:08:19 -0700
Subject: panic: run_interrupt_driven_config_hooks: waited to long on
 10.1-PRERELEASE + RPI-B
In-Reply-To: <5410BCEA.8060100@selasky.org>
References: <1410382322.23950.YahooMailNeo@web162003.mail.bf1.yahoo.com>
 <1410382596.45838.YahooMailNeo@web162005.mail.bf1.yahoo.com>
 <5410BCEA.8060100@selasky.org>
Message-ID: <1410383299.82284.YahooMailNeo@web162004.mail.bf1.yahoo.com>

On 09/10/14 22:56, Danilo Egea wrote:



> Hi all,
>
>
>
>
>
>
> I updated my system on raspberry to 10.0-PRERELEASE (r271400) and now the system is stopping at this point [1].
> This is a known problem?
>
> Sorry the bad quality picture...
>
> [1] - https://www.dropbox.com/sc/r89hs2wal7dpn44/AABCKqJzAB7FzlHugfUvQrUva
>
>
>
> Oops, sorry. The correct is 10.1-PRERELEASE, of course.


Hi,

What does "bt" say?

--HPS

This is another problem, the usb keyboard is not working at this point.

From jhb at freebsd.org  Wed Sep 10 21:20:00 2014
From: jhb at freebsd.org (John Baldwin)
Date: Wed, 10 Sep 2014 17:19:55 -0400
Subject: NEW_PCIB and arm take 3 (4?)
Message-ID: <74248385.OR9iBtFISv@ralph.baldwin.cx>

The plan for NEW_PCIB was for it to be a temporary option that would 
eventually become the default on all platforms.  I have long had patches to 
provide the one step of infrastructure (namely implementing "real" 
bus_activate_resource methods) for various arm chipsets, but I haven't been 
able to get anyone to review or test them.  I'm about at the point of just 
committing them in a week barring any specific reports from testers or 
reviewers.

You can read more about what NEW_PCIB is at:

   https://wiki.freebsd.org/NEW_PCIB

These patches aim to implement step 2 from that wiki page.  However, I have no 
way to test them (and to be honest, I haven't recently tested to see if they 
will compile.  I will ensure make universe passes before pushing them in if it 
comes down to that.)

   http://people.freebsd.org/~jhb/patches/arm_activate2.patch

As I noted previously, I don't know how to properly fix i80321_pci in large 
part because I do not understand what it is doing.  Warner had previously 
suggested just dropping it and if the consensus is to do that, I'd be much 
obliged for someone to make it so.

-- 
John Baldwin

From jmg at funkthat.com  Wed Sep 10 21:30:41 2014
From: jmg at funkthat.com (John-Mark Gurney)
Date: Wed, 10 Sep 2014 14:30:39 -0700
Subject: NEW_PCIB and arm take 3 (4?)
In-Reply-To: <74248385.OR9iBtFISv@ralph.baldwin.cx>
References: <74248385.OR9iBtFISv@ralph.baldwin.cx>
Message-ID: <20140910213039.GB82175@funkthat.com>

John Baldwin wrote this message on Wed, Sep 10, 2014 at 17:19 -0400:
> The plan for NEW_PCIB was for it to be a temporary option that would 
> eventually become the default on all platforms.  I have long had patches to 
> provide the one step of infrastructure (namely implementing "real" 
> bus_activate_resource methods) for various arm chipsets, but I haven't been 
> able to get anyone to review or test them.  I'm about at the point of just 
> committing them in a week barring any specific reports from testers or 
> reviewers.
> 
> You can read more about what NEW_PCIB is at:
> 
>    https://wiki.freebsd.org/NEW_PCIB
> 
> These patches aim to implement step 2 from that wiki page.  However, I have no 
> way to test them (and to be honest, I haven't recently tested to see if they 
> will compile.  I will ensure make universe passes before pushing them in if it 
> comes down to that.)
> 
>    http://people.freebsd.org/~jhb/patches/arm_activate2.patch
> 
> As I noted previously, I don't know how to properly fix i80321_pci in large 
> part because I do not understand what it is doing.  Warner had previously 
> suggested just dropping it and if the consensus is to do that, I'd be much 
> obliged for someone to make it so.

As before, I can test on AVILA (ixp425)...  What's the best way to
test the patch?  Just apply, build, boot and verify that things come
up sanely?

If so, I'll have results for you soon..

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From jmg at funkthat.com  Thu Sep 11 06:51:17 2014
From: jmg at funkthat.com (John-Mark Gurney)
Date: Wed, 10 Sep 2014 23:51:14 -0700
Subject: NEW_PCIB and arm take 3 (4?)
In-Reply-To: <20140910213039.GB82175@funkthat.com>
References: <74248385.OR9iBtFISv@ralph.baldwin.cx>
 <20140910213039.GB82175@funkthat.com>
Message-ID: <20140911065114.GJ82175@funkthat.com>

John-Mark Gurney wrote this message on Wed, Sep 10, 2014 at 14:30 -0700:
> John Baldwin wrote this message on Wed, Sep 10, 2014 at 17:19 -0400:
> > The plan for NEW_PCIB was for it to be a temporary option that would 
> > eventually become the default on all platforms.  I have long had patches to 
> > provide the one step of infrastructure (namely implementing "real" 
> > bus_activate_resource methods) for various arm chipsets, but I haven't been 
> > able to get anyone to review or test them.  I'm about at the point of just 
> > committing them in a week barring any specific reports from testers or 
> > reviewers.
> > 
> > You can read more about what NEW_PCIB is at:
> > 
> >    https://wiki.freebsd.org/NEW_PCIB
> > 
> > These patches aim to implement step 2 from that wiki page.  However, I have no 
> > way to test them (and to be honest, I haven't recently tested to see if they 
> > will compile.  I will ensure make universe passes before pushing them in if it 
> > comes down to that.)
> > 
> >    http://people.freebsd.org/~jhb/patches/arm_activate2.patch
> > 
> > As I noted previously, I don't know how to properly fix i80321_pci in large 
> > part because I do not understand what it is doing.  Warner had previously 
> > suggested just dropping it and if the consensus is to do that, I'd be much 
> > obliged for someone to make it so.
> 
> As before, I can test on AVILA (ixp425)...  What's the best way to
> test the patch?  Just apply, build, boot and verify that things come
> up sanely?
> 
> If so, I'll have results for you soon..

Ok, tested, and my AVILA board comes up fine and see the ath board
I have on it...

$ pciconf -lv
ath0 at pci0:0:2:0:	class=0x028000 card=0x2091168c chip=0x0029168c rev=0x01 hdr=0x00
    vendor     = 'Atheros Communications Inc.'
    device     = 'AR922X Wireless Network Adapter'
    class      = network

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From ian at FreeBSD.org  Thu Sep 11 14:05:51 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Thu, 11 Sep 2014 08:05:41 -0600
Subject: panic: run_interrupt_driven_config_hooks: waited to long on
 10.1-PRERELEASE + RPI-B
In-Reply-To: <1410382322.23950.YahooMailNeo@web162003.mail.bf1.yahoo.com>
References: <1410382322.23950.YahooMailNeo@web162003.mail.bf1.yahoo.com>
Message-ID: <1410444341.1150.439.camel@revolution.hippie.lan>

On Wed, 2014-09-10 at 13:52 -0700, Danilo Egea wrote:
> Hi all,
> 
> I updated my system on raspberry to 10.0-PRERELEASE (r271400) and now the system is stopping at this point [1].
> This is a known problem?
> 
> Sorry the bad quality picture...
> 
> [1] - https://www.dropbox.com/sc/r89hs2wal7dpn44/AABCKqJzAB7FzlHugfUvQrUva

I sync'd to the same stable-10 revision and built a fresh world and
kernel and it boots fine.  The big difference is that I don't use a
video console, just serial.  I don't know if that's a factor in why you
see a hang or not.

-- Ian



From daniloegea at yahoo.com.br  Fri Sep 12 16:00:09 2014
From: daniloegea at yahoo.com.br (Danilo Egea Gondolfo)
Date: Fri, 12 Sep 2014 13:02:49 -0300
Subject: panic: run_interrupt_driven_config_hooks: waited to long on
 10.1-PRERELEASE + RPI-B
In-Reply-To: <1410444341.1150.439.camel@revolution.hippie.lan>
References: <1410382322.23950.YahooMailNeo@web162003.mail.bf1.yahoo.com>
 <1410444341.1150.439.camel@revolution.hippie.lan>
Message-ID: <54131929.10208@yahoo.com.br>

On 09/11/14 11:05, Ian Lepore wrote:
> On Wed, 2014-09-10 at 13:52 -0700, Danilo Egea wrote:
>> Hi all,
>>
>> I updated my system on raspberry to 10.0-PRERELEASE (r271400) and now the system is stopping at this point [1].
>> This is a known problem?
>>
>> Sorry the bad quality picture...
>>
>> [1] - https://www.dropbox.com/sc/r89hs2wal7dpn44/AABCKqJzAB7FzlHugfUvQrUva
> I sync'd to the same stable-10 revision and built a fresh world and
> kernel and it boots fine.  The big difference is that I don't use a
> video console, just serial.  I don't know if that's a factor in why you
> see a hang or not.
>
> -- Ian
>
>
>
Ok, now I have a serial cable.

Now it's freezing and I can't run a "bt".

I noticed these lines:
"VT: initialize with new VT driver "fb".
device_attach: fbd0 attach returned 6
fb0: Failed to attach fbd device"

With other kernel config I got this bt: http://pastebin.com/FUVCwt7B

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by U-Boot at address 0x0x100.
Kernel entry at 0x100100...
Kernel args: (null)
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2014 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 10.1-BETA1 #0 r271466: Fri Sep 12 11:41:47 BRT 2014
root at danilo:/home/danilo/Mestrado/Sources/crochet-freebsd/work/obj/arm.armv6/home/danilo/Sources/freebsd-10-stable/sys/RPI-B 
arm
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
VT: init without driver.
CPU: ARM1176JZ-S rev 7 (ARM11J core)
  Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext
  WB enabled LABT branch prediction enabled
   16KB/32B 4-way instruction cache
   16KB/32B 4-way write-back-locking-C data cache
real memory  = 536866816 (511 MB)
avail memory = 482893824 (460 MB)
random device not loaded; using insecure entropy
random: <Software, Yarrow> initialized
kbd0 at kbdmux0
ofwbus0: <Open Firmware Device Tree>
simplebus0: <Flattened device tree simple bus> mem 0x20000000-0x20ffffff 
on ofwbus0
intc0: <BCM2835 Interrupt Controller> mem 0xb200-0xb3ff on simplebus0
systimer0: <BCM2835 System Timer> mem 0x3000-0x3fff irq 8,9,10,11 on 
simplebus0
Event timer "BCM2835 Event Timer 3" frequency 1000000 Hz quality 1000
Timecounter "BCM2835 Timecounter" frequency 1000000 Hz quality 1000
bcmwd0: <BCM2708/2835 Watchdog> mem 0x10001c-0x100027 on simplebus0
gpio0: <BCM2708/2835 GPIO controller> mem 0x200000-0x2000af irq 
57,59,58,60 on simplebus0
gpio0: read-only pins: 46,47,48,49,50,51,52,53.
gpio0: reserved pins: 48,49,50,51,52,53.
gpioc0: <GPIO controller> on gpio0
gpiobus0: <OFW GPIO bus> on gpio0
gpioled0: <GPIO led> at pin(s) 16 on gpiobus0
iichb0: <BCM2708/2835 BSC controller> mem 0x205000-0x20501f irq 61 on 
simplebus0
iicbus0: <OFW I2C bus> on iichb0
iic0: <I2C generic I/O> on iicbus0
iichb1: <BCM2708/2835 BSC controller> mem 0x804000-0x80401f irq 61 on 
simplebus0
iicbus1: <OFW I2C bus> on iichb1
iic1: <I2C generic I/O> on iicbus1
spi0: <BCM2708/2835 SPI controller> mem 0x204000-0x20401f irq 62 on 
simplebus0
spibus0: <OFW SPI bus> on spi0
bcm_dma0: <BCM2835 DMA Controller> mem 0x7000-0x7fff,0xe05000-0xe05fff 
irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0
mbox0: <BCM2835 VideoCore Mailbox> mem 0xb880-0xb8bf irq 1 on simplebus0
sdhci_bcm0: <Broadcom 2708 SDHCI controller> mem 0x300000-0x3000ff irq 
70 on simplebus0
mmc0: <MMC/SD bus> on sdhci_bcm0
uart0: <PrimeCell UART (PL011)> mem 0x201000-0x201fff irq 65 on simplebus0
uart0: console (115200,n,8,1)
dwcotg0: <DWC OTG 2.0 integrated USB controller> mem 0x980000-0x99ffff 
irq 17 on simplebus0
usbus0 on dwcotg0
fb0: <BCM2835 VT framebuffer driver> on ofwbus0
simplebus1: <Flattened device tree simple bus> on ofwbus0
simplebus1: could not get ranges
device_attach: simplebus1 attach returned 6
Timecounters tick every 10.000 msec
usbus0: 480Mbps High Speed USB v2.0
ugen0.1: <DWCOTG> at usbus0
uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
mmcsd0: 4GB <SDHC SA04G 1.0 SN 1A93CC12 MFG 07/2012 by 2 TM> at mmc0 
50.0MHz/4bit/65535-block
fb0: 656x416(0x0 at 0,0) 16bpp
fb0: pitch 1312, base 0x5e006000, screen_size 545792
fbd0 on fb0
VT: initialize with new VT driver "fb".
device_attach: fbd0 attach returned 6
fb0: Failed to attach fbd device
uhub0: 1 port with 1 removable, self powered
ugen0.2: <vendor 0x0424> at usbus0
uhub1: <vendor 0x0424 product 0x9514, class 9/0, rev 2.00/2.00, addr 2> 
on usbus0
uhub1: MTT enabled
uhub1: 5 ports with 4 removable, self powered
random: unblocking device.
ugen0.3: <vendor 0x0424> at usbus0
smsc0: <vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3> on usbus0
smsc0: chip 0xec00, rev. 0002
miibus0: <MII bus> on smsc0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0: <USB Ethernet> on smsc0
ue0: Ethernet address: b8:27:eb:60:d9:9b
run_interrupt_driven_hooks: still waiting after 60 seconds for bcm_fb_init
run_interrupt_driven_hooks: still waiting after 120 seconds for bcm_fb_init
run_interrupt_driven_hooks: still waiting after 180 seconds for bcm_fb_init
run_interrupt_driven_hooks: still waiting after 240 seconds for bcm_fb_init
run_interrupt_driven_hooks: still waiting after 300 seconds for bcm_fb_init

From jhb at freebsd.org  Fri Sep 12 20:35:12 2014
From: jhb at freebsd.org (John Baldwin)
Date: Fri, 12 Sep 2014 16:34:36 -0400
Subject: NEW_PCIB and arm take 3 (4?)
In-Reply-To: <20140911065114.GJ82175@funkthat.com>
References: <74248385.OR9iBtFISv@ralph.baldwin.cx>
 <20140910213039.GB82175@funkthat.com> <20140911065114.GJ82175@funkthat.com>
Message-ID: <2090192.XxU5luGasi@ralph.baldwin.cx>

On Wednesday, September 10, 2014 11:51:14 PM John-Mark Gurney wrote:
> John-Mark Gurney wrote this message on Wed, Sep 10, 2014 at 14:30 -0700:
> > John Baldwin wrote this message on Wed, Sep 10, 2014 at 17:19 -0400:
> > > The plan for NEW_PCIB was for it to be a temporary option that would
> > > eventually become the default on all platforms.  I have long had patches
> > > to
> > > provide the one step of infrastructure (namely implementing "real"
> > > bus_activate_resource methods) for various arm chipsets, but I haven't
> > > been
> > > able to get anyone to review or test them.  I'm about at the point of
> > > just
> > > committing them in a week barring any specific reports from testers or
> > > reviewers.
> > > 
> > > You can read more about what NEW_PCIB is at:
> > >    https://wiki.freebsd.org/NEW_PCIB
> > > 
> > > These patches aim to implement step 2 from that wiki page.  However, I
> > > have no way to test them (and to be honest, I haven't recently tested
> > > to see if they will compile.  I will ensure make universe passes before
> > > pushing them in if it comes down to that.)
> > > 
> > >    http://people.freebsd.org/~jhb/patches/arm_activate2.patch
> > > 
> > > As I noted previously, I don't know how to properly fix i80321_pci in
> > > large
> > > part because I do not understand what it is doing.  Warner had
> > > previously
> > > suggested just dropping it and if the consensus is to do that, I'd be
> > > much
> > > obliged for someone to make it so.
> > 
> > As before, I can test on AVILA (ixp425)...  What's the best way to
> > test the patch?  Just apply, build, boot and verify that things come
> > up sanely?
> > 
> > If so, I'll have results for you soon..
> 
> Ok, tested, and my AVILA board comes up fine and see the ath board
> I have on it...
> 
> $ pciconf -lv
> ath0 at pci0:0:2:0:	class=0x028000 card=0x2091168c chip=0x0029168c rev=0x01
> hdr=0x00 vendor     = 'Atheros Communications Inc.'
>     device     = 'AR922X Wireless Network Adapter'
>     class      = network

Perfect, thanks!

-- 
John Baldwin

From ian at FreeBSD.org  Fri Sep 12 21:30:55 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Fri, 12 Sep 2014 15:30:45 -0600
Subject: panic: run_interrupt_driven_config_hooks: waited to long on
 10.1-PRERELEASE + RPI-B
In-Reply-To: <54131929.10208@yahoo.com.br>
References: <1410382322.23950.YahooMailNeo@web162003.mail.bf1.yahoo.com>
 <1410444341.1150.439.camel@revolution.hippie.lan>
 <54131929.10208@yahoo.com.br>
Message-ID: <1410557445.1150.473.camel@revolution.hippie.lan>

On Fri, 2014-09-12 at 13:02 -0300, Danilo Egea Gondolfo wrote:
> On 09/11/14 11:05, Ian Lepore wrote:
> > On Wed, 2014-09-10 at 13:52 -0700, Danilo Egea wrote:
> >> Hi all,
> >>
> >> I updated my system on raspberry to 10.0-PRERELEASE (r271400) and now the system is stopping at this point [1].
> >> This is a known problem?
> >>
> >> Sorry the bad quality picture...
> >>
> >> [1] - https://www.dropbox.com/sc/r89hs2wal7dpn44/AABCKqJzAB7FzlHugfUvQrUva
> > I sync'd to the same stable-10 revision and built a fresh world and
> > kernel and it boots fine.  The big difference is that I don't use a
> > video console, just serial.  I don't know if that's a factor in why you
> > see a hang or not.
> >
> > -- Ian
> >
> >
> >
> Ok, now I have a serial cable.
> 
> Now it's freezing and I can't run a "bt".
> 
> I noticed these lines:
> "VT: initialize with new VT driver "fb".
> device_attach: fbd0 attach returned 6
> fb0: Failed to attach fbd device"
> 
> With other kernel config I got this bt: http://pastebin.com/FUVCwt7B
> 
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...
> Using DTB provided by U-Boot at address 0x0x100.
> Kernel entry at 0x100100...
> Kernel args: (null)
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> Copyright (c) 1992-2014 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 10.1-BETA1 #0 r271466: Fri Sep 12 11:41:47 BRT 2014
> root at danilo:/home/danilo/Mestrado/Sources/crochet-freebsd/work/obj/arm.armv6/home/danilo/Sources/freebsd-10-stable/sys/RPI-B 
> arm
> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
> VT: init without driver.
> CPU: ARM1176JZ-S rev 7 (ARM11J core)
>   Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext
>   WB enabled LABT branch prediction enabled
>    16KB/32B 4-way instruction cache
>    16KB/32B 4-way write-back-locking-C data cache
> real memory  = 536866816 (511 MB)
> avail memory = 482893824 (460 MB)
> random device not loaded; using insecure entropy
> random: <Software, Yarrow> initialized
> kbd0 at kbdmux0
> ofwbus0: <Open Firmware Device Tree>
> simplebus0: <Flattened device tree simple bus> mem 0x20000000-0x20ffffff 
> on ofwbus0
> intc0: <BCM2835 Interrupt Controller> mem 0xb200-0xb3ff on simplebus0
> systimer0: <BCM2835 System Timer> mem 0x3000-0x3fff irq 8,9,10,11 on 
> simplebus0
> Event timer "BCM2835 Event Timer 3" frequency 1000000 Hz quality 1000
> Timecounter "BCM2835 Timecounter" frequency 1000000 Hz quality 1000
> bcmwd0: <BCM2708/2835 Watchdog> mem 0x10001c-0x100027 on simplebus0
> gpio0: <BCM2708/2835 GPIO controller> mem 0x200000-0x2000af irq 
> 57,59,58,60 on simplebus0
> gpio0: read-only pins: 46,47,48,49,50,51,52,53.
> gpio0: reserved pins: 48,49,50,51,52,53.
> gpioc0: <GPIO controller> on gpio0
> gpiobus0: <OFW GPIO bus> on gpio0
> gpioled0: <GPIO led> at pin(s) 16 on gpiobus0
> iichb0: <BCM2708/2835 BSC controller> mem 0x205000-0x20501f irq 61 on 
> simplebus0
> iicbus0: <OFW I2C bus> on iichb0
> iic0: <I2C generic I/O> on iicbus0
> iichb1: <BCM2708/2835 BSC controller> mem 0x804000-0x80401f irq 61 on 
> simplebus0
> iicbus1: <OFW I2C bus> on iichb1
> iic1: <I2C generic I/O> on iicbus1
> spi0: <BCM2708/2835 SPI controller> mem 0x204000-0x20401f irq 62 on 
> simplebus0
> spibus0: <OFW SPI bus> on spi0
> bcm_dma0: <BCM2835 DMA Controller> mem 0x7000-0x7fff,0xe05000-0xe05fff 
> irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0
> mbox0: <BCM2835 VideoCore Mailbox> mem 0xb880-0xb8bf irq 1 on simplebus0
> sdhci_bcm0: <Broadcom 2708 SDHCI controller> mem 0x300000-0x3000ff irq 
> 70 on simplebus0
> mmc0: <MMC/SD bus> on sdhci_bcm0
> uart0: <PrimeCell UART (PL011)> mem 0x201000-0x201fff irq 65 on simplebus0
> uart0: console (115200,n,8,1)
> dwcotg0: <DWC OTG 2.0 integrated USB controller> mem 0x980000-0x99ffff 
> irq 17 on simplebus0
> usbus0 on dwcotg0
> fb0: <BCM2835 VT framebuffer driver> on ofwbus0
> simplebus1: <Flattened device tree simple bus> on ofwbus0
> simplebus1: could not get ranges
> device_attach: simplebus1 attach returned 6
> Timecounters tick every 10.000 msec
> usbus0: 480Mbps High Speed USB v2.0
> ugen0.1: <DWCOTG> at usbus0
> uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
> mmcsd0: 4GB <SDHC SA04G 1.0 SN 1A93CC12 MFG 07/2012 by 2 TM> at mmc0 
> 50.0MHz/4bit/65535-block
> fb0: 656x416(0x0 at 0,0) 16bpp
> fb0: pitch 1312, base 0x5e006000, screen_size 545792
> fbd0 on fb0
> VT: initialize with new VT driver "fb".
> device_attach: fbd0 attach returned 6
> fb0: Failed to attach fbd device
> uhub0: 1 port with 1 removable, self powered
> ugen0.2: <vendor 0x0424> at usbus0
> uhub1: <vendor 0x0424 product 0x9514, class 9/0, rev 2.00/2.00, addr 2> 
> on usbus0
> uhub1: MTT enabled
> uhub1: 5 ports with 4 removable, self powered
> random: unblocking device.
> ugen0.3: <vendor 0x0424> at usbus0
> smsc0: <vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3> on usbus0
> smsc0: chip 0xec00, rev. 0002
> miibus0: <MII bus> on smsc0
> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
> ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> ue0: <USB Ethernet> on smsc0
> ue0: Ethernet address: b8:27:eb:60:d9:9b
> run_interrupt_driven_hooks: still waiting after 60 seconds for bcm_fb_init
> run_interrupt_driven_hooks: still waiting after 120 seconds for bcm_fb_init
> run_interrupt_driven_hooks: still waiting after 180 seconds for bcm_fb_init
> run_interrupt_driven_hooks: still waiting after 240 seconds for bcm_fb_init
> run_interrupt_driven_hooks: still waiting after 300 seconds for bcm_fb_init

This looks like it's somehow related to the the frame buffer driver or
the new vt(4) driver.  I'm cc'ing Aleksander who knows more than I do
about that stuff. :)

-- Ian



From fzv at yahoo.com  Fri Sep 12 23:05:00 2014
From: fzv at yahoo.com (Faraz Vahabzadeh)
Date: Fri, 12 Sep 2014 16:02:08 -0700
Subject: SD card support on Sheevaplug
Message-ID: <1410562928.1909.YahooMailBasic@web122404.mail.ne1.yahoo.com>

Hi,

I am wondering if the state of SD card support on Sheevaplug for FreeBSD has seen any changes
lately. The latest news I have is from a year ago:

https://forums.freebsd.org/viewtopic.php?&t=41592

Or if there are any workaround to make it work, I'd really appreciate it.

Thanks,
Raz


From bugzilla-noreply at freebsd.org  Sat Sep 13 15:10:43 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 13 Sep 2014 15:10:42 +0000
Subject: [Bug 193608] New: cubieboard2: kernel crash on disconnect/connect
 serial console
Message-ID: <bug-193608-7@https.bugs.freebsd.org/bugzilla/>

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193608

            Bug ID: 193608
           Summary: cubieboard2: kernel crash on disconnect/connect serial
                    console
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: arm
                OS: Any
            Status: Needs Triage
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm at FreeBSD.org
          Reporter: che at bein.link

Using my cubieboard2, I disconnected serial and connected it back. Here's what
I got:

[19:07:28] ]che at quad:~[$ sudo cu -s 115200 -l /dev/ttyU0
Connected


FreeBSD/arm (cubie) (ttyu0)

login: ~
[EOT]
[19:07:33] ]che at quad:~[$ sudo cu -s 115200 -l /dev/ttyU0
/dev/ttyU0: No such file or directory
link down
[19:07:44] ]che at quad:~[$ sudo cu -s 115200 -l /dev/ttyU0
Connected

Bad character in number
KDB: reentering
KDB: stack backtrace:
db_trace_self() at db_trace_self
pc = 0xc0509f5c  lr = 0xc02347dc (X_db_symbol_values+0x11c)
sp = 0xebbd68b8  fp = 0xebbd69d0
r10 = 0xc0639aa4
X_db_symbol_values() at X_db_symbol_values+0x11c
pc = 0xc02347dc  lr = 0xc0371188 (kdb_reenter+0x60)
sp = 0xebbd69d8  fp = 0xebbd69e0
r4 = 0xc0639ac0  r5 = 0xc0639aa4
r6 = 0x00000008  r7 = 0x00000009
kdb_reenter() at kdb_reenter+0x60
pc = 0xc0371188  lr = 0xc0232394 (db_error+0x24)
sp = 0xebbd69e8  fp = 0xebbd69e8
r4 = 0x00000069  r5 = 0xc06276f0
db_error() at db_error+0x24
pc = 0xc0232394  lr = 0xc0234194 (db_read_token+0x230)
sp = 0xebbd69f0  fp = 0xebbd6a08
db_read_token() at db_read_token+0x230
pc = 0xc0234194  lr = 0xc0231f88 (db_command_loop+0xa0)
sp = 0xebbd6a10  fp = 0xebbd6ab0
r4 = 0xc0546bcc  r5 = 0xc0563b71
r6 = 0xc08de1a8  r7 = 0xebbd6c98
r8 = 0x00000001  r9 = 0xc05f8688
db_command_loop() at db_command_loop+0xa0
pc = 0xc0231f88  lr = 0xc0231f48 (db_command_loop+0x60)
sp = 0xebbd6ab8  fp = 0xebbd6ac8
r4 = 0xc0546bcc  r5 = 0xc0563b71
r6 = 0xc08de1a8  r7 = 0xebbd6c98
r8 = 0x00000001  r9 = 0xc05f8688
r10 = 0xc0639aa4
db_command_loop() at db_command_loop+0x60
pc = 0xc0231f48  lr = 0xc0234910 (X_db_symbol_values+0x250)
sp = 0xebbd6ad0  fp = 0xebbd6bf0
r4 = 0x00000000  r5 = 0xc08de1b4
r6 = 0xc0639ac8
X_db_symbol_values() at X_db_symbol_values+0x250
pc = 0xc0234910  lr = 0xc0371580 (kdb_trap+0x15c)
sp = 0xebbd6bf8  fp = 0xebbd6c18
r4 = 0x00000000  r5 = 0x00000001
r6 = 0xc0639ac8  r7 = 0xebbd6c98
kdb_trap() at kdb_trap+0x15c
pc = 0xc0371580  lr = 0xc0520aa0 (undefinedinstruction+0x2c4)
sp = 0xebbd6c20  fp = 0xebbd6c90
r4 = 0x00000000  r5 = 0x00000000
r6 = 0xc052072c  r7 = 0xe7ffffff
r8 = 0xc3a86960  r9 = 0xc0370c70
r10 = 0xebbd6c98
undefinedinstruction() at undefinedinstruction+0x2c4
pc = 0xc0520aa0  lr = 0xc050bc44 (exception_exit)
sp = 0xebbd6c98  fp = 0xebbd6cf0
r4 = 0x00000001  r5 = 0xebbd6d80
r6 = 0xc391b174  r7 = 0x00060000
r8 = 0x00000001  r9 = 0xc05fc588
r10 = 0xc391b000
exception_exit() at exception_exit
pc = 0xc050bc44  lr = 0xc0370c60 (kdb_break+0x50)
sp = 0xebbd6ce8  fp = 0xebbd6cf0
r0 = 0xc0639ab4  r1 = 0x00000000
r2 = 0x00000001  r3 = 0x60000193
r4 = 0x00000001  r5 = 0xebbd6d80
r6 = 0xc391b174  r7 = 0x00060000
r8 = 0x00000001  r9 = 0xc05fc588
r10 = 0xc391b000 r12 = 0x00000000
kdb_break() at kdb_break+0x64
pc = 0xc0370c74  lr = 0xc026379c (uart_bus_attach+0x608)
sp = 0xebbd6cf8  fp = 0xebbd6d38
r4 = 0x00000000
uart_bus_attach() at uart_bus_attach+0x608
pc = 0xc026379c  lr = 0xc03093d4 (intr_event_handle+0x7c)
sp = 0xebbd6d40  fp = 0xebbd6d60
r4 = 0xc3959100  r5 = 0xebbd6d80
r6 = 0xc08e784c  r7 = 0xc3a86960
r8 = 0x00000000  r9 = 0xc055da58
r10 = 0xc3b14180
intr_event_handle() at intr_event_handle+0x7c
pc = 0xc03093d4  lr = 0xc050d0f4 (arm_irq_handler+0x60)
sp = 0xebbd6d68  fp = 0xebbd6d78
r4 = 0xebbd6d80  r5 = 0x00000021
r6 = 0xc08e784c  r7 = 0xc08daa4c
r8 = 0x0000055a  r9 = 0x00000000
r10 = 0xc055d92e
arm_irq_handler() at arm_irq_handler+0x60
pc = 0xc050d0f4  lr = 0xc050bc44 (exception_exit)
sp = 0xebbd6d80  fp = 0xebbd6dd8
r4 = 0xc3a86960  r5 = 0xc0638e14
r6 = 0x00000000  r7 = 0xc055d92e
exception_exit() at exception_exit
pc = 0xc050bc44  lr = 0xc050d8d4 (spinlock_exit+0x14)
sp = 0xebbd6dd0  fp = 0xebbd6dd8
r0 = 0x00000000  r1 = 0x000000c0
r2 = 0x600001d3  r3 = 0x60000113
r4 = 0xc3a86960  r5 = 0xc0638e14
r6 = 0x00000000  r7 = 0xc055d92e
r8 = 0x0000055a  r9 = 0x00000000
r10 = 0xc055d92e r12 = 0x00000000
spinlock_exit() at spinlock_exit+0x40
pc = 0xc050d900  lr = 0xc03243ec (__mtx_unlock_spin_flags+0xd4)
sp = 0xebbd6de0  fp = 0xebbd6df8
r4 = 0xc0638e24
__mtx_unlock_spin_flags() at __mtx_unlock_spin_flags+0xd4
pc = 0xc03243ec  lr = 0xc0309d20 (db_dump_intr_event+0x864)
sp = 0xebbd6e00  fp = 0xebbd6e38
r4 = 0xc3910f70  r5 = 0xc3a86960
r6 = 0xc3959b00  r7 = 0xc0608c20
r8 = 0xc08df1f0
db_dump_intr_event() at db_dump_intr_event+0x864
pc = 0xc0309d20  lr = 0xc0306b04 (fork_exit+0xa0)
sp = 0xebbd6e40  fp = 0xebbd6e58
r4 = 0xc3a86960  r5 = 0xc3a84000
r6 = 0xc0309b28  r7 = 0xc3910f70
r8 = 0xebbd6e60  r9 = 0x00000000
r10 = 0x00000000
fork_exit() at fork_exit+0xa0
pc = 0xc0306b04  lr = 0xc050bbd4 (swi_exit)
sp = 0xebbd6e60  fp = 0x00000000
r4 = 0xc0309b28  r5 = 0xc3910f70
r6 = 0x00000000  r7 = 0x00000000
r8 = 0x00000000
swi_exit() at swi_exit
pc = 0xc050bbd4  lr = 0xc050bbd4 (swi_exit)
sp = 0xebbd6e60  fp = 0x00000000
Unable to unwind further
db>

-- 
You are receiving this mail because:
You are the assignee for the bug.

From sales03 at laptoppartsupply.com  Tue Sep 16 14:10:57 2014
From: sales03 at laptoppartsupply.com (sales03 at laptoppartsupply.com)
Date: Tue, 16 Sep 2014 22:04:25 +0800
Subject: =?UTF-8?B?UHJvZmVzc2lvbmFsIE1hbnVmYWN0dXJlIExhcHRvcCBBQyBBZGFwdGVyICA=?=
Message-ID: <525cc219-e733-4ec8-a198-6a577c07a99e@laptoppartsupply.com>

Hi 
dear Friend,




































































































































?

We have the pleasure of contacting with you 
today.

?


We're a leading manufacturer of all kinds of laptop 
adapters, concluding Unniversal AC/Car adapter, Tablet adapter, Wall Mount 
adapter, Mini adapter, Original adapter and more, as well as laptop batteries 
and Ipone accessories. All these account more than 1000 models with more than 1 
year warranty and no MOQ.

?











Should you have any questions or inquires, please do not 
hesitate to let me know.

?











We would be thankful to cooperate with 
you.

































Thanks and Best Regards!
















Betty (sales 
manager)





?

Shenzhen Hongda Shun 
Technology Development Co.,Ltd.

HK Flying 
International Co.,Limited

E-mail:sales04 at hundapower.com; Skype:fyadapter? 
ICQ:612623446

Website:?http://www.fy-adapter.com;?http://www.hundapower.com;?http://hongdashun.en.alibaba.com/

Address:401-2,No.218-2,Henan 
New Village,Dafu Community,Guanlan,Longhua New 
District,Shenzhen,Guangdong,China.








































































































































































































































































































































































































































From daniloegea at yahoo.com.br  Thu Sep 18 14:18:25 2014
From: daniloegea at yahoo.com.br (Danilo Egea Gondolfo)
Date: Thu, 18 Sep 2014 11:18:16 -0300
Subject: panic: run_interrupt_driven_config_hooks: waited to long on
 10.1-PRERELEASE + RPI-B
In-Reply-To: <1410557445.1150.473.camel@revolution.hippie.lan>
References: <1410382322.23950.YahooMailNeo@web162003.mail.bf1.yahoo.com>	
 <1410444341.1150.439.camel@revolution.hippie.lan>	
 <54131929.10208@yahoo.com.br>
 <1410557445.1150.473.camel@revolution.hippie.lan>
Message-ID: <541AE9A8.5030901@yahoo.com.br>


On 09/12/14 18:30, Ian Lepore wrote:
> On Fri, 2014-09-12 at 13:02 -0300, Danilo Egea Gondolfo wrote:
>> On 09/11/14 11:05, Ian Lepore wrote:
>>> On Wed, 2014-09-10 at 13:52 -0700, Danilo Egea wrote:
>>>> Hi all,
>>>>
>>>> I updated my system on raspberry to 10.0-PRERELEASE (r271400) and now the system is stopping at this point [1].
>>>> This is a known problem?
>>>>
>>>> Sorry the bad quality picture...
>>>>
>>>> [1] - https://www.dropbox.com/sc/r89hs2wal7dpn44/AABCKqJzAB7FzlHugfUvQrUva
>>> I sync'd to the same stable-10 revision and built a fresh world and
>>> kernel and it boots fine.  The big difference is that I don't use a
>>> video console, just serial.  I don't know if that's a factor in why you
>>> see a hang or not.
>>>
>>> -- Ian
>>>
>>>
>>>
>> Ok, now I have a serial cable.
>>
>> Now it's freezing and I can't run a "bt".
>>
>> I noticed these lines:
>> "VT: initialize with new VT driver "fb".
>> device_attach: fbd0 attach returned 6
>> fb0: Failed to attach fbd device"
>>
>> With other kernel config I got this bt: http://pastebin.com/FUVCwt7B
>>
>> Hit [Enter] to boot immediately, or any other key for command prompt.
>> Booting [/boot/kernel/kernel]...
>> Using DTB provided by U-Boot at address 0x0x100.
>> Kernel entry at 0x100100...
>> Kernel args: (null)
>> KDB: debugger backends: ddb
>> KDB: current backend: ddb
>> Copyright (c) 1992-2014 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 10.1-BETA1 #0 r271466: Fri Sep 12 11:41:47 BRT 2014
>> root at danilo:/home/danilo/Mestrado/Sources/crochet-freebsd/work/obj/arm.armv6/home/danilo/Sources/freebsd-10-stable/sys/RPI-B
>> arm
>> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
>> VT: init without driver.
>> CPU: ARM1176JZ-S rev 7 (ARM11J core)
>>    Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext
>>    WB enabled LABT branch prediction enabled
>>     16KB/32B 4-way instruction cache
>>     16KB/32B 4-way write-back-locking-C data cache
>> real memory  = 536866816 (511 MB)
>> avail memory = 482893824 (460 MB)
>> random device not loaded; using insecure entropy
>> random: <Software, Yarrow> initialized
>> kbd0 at kbdmux0
>> ofwbus0: <Open Firmware Device Tree>
>> simplebus0: <Flattened device tree simple bus> mem 0x20000000-0x20ffffff
>> on ofwbus0
>> intc0: <BCM2835 Interrupt Controller> mem 0xb200-0xb3ff on simplebus0
>> systimer0: <BCM2835 System Timer> mem 0x3000-0x3fff irq 8,9,10,11 on
>> simplebus0
>> Event timer "BCM2835 Event Timer 3" frequency 1000000 Hz quality 1000
>> Timecounter "BCM2835 Timecounter" frequency 1000000 Hz quality 1000
>> bcmwd0: <BCM2708/2835 Watchdog> mem 0x10001c-0x100027 on simplebus0
>> gpio0: <BCM2708/2835 GPIO controller> mem 0x200000-0x2000af irq
>> 57,59,58,60 on simplebus0
>> gpio0: read-only pins: 46,47,48,49,50,51,52,53.
>> gpio0: reserved pins: 48,49,50,51,52,53.
>> gpioc0: <GPIO controller> on gpio0
>> gpiobus0: <OFW GPIO bus> on gpio0
>> gpioled0: <GPIO led> at pin(s) 16 on gpiobus0
>> iichb0: <BCM2708/2835 BSC controller> mem 0x205000-0x20501f irq 61 on
>> simplebus0
>> iicbus0: <OFW I2C bus> on iichb0
>> iic0: <I2C generic I/O> on iicbus0
>> iichb1: <BCM2708/2835 BSC controller> mem 0x804000-0x80401f irq 61 on
>> simplebus0
>> iicbus1: <OFW I2C bus> on iichb1
>> iic1: <I2C generic I/O> on iicbus1
>> spi0: <BCM2708/2835 SPI controller> mem 0x204000-0x20401f irq 62 on
>> simplebus0
>> spibus0: <OFW SPI bus> on spi0
>> bcm_dma0: <BCM2835 DMA Controller> mem 0x7000-0x7fff,0xe05000-0xe05fff
>> irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0
>> mbox0: <BCM2835 VideoCore Mailbox> mem 0xb880-0xb8bf irq 1 on simplebus0
>> sdhci_bcm0: <Broadcom 2708 SDHCI controller> mem 0x300000-0x3000ff irq
>> 70 on simplebus0
>> mmc0: <MMC/SD bus> on sdhci_bcm0
>> uart0: <PrimeCell UART (PL011)> mem 0x201000-0x201fff irq 65 on simplebus0
>> uart0: console (115200,n,8,1)
>> dwcotg0: <DWC OTG 2.0 integrated USB controller> mem 0x980000-0x99ffff
>> irq 17 on simplebus0
>> usbus0 on dwcotg0
>> fb0: <BCM2835 VT framebuffer driver> on ofwbus0
>> simplebus1: <Flattened device tree simple bus> on ofwbus0
>> simplebus1: could not get ranges
>> device_attach: simplebus1 attach returned 6
>> Timecounters tick every 10.000 msec
>> usbus0: 480Mbps High Speed USB v2.0
>> ugen0.1: <DWCOTG> at usbus0
>> uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
>> mmcsd0: 4GB <SDHC SA04G 1.0 SN 1A93CC12 MFG 07/2012 by 2 TM> at mmc0
>> 50.0MHz/4bit/65535-block
>> fb0: 656x416(0x0 at 0,0) 16bpp
>> fb0: pitch 1312, base 0x5e006000, screen_size 545792
>> fbd0 on fb0
>> VT: initialize with new VT driver "fb".
>> device_attach: fbd0 attach returned 6
>> fb0: Failed to attach fbd device
>> uhub0: 1 port with 1 removable, self powered
>> ugen0.2: <vendor 0x0424> at usbus0
>> uhub1: <vendor 0x0424 product 0x9514, class 9/0, rev 2.00/2.00, addr 2>
>> on usbus0
>> uhub1: MTT enabled
>> uhub1: 5 ports with 4 removable, self powered
>> random: unblocking device.
>> ugen0.3: <vendor 0x0424> at usbus0
>> smsc0: <vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3> on usbus0
>> smsc0: chip 0xec00, rev. 0002
>> miibus0: <MII bus> on smsc0
>> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
>> ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>> ue0: <USB Ethernet> on smsc0
>> ue0: Ethernet address: b8:27:eb:60:d9:9b
>> run_interrupt_driven_hooks: still waiting after 60 seconds for bcm_fb_init
>> run_interrupt_driven_hooks: still waiting after 120 seconds for bcm_fb_init
>> run_interrupt_driven_hooks: still waiting after 180 seconds for bcm_fb_init
>> run_interrupt_driven_hooks: still waiting after 240 seconds for bcm_fb_init
>> run_interrupt_driven_hooks: still waiting after 300 seconds for bcm_fb_init
> This looks like it's somehow related to the the frame buffer driver or
> the new vt(4) driver.  I'm cc'ing Aleksander who knows more than I do
> about that stuff. :)
>
> -- Ian
>
>
>
Hello again,

The last snapshot of 10.1 has the same problem. Just to make sure, I'll 
test it with another raspberry later.

Here is the complete boot log http://pastebin.com/SEX64FNv

I'd like to highlight this (again):

VT: initialize with new VT driver "fb".
device_attach: fbd0 attach returned 6
fb0: Failed to attach fbd device

and this (in the backtrace):

undefinedinstruction() at undefinedinstruction+0x298
          pc = 0xc04a8300  lr = 0xc0496684 (exception_exit)
          sp = 0xc075ed50  fp = 0xc075eda8
          r4 = 0xc04eebec  r5 = 0xc075edfc
          r6 = 0xc04f11f2  r7 = 0xc064a100
          r8 = 0xc06625e0  r9 = 0xc06630c0
         r10 = 0xc0649f60

Maybe this problem is related to the compiler?

Thanks!

From johannes at brilliantservice.co.jp  Fri Sep 19 11:15:54 2014
From: johannes at brilliantservice.co.jp (Lundberg, Johannes)
Date: Fri, 19 Sep 2014 20:15:32 +0900
Subject: Jetson TK1 board support
Message-ID: <CAASDrVkKEPUeoQqfo0_O9XpCB7Tdqgjs_VgjM9UeqWMVKt5+TQ@mail.gmail.com>

Hi

I started working on adding the Jetson TK1 board to Crochet. Is there any
work in progress on this?
I guess there is quite a lot of work that has to been done to get full
support for it in the kernel as well..

Best regards
--
Johannes Lundberg

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
????????????????????????????????????????????????????
??????????????????????????????????????????????
???????????????????????????????????????????????
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.

From john at thehowies.com  Fri Sep 19 11:26:42 2014
From: john at thehowies.com (John Howie)
Date: Fri, 19 Sep 2014 11:25:31 +0000
Subject: Jetson TK1 board support
In-Reply-To: <CAASDrVkKEPUeoQqfo0_O9XpCB7Tdqgjs_VgjM9UeqWMVKt5+TQ@mail.gmail.com>
References: <CAASDrVkKEPUeoQqfo0_O9XpCB7Tdqgjs_VgjM9UeqWMVKt5+TQ@mail.gmail.com>
Message-ID: <D041D0CA.4C994%john@thehowies.com>

Hi all,

I am up for testing and supporting this board. I ordered and received
mine, but have not really had a chance to use it due to work to-date. The
good news is the next few months I will have bandwidth.

Regards,

John


On 9/19/14, 12:15 PM, "Lundberg, Johannes"
<johannes at brilliantservice.co.jp> wrote:

>Hi
>
>I started working on adding the Jetson TK1 board to Crochet. Is there any
>work in progress on this?
>I guess there is quite a lot of work that has to been done to get full
>support for it in the kernel as well..
>
>Best regards
>--
>Johannes Lundberg
>
>-- 
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>??????????????????????????????????????????????
??????
>??????????????????????????????????????????????
>???????????????????????????????????????????????
>---
>CONFIDENTIALITY NOTE: The information in this email is confidential
>and intended solely for the addressee.
>Disclosure, copying, distribution or any other action of use of this
>email by person other than intended recipient, is prohibited.
>If you are not the intended recipient and have received this email in
>error, please destroy the original message.
>_______________________________________________
>freebsd-arm at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"


From daniloegea at yahoo.com.br  Fri Sep 19 18:03:51 2014
From: daniloegea at yahoo.com.br (Danilo Egea Gondolfo)
Date: Fri, 19 Sep 2014 15:01:59 -0300
Subject: panic: run_interrupt_driven_config_hooks: waited to long on
 10.1-PRERELEASE + RPI-B
In-Reply-To: <541AE9A8.5030901@yahoo.com.br>
References: <1410382322.23950.YahooMailNeo@web162003.mail.bf1.yahoo.com>	
 <1410444341.1150.439.camel@revolution.hippie.lan>	
 <54131929.10208@yahoo.com.br>
 <1410557445.1150.473.camel@revolution.hippie.lan>
 <541AE9A8.5030901@yahoo.com.br>
Message-ID: <541C6F97.1070703@yahoo.com.br>


On 09/18/14 11:18, Danilo Egea Gondolfo wrote:
>
> On 09/12/14 18:30, Ian Lepore wrote:
>> On Fri, 2014-09-12 at 13:02 -0300, Danilo Egea Gondolfo wrote:
>>> On 09/11/14 11:05, Ian Lepore wrote:
>>>> On Wed, 2014-09-10 at 13:52 -0700, Danilo Egea wrote:
>>>>> Hi all,
>>>>>
>>>>> I updated my system on raspberry to 10.0-PRERELEASE (r271400) and 
>>>>> now the system is stopping at this point [1].
>>>>> This is a known problem?
>>>>>
>>>>> Sorry the bad quality picture...
>>>>>
>>>>> [1] - 
>>>>> https://www.dropbox.com/sc/r89hs2wal7dpn44/AABCKqJzAB7FzlHugfUvQrUva
>>>> I sync'd to the same stable-10 revision and built a fresh world and
>>>> kernel and it boots fine.  The big difference is that I don't use a
>>>> video console, just serial.  I don't know if that's a factor in why 
>>>> you
>>>> see a hang or not.
>>>>
>>>> -- Ian
>>>>
>>>>
>>>>
>>> Ok, now I have a serial cable.
>>>
>>> Now it's freezing and I can't run a "bt".
>>>
>>> I noticed these lines:
>>> "VT: initialize with new VT driver "fb".
>>> device_attach: fbd0 attach returned 6
>>> fb0: Failed to attach fbd device"
>>>
>>> With other kernel config I got this bt: http://pastebin.com/FUVCwt7B
>>>
>>> Hit [Enter] to boot immediately, or any other key for command prompt.
>>> Booting [/boot/kernel/kernel]...
>>> Using DTB provided by U-Boot at address 0x0x100.
>>> Kernel entry at 0x100100...
>>> Kernel args: (null)
>>> KDB: debugger backends: ddb
>>> KDB: current backend: ddb
>>> Copyright (c) 1992-2014 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 10.1-BETA1 #0 r271466: Fri Sep 12 11:41:47 BRT 2014
>>> root at danilo:/home/danilo/Mestrado/Sources/crochet-freebsd/work/obj/arm.armv6/home/danilo/Sources/freebsd-10-stable/sys/RPI-B 
>>>
>>> arm
>>> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 
>>> 20140512
>>> VT: init without driver.
>>> CPU: ARM1176JZ-S rev 7 (ARM11J core)
>>>    Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext
>>>    WB enabled LABT branch prediction enabled
>>>     16KB/32B 4-way instruction cache
>>>     16KB/32B 4-way write-back-locking-C data cache
>>> real memory  = 536866816 (511 MB)
>>> avail memory = 482893824 (460 MB)
>>> random device not loaded; using insecure entropy
>>> random: <Software, Yarrow> initialized
>>> kbd0 at kbdmux0
>>> ofwbus0: <Open Firmware Device Tree>
>>> simplebus0: <Flattened device tree simple bus> mem 
>>> 0x20000000-0x20ffffff
>>> on ofwbus0
>>> intc0: <BCM2835 Interrupt Controller> mem 0xb200-0xb3ff on simplebus0
>>> systimer0: <BCM2835 System Timer> mem 0x3000-0x3fff irq 8,9,10,11 on
>>> simplebus0
>>> Event timer "BCM2835 Event Timer 3" frequency 1000000 Hz quality 1000
>>> Timecounter "BCM2835 Timecounter" frequency 1000000 Hz quality 1000
>>> bcmwd0: <BCM2708/2835 Watchdog> mem 0x10001c-0x100027 on simplebus0
>>> gpio0: <BCM2708/2835 GPIO controller> mem 0x200000-0x2000af irq
>>> 57,59,58,60 on simplebus0
>>> gpio0: read-only pins: 46,47,48,49,50,51,52,53.
>>> gpio0: reserved pins: 48,49,50,51,52,53.
>>> gpioc0: <GPIO controller> on gpio0
>>> gpiobus0: <OFW GPIO bus> on gpio0
>>> gpioled0: <GPIO led> at pin(s) 16 on gpiobus0
>>> iichb0: <BCM2708/2835 BSC controller> mem 0x205000-0x20501f irq 61 on
>>> simplebus0
>>> iicbus0: <OFW I2C bus> on iichb0
>>> iic0: <I2C generic I/O> on iicbus0
>>> iichb1: <BCM2708/2835 BSC controller> mem 0x804000-0x80401f irq 61 on
>>> simplebus0
>>> iicbus1: <OFW I2C bus> on iichb1
>>> iic1: <I2C generic I/O> on iicbus1
>>> spi0: <BCM2708/2835 SPI controller> mem 0x204000-0x20401f irq 62 on
>>> simplebus0
>>> spibus0: <OFW SPI bus> on spi0
>>> bcm_dma0: <BCM2835 DMA Controller> mem 0x7000-0x7fff,0xe05000-0xe05fff
>>> irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0
>>> mbox0: <BCM2835 VideoCore Mailbox> mem 0xb880-0xb8bf irq 1 on 
>>> simplebus0
>>> sdhci_bcm0: <Broadcom 2708 SDHCI controller> mem 0x300000-0x3000ff irq
>>> 70 on simplebus0
>>> mmc0: <MMC/SD bus> on sdhci_bcm0
>>> uart0: <PrimeCell UART (PL011)> mem 0x201000-0x201fff irq 65 on 
>>> simplebus0
>>> uart0: console (115200,n,8,1)
>>> dwcotg0: <DWC OTG 2.0 integrated USB controller> mem 0x980000-0x99ffff
>>> irq 17 on simplebus0
>>> usbus0 on dwcotg0
>>> fb0: <BCM2835 VT framebuffer driver> on ofwbus0
>>> simplebus1: <Flattened device tree simple bus> on ofwbus0
>>> simplebus1: could not get ranges
>>> device_attach: simplebus1 attach returned 6
>>> Timecounters tick every 10.000 msec
>>> usbus0: 480Mbps High Speed USB v2.0
>>> ugen0.1: <DWCOTG> at usbus0
>>> uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on 
>>> usbus0
>>> mmcsd0: 4GB <SDHC SA04G 1.0 SN 1A93CC12 MFG 07/2012 by 2 TM> at mmc0
>>> 50.0MHz/4bit/65535-block
>>> fb0: 656x416(0x0 at 0,0) 16bpp
>>> fb0: pitch 1312, base 0x5e006000, screen_size 545792
>>> fbd0 on fb0
>>> VT: initialize with new VT driver "fb".
>>> device_attach: fbd0 attach returned 6
>>> fb0: Failed to attach fbd device
>>> uhub0: 1 port with 1 removable, self powered
>>> ugen0.2: <vendor 0x0424> at usbus0
>>> uhub1: <vendor 0x0424 product 0x9514, class 9/0, rev 2.00/2.00, addr 2>
>>> on usbus0
>>> uhub1: MTT enabled
>>> uhub1: 5 ports with 4 removable, self powered
>>> random: unblocking device.
>>> ugen0.3: <vendor 0x0424> at usbus0
>>> smsc0: <vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3> on usbus0
>>> smsc0: chip 0xec00, rev. 0002
>>> miibus0: <MII bus> on smsc0
>>> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
>>> ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>>> ue0: <USB Ethernet> on smsc0
>>> ue0: Ethernet address: b8:27:eb:60:d9:9b
>>> run_interrupt_driven_hooks: still waiting after 60 seconds for 
>>> bcm_fb_init
>>> run_interrupt_driven_hooks: still waiting after 120 seconds for 
>>> bcm_fb_init
>>> run_interrupt_driven_hooks: still waiting after 180 seconds for 
>>> bcm_fb_init
>>> run_interrupt_driven_hooks: still waiting after 240 seconds for 
>>> bcm_fb_init
>>> run_interrupt_driven_hooks: still waiting after 300 seconds for 
>>> bcm_fb_init
>> This looks like it's somehow related to the the frame buffer driver or
>> the new vt(4) driver.  I'm cc'ing Aleksander who knows more than I do
>> about that stuff. :)
>>
>> -- Ian
>>
>>
>>
> Hello again,
>
> The last snapshot of 10.1 has the same problem. Just to make sure, 
> I'll test it with another raspberry later.
>
> Here is the complete boot log http://pastebin.com/SEX64FNv
>
> I'd like to highlight this (again):
>
> VT: initialize with new VT driver "fb".
> device_attach: fbd0 attach returned 6
> fb0: Failed to attach fbd device
>
> and this (in the backtrace):
>
> undefinedinstruction() at undefinedinstruction+0x298
>          pc = 0xc04a8300  lr = 0xc0496684 (exception_exit)
>          sp = 0xc075ed50  fp = 0xc075eda8
>          r4 = 0xc04eebec  r5 = 0xc075edfc
>          r6 = 0xc04f11f2  r7 = 0xc064a100
>          r8 = 0xc06625e0  r9 = 0xc06630c0
>         r10 = 0xc0649f60
>
> Maybe this problem is related to the compiler?
>
> Thanks!

Seems that r271769 fixed the problem.  It's booting again! :)

From gdalmas at wanadoo.fr  Sat Sep 20 13:11:17 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Sat, 20 Sep 2014 15:11:08 +0200 (CEST)
Subject: kernel debugger on cubietruck
Message-ID: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>

hi,

?

I would compile freebsd for it run on a cubietruck. For this I used the wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option confifuration "CUBIEBOARD2." everything goes well, but starting on the "truck", I get this message:

?

vm_fault(0xc08bab80, 0, 1, 0) -> 1
Fatal kernel mode data abort: 'Translation Fault (S)'
trapframe: 0xc08e5a48
FSR=00000005, FAR=00000000, spsr=a00001d3
r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008
r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000
r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0
r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604

[ thread pid 0 tid 100000 ]
Stopped at????? strcmp+0x4:???? ldrb??? r3, [r0]



where is the problem please ?


From boris.astardzhiev at gmail.com  Sat Sep 20 13:14:01 2014
From: boris.astardzhiev at gmail.com (Boris Astardzhiev)
Date: Sat, 20 Sep 2014 16:13:58 +0300
Subject: kernel debugger on cubietruck
In-Reply-To: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
Message-ID: <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>

Hi,

As far as I see strcmp() is passed a NULL pointer, try issuing a backtrace
to get the exact place of calling.

Regards
On Sep 20, 2014 4:11 PM, "Gilles DALMAS" <gdalmas at wanadoo.fr> wrote:

> hi,
>
>
>
> I would compile freebsd for it run on a cubietruck. For this I used the
> wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option
> confifuration "CUBIEBOARD2." everything goes well, but starting on the
> "truck", I get this message:
>
>
>
> vm_fault(0xc08bab80, 0, 1, 0) -> 1
> Fatal kernel mode data abort: 'Translation Fault (S)'
> trapframe: 0xc08e5a48
> FSR=00000005, FAR=00000000, spsr=a00001d3
> r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008
> r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000
> r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0
> r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604
>
> [ thread pid 0 tid 100000 ]
> Stopped at      strcmp+0x4:     ldrb    r3, [r0]
>
>
>
> where is the problem please ?
>
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

From gdalmas at wanadoo.fr  Sat Sep 20 13:14:08 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Sat, 20 Sep 2014 15:14:06 +0200 (CEST)
Subject: kernel debugger on cubietruck
In-Reply-To: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
Message-ID: <689666083.10970.1411218847015.JavaMail.www@wwinf1p20>

the complete sequence :

sun7i#fatload mmc 0 0x40200000 kernel; go 0x40200100
reading kernel
5059739 bytes read in 223 ms (21.6 MiB/s)
## Starting application at 0x40200100 ...
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2014 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 11.0-CURRENT #0 r271768: Thu Sep 18 16:06:02 CEST 2014
??? root at CTBSD:/usr/obj/arm.armv6/usr/home/gilles/FBSD/sys/CUBIEBOARD2 arm
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
WARNING: WITNESS option enabled, expect reduced performance.
CPU: Cortex A7 rev 4 (Cortex-A core)
?Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext
?WB disabled EABT branch prediction enabled
LoUU:2 LoC:2 LoUIS:2 
Cache level 1: 
?32KB/64B 4-way data cache WB Read-Alloc Write-Alloc
?32KB/32B 2-way instruction cache Read-Alloc
Cache level 2: 
?256KB/64B 8-way unified cache WB Read-Alloc Write-Alloc
real memory? = 1073741824 (1024 MB)
avail memory = 1040261120 (992 MB)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
random device not loaded; using insecure entropy
random:  initialized
ofwbus0: 
simplebus0:  on ofwbus0
gic0:  mem 0x1c81000-0x1c81fff,0x1c82000-0x1c820ff on simplebus0
gic0: pn 0x10, arch 0x2, rev 0x1, implementer 0x43b sc->nirqs 160
a10_sramc0:  mem 0x1c00000-0x1c00fff on simplebus0
a20_cpu_cfg0:  mem 0x1c25c00-0x1c25fff on simplebus0
a10_ccm0:  mem 0x1c20000-0x1c203ff on simplebus0
a10_timer0:  mem 0x1c20c00-0x1c20c8f irq 54 on simplebus0
Event timer "a10_timer Eventtimer" frequency 24000000 Hz quality 1000
Timecounter "a10_timer timer0" frequency 24000000 Hz quality 1000
a10wd0:  mem 0x1c20c90-0x1c20c9f on simplebus0
gpio0:  mem 0x1c20800-0x1c20bff irq 60 on simplebus0
gpioc0:  on gpio0
gpiobus0:  on gpio0
ehci0:  mem 0x1c14000-0x1c14fff irq 71 on simplebus0
usbus0: EHCI version 1.0
usbus0 on ehci0
ehci1:  mem 0x1c1c000-0x1c1cfff irq 72 on simplebus0
usbus1: EHCI version 1.0
usbus1 on ehci1
uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 33 on simplebus0
uart0: console (115200,n,8,1)
emac0:  mem 0x1c0b000-0x1c0bfff irq 87 on simplebus0
miibus0:  on emac0
rgephy0:  PHY 0 on miibus0

vm_fault(0xc08bab80, 0, 1, 0) -> 1
Fatal kernel mode data abort: 'Translation Fault (S)'
trapframe: 0xc08e5a48
FSR=00000005, FAR=00000000, spsr=a00001d3
r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008
r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000
r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0
r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604

[ thread pid 0 tid 100000 ]
Stopped at????? strcmp+0x4:???? ldrb??? r3, [r0]



> Message du 20/09/14 15:11
> De : "Gilles DALMAS" 
> A : freebsd-arm at freebsd.org
> Copie ? : 
> Objet : kernel debugger on cubietruck
> 
> hi, ? I would compile freebsd for it run on a cubietruck. For this I used the wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option confifuration "CUBIEBOARD2." everything goes well, but starting on the "truck", I get this message: ? vm_fault(0xc08bab80, 0, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc08e5a48 FSR=00000005, FAR=00000000, spsr=a00001d3 r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008 r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000 r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0 r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604 [ thread pid 0 tid 100000 ] Stopped at????? strcmp+0x4:???? ldrb??? r3, [r0] where is the problem please ? _______________________________________________ freebsd-arm at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

From gdalmas at wanadoo.fr  Sat Sep 20 13:32:53 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Sat, 20 Sep 2014 15:25:13 +0200 (CEST)
Subject: kernel debugger on cubietruck
In-Reply-To: <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
Message-ID: <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>

I did not know much about debug kernel, but when I pass the trace command, I get:

db> trace
Tracing pid 0 tid 100000 td 0xc08ba870
db_trace_self() at db_trace_self
???????? pc = 0xc04eba6c? lr = 0xc0232780 (db_hex2dec+0x4d8)
???????? sp = 0xc08e5750? fp = 0xc08e5768
??????? r10 = 0xc08ba1c4
db_hex2dec() at db_hex2dec+0x4d8
???????? pc = 0xc0232780? lr = 0xc02320f0 (db_command_loop+0x2fc)
???????? sp = 0xc08e5770? fp = 0xc08e5810
???????? r4 = 0x00000000? r5 = 0x00000000
???????? r6 = 0x00000063
db_command_loop() at db_command_loop+0x2fc
???????? pc = 0xc02320f0? lr = 0xc0231e54 (db_command_loop+0x60)
???????? sp = 0xc08e5818? fp = 0xc08e5828
???????? r4 = 0xc0528609? r5 = 0xc0540c1c
???????? r6 = 0xc08ba1b0? r7 = 0xc08e5a48
???????? r8 = 0x00000001? r9 = 0xc05d2918
??????? r10 = 0xc0615aa4
db_command_loop() at db_command_loop+0x60
???????? pc = 0xc0231e54? lr = 0xc023481c (X_db_symbol_values+0x250)
???????? sp = 0xc08e5830? fp = 0xc08e5950
???????? r4 = 0x00000000? r5 = 0xc08ba1bc
???????? r6 = 0xc0615ac8
X_db_symbol_values() at X_db_symbol_values+0x250
???????? pc = 0xc023481c? lr = 0xc0352c88 (kdb_trap+0x15c)
???????? sp = 0xc08e5958? fp = 0xc08e5978
???????? r4 = 0x00000000? r5 = 0x00000005
???????? r6 = 0xc0615ac8? r7 = 0xc08e5a48
kdb_trap() at kdb_trap+0x15c
???????? pc = 0xc0352c88? lr = 0xc050138c (data_abort_handler+0x680)
???????? sp = 0xc08e5980? fp = 0xc08e5998
???????? r4 = 0xc08e5a48? r5 = 0x00000005
???????? r6 = 0x600001d3? r7 = 0x00000000
???????? r8 = 0x00000013? r9 = 0xc08e5a48
??????? r10 = 0x00000001
data_abort_handler() at data_abort_handler+0x680
???????? pc = 0xc050138c? lr = 0xc0501134 (data_abort_handler+0x428)
???????? sp = 0xc08e59a0? fp = 0xc08e5a40
???????? r4 = 0xc08e5eb0? r5 = 0xc08ba870
???????? r6 = 0xc08ba548? r7 = 0x00000005
data_abort_handler() at data_abort_handler+0x428
???????? pc = 0xc0501134? lr = 0xc04ed754 (exception_exit)
???????? sp = 0xc08e5a48? fp = 0xc08e5ab0
???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080
???????? r6 = 0xc3b4a0b8? r7 = 0x00000000
???????? r8 = 0xc056b038? r9 = 0xc3ae1700
??????? r10 = 0xc05d4930
exception_exit() at exception_exit
???????? pc = 0xc04ed754? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080)
???????? sp = 0xc08e5a98? fp = 0xc08e5ab0
???????? r0 = 0x00000000? r1 = 0xc0547c85
???????? r2 = 0x00000072? r3 = 0x00000008
???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080
???????? r6 = 0xc3b4a0b8? r7 = 0x00000000
???????? r8 = 0xc056b038? r9 = 0xc3ae1700
??????? r10 = 0xc05d4930 r12 = 0x00000000
strcmp() at strcmp+0x4
???????? pc = 0xc03d7604? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080)
???????? sp = 0xc08e5a98? fp = 0xc08e5ab0
Unwind failure (no registers changed)



?

> Message du 20/09/14 15:13
> De : "Boris Astardzhiev" 
> A : "Gilles DALMAS" 
> Copie ? : freebsd-arm at freebsd.org
> Objet : Re: kernel debugger on cubietruck
> 
>
> Hi,

> As far as I see strcmp() is passed a NULL pointer, try issuing a backtrace to get the exact place of calling.

> Regards

On Sep 20, 2014 4:11 PM, "Gilles DALMAS"  wrote:

hi,
> 
> ?
> 
> I would compile freebsd for it run on a cubietruck. For this I used the wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option confifuration "CUBIEBOARD2." everything goes well, but starting on the "truck", I get this message:
> 
> ?
> 
> vm_fault(0xc08bab80, 0, 1, 0) -> 1
> Fatal kernel mode data abort: 'Translation Fault (S)'
> trapframe: 0xc08e5a48
> FSR=00000005, FAR=00000000, spsr=a00001d3
> r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008
> r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000
> r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0
> r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604
> 
> [ thread pid 0 tid 100000 ]
> Stopped at????? strcmp+0x4:???? ldrb??? r3, [r0]
> 
> 
> 
> where is the problem please ?
> 
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"


From ganbold at gmail.com  Sat Sep 20 14:09:00 2014
From: ganbold at gmail.com (Ganbold Tsagaankhuu)
Date: Sat, 20 Sep 2014 22:08:59 +0800
Subject: kernel debugger on cubietruck
In-Reply-To: <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
Message-ID: <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>

On Sat, Sep 20, 2014 at 9:25 PM, Gilles DALMAS <gdalmas at wanadoo.fr> wrote:

> I did not know much about debug kernel, but when I pass the trace command,
> I get:
>
> db> trace
> Tracing pid 0 tid 100000 td 0xc08ba870
> db_trace_self() at db_trace_self
>          pc = 0xc04eba6c  lr = 0xc0232780 (db_hex2dec+0x4d8)
>          sp = 0xc08e5750  fp = 0xc08e5768
>         r10 = 0xc08ba1c4
> db_hex2dec() at db_hex2dec+0x4d8
>          pc = 0xc0232780  lr = 0xc02320f0 (db_command_loop+0x2fc)
>          sp = 0xc08e5770  fp = 0xc08e5810
>          r4 = 0x00000000  r5 = 0x00000000
>          r6 = 0x00000063
> db_command_loop() at db_command_loop+0x2fc
>          pc = 0xc02320f0  lr = 0xc0231e54 (db_command_loop+0x60)
>          sp = 0xc08e5818  fp = 0xc08e5828
>          r4 = 0xc0528609  r5 = 0xc0540c1c
>          r6 = 0xc08ba1b0  r7 = 0xc08e5a48
>          r8 = 0x00000001  r9 = 0xc05d2918
>         r10 = 0xc0615aa4
> db_command_loop() at db_command_loop+0x60
>          pc = 0xc0231e54  lr = 0xc023481c (X_db_symbol_values+0x250)
>          sp = 0xc08e5830  fp = 0xc08e5950
>          r4 = 0x00000000  r5 = 0xc08ba1bc
>          r6 = 0xc0615ac8
> X_db_symbol_values() at X_db_symbol_values+0x250
>          pc = 0xc023481c  lr = 0xc0352c88 (kdb_trap+0x15c)
>          sp = 0xc08e5958  fp = 0xc08e5978
>          r4 = 0x00000000  r5 = 0x00000005
>          r6 = 0xc0615ac8  r7 = 0xc08e5a48
> kdb_trap() at kdb_trap+0x15c
>          pc = 0xc0352c88  lr = 0xc050138c (data_abort_handler+0x680)
>          sp = 0xc08e5980  fp = 0xc08e5998
>          r4 = 0xc08e5a48  r5 = 0x00000005
>          r6 = 0x600001d3  r7 = 0x00000000
>          r8 = 0x00000013  r9 = 0xc08e5a48
>         r10 = 0x00000001
> data_abort_handler() at data_abort_handler+0x680
>          pc = 0xc050138c  lr = 0xc0501134 (data_abort_handler+0x428)
>          sp = 0xc08e59a0  fp = 0xc08e5a40
>          r4 = 0xc08e5eb0  r5 = 0xc08ba870
>          r6 = 0xc08ba548  r7 = 0x00000005
> data_abort_handler() at data_abort_handler+0x428
>          pc = 0xc0501134  lr = 0xc04ed754 (exception_exit)
>          sp = 0xc08e5a48  fp = 0xc08e5ab0
>          r4 = 0xc3b49f00  r5 = 0xc3b4a080
>          r6 = 0xc3b4a0b8  r7 = 0x00000000
>          r8 = 0xc056b038  r9 = 0xc3ae1700
>         r10 = 0xc05d4930
> exception_exit() at exception_exit
>          pc = 0xc04ed754  lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080)
>          sp = 0xc08e5a98  fp = 0xc08e5ab0
>          r0 = 0x00000000  r1 = 0xc0547c85
>          r2 = 0x00000072  r3 = 0x00000008
>          r4 = 0xc3b49f00  r5 = 0xc3b4a080
>          r6 = 0xc3b4a0b8  r7 = 0x00000000
>          r8 = 0xc056b038  r9 = 0xc3ae1700
>         r10 = 0xc05d4930 r12 = 0x00000000
> strcmp() at strcmp+0x4
>          pc = 0xc03d7604  lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080)
>          sp = 0xc08e5a98  fp = 0xc08e5ab0
> Unwind failure (no registers changed)
>

Please try without emac driver. MII in Cubietruck could be different.

Ganbold




>
>
>
>
>
> > Message du 20/09/14 15:13
> > De : "Boris Astardzhiev"
> > A : "Gilles DALMAS"
> > Copie ? : freebsd-arm at freebsd.org
> > Objet : Re: kernel debugger on cubietruck
> >
> >
> > Hi,
>
> > As far as I see strcmp() is passed a NULL pointer, try issuing a
> backtrace to get the exact place of calling.
>
> > Regards
>
> On Sep 20, 2014 4:11 PM, "Gilles DALMAS"  wrote:
>
> hi,
> >
> >
> >
> > I would compile freebsd for it run on a cubietruck. For this I used the
> wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option
> confifuration "CUBIEBOARD2." everything goes well, but starting on the
> "truck", I get this message:
> >
> >
> >
> > vm_fault(0xc08bab80, 0, 1, 0) -> 1
> > Fatal kernel mode data abort: 'Translation Fault (S)'
> > trapframe: 0xc08e5a48
> > FSR=00000005, FAR=00000000, spsr=a00001d3
> > r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008
> > r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000
> > r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0
> > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604
> >
> > [ thread pid 0 tid 100000 ]
> > Stopped at      strcmp+0x4:     ldrb    r3, [r0]
> >
> >
> >
> > where is the problem please ?
> >
> > _______________________________________________
> > freebsd-arm at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>

From gdalmas at wanadoo.fr  Sat Sep 20 14:26:45 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Sat, 20 Sep 2014 16:26:37 +0200 (CEST)
Subject: kernel debugger on cubietruck
In-Reply-To: <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
Message-ID: <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>

i comment emac line from :

# Ethernet
device??? ??? loop
device??? ??? ether
device??? ??? mii
device??? ??? smscphy
#device ??? cpsw
device??? ??? bpf

device??? ??? emac

# USB ethernet support, requires miibus
device??? ??? miibus

?

and re run the compilation ?

?

?

no need to re created the sd card ? just the USB flash ?

?

> Message du 20/09/14 16:09
> De : "Ganbold Tsagaankhuu" 
> A : "Gilles DALMAS" 
> Copie ? : "freebsd-arm at freebsd.org" 
> Objet : Re: kernel debugger on cubietruck
> 
>

>

>
On Sat, Sep 20, 2014 at 9:25 PM, Gilles DALMAS  wrote:
>
I did not know much about debug kernel, but when I pass the trace command, I get:
> 
> db> trace
> Tracing pid 0 tid 100000 td 0xc08ba870
> db_trace_self() at db_trace_self
> ???????? pc = 0xc04eba6c? lr = 0xc0232780 (db_hex2dec+0x4d8)
> ???????? sp = 0xc08e5750? fp = 0xc08e5768
> ??????? r10 = 0xc08ba1c4
> db_hex2dec() at db_hex2dec+0x4d8
> ???????? pc = 0xc0232780? lr = 0xc02320f0 (db_command_loop+0x2fc)
> ???????? sp = 0xc08e5770? fp = 0xc08e5810
> ???????? r4 = 0x00000000? r5 = 0x00000000
> ???????? r6 = 0x00000063
> db_command_loop() at db_command_loop+0x2fc
> ???????? pc = 0xc02320f0? lr = 0xc0231e54 (db_command_loop+0x60)
> ???????? sp = 0xc08e5818? fp = 0xc08e5828
> ???????? r4 = 0xc0528609? r5 = 0xc0540c1c
> ???????? r6 = 0xc08ba1b0? r7 = 0xc08e5a48
> ???????? r8 = 0x00000001? r9 = 0xc05d2918
> ??????? r10 = 0xc0615aa4
> db_command_loop() at db_command_loop+0x60
> ???????? pc = 0xc0231e54? lr = 0xc023481c (X_db_symbol_values+0x250)
> ???????? sp = 0xc08e5830? fp = 0xc08e5950
> ???????? r4 = 0x00000000? r5 = 0xc08ba1bc
> ???????? r6 = 0xc0615ac8
> X_db_symbol_values() at X_db_symbol_values+0x250
> ???????? pc = 0xc023481c? lr = 0xc0352c88 (kdb_trap+0x15c)
> ???????? sp = 0xc08e5958? fp = 0xc08e5978
> ???????? r4 = 0x00000000? r5 = 0x00000005
> ???????? r6 = 0xc0615ac8? r7 = 0xc08e5a48
> kdb_trap() at kdb_trap+0x15c
> ???????? pc = 0xc0352c88? lr = 0xc050138c (data_abort_handler+0x680)
> ???????? sp = 0xc08e5980? fp = 0xc08e5998
> ???????? r4 = 0xc08e5a48? r5 = 0x00000005
> ???????? r6 = 0x600001d3? r7 = 0x00000000
> ???????? r8 = 0x00000013? r9 = 0xc08e5a48
> ??????? r10 = 0x00000001
> data_abort_handler() at data_abort_handler+0x680
> ???????? pc = 0xc050138c? lr = 0xc0501134 (data_abort_handler+0x428)
> ???????? sp = 0xc08e59a0? fp = 0xc08e5a40
> ???????? r4 = 0xc08e5eb0? r5 = 0xc08ba870
> ???????? r6 = 0xc08ba548? r7 = 0x00000005
> data_abort_handler() at data_abort_handler+0x428
> ???????? pc = 0xc0501134? lr = 0xc04ed754 (exception_exit)
> ???????? sp = 0xc08e5a48? fp = 0xc08e5ab0
> ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080
> ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000
> ???????? r8 = 0xc056b038? r9 = 0xc3ae1700
> ??????? r10 = 0xc05d4930
> exception_exit() at exception_exit
> ???????? pc = 0xc04ed754? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080)
> ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0
> ???????? r0 = 0x00000000? r1 = 0xc0547c85
> ???????? r2 = 0x00000072? r3 = 0x00000008
> ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080
> ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000
> ???????? r8 = 0xc056b038? r9 = 0xc3ae1700
> ??????? r10 = 0xc05d4930 r12 = 0x00000000
> strcmp() at strcmp+0x4
> ???????? pc = 0xc03d7604? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080)
> ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0
> Unwind failure (no registers changed)
>

>
Please try without?emac?driver. MII in Cubietruck?could be different.
>

> 
Ganbold

> 

> 
?

> 
> 
> ?
> 
> > Message du 20/09/14 15:13
> > De : "Boris Astardzhiev"
> > A : "Gilles DALMAS"
> > Copie ? : freebsd-arm at freebsd.org
> > Objet : Re: kernel debugger on cubietruck
> >
> >
> > Hi,
> 
> > As far as I see strcmp() is passed a NULL pointer, try issuing a backtrace to get the exact place of calling.
> 
> > Regards
> 
> 

On Sep 20, 2014 4:11 PM, "Gilles DALMAS"? wrote:
> 
> hi,
> >
> > ?
> >
> > I would compile freebsd for it run on a cubietruck. For this I used the wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option confifuration "CUBIEBOARD2." everything goes well, but starting on the "truck", I get this message:
> >
> > ?
> >
> > vm_fault(0xc08bab80, 0, 1, 0) -> 1
> > Fatal kernel mode data abort: 'Translation Fault (S)'
> > trapframe: 0xc08e5a48
> > FSR=00000005, FAR=00000000, spsr=a00001d3
> > r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008
> > r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000
> > r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0
> > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604
> >
> > [ thread pid 0 tid 100000 ]
> > Stopped at????? strcmp+0x4:???? ldrb??? r3, [r0]
> >
> >
> >
> > where is the problem please ?
> >
> > _______________________________________________
> > freebsd-arm at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
> 
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"




>


From ganbold at gmail.com  Sat Sep 20 14:30:21 2014
From: ganbold at gmail.com (Ganbold Tsagaankhuu)
Date: Sat, 20 Sep 2014 22:30:20 +0800
Subject: kernel debugger on cubietruck
In-Reply-To: <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
Message-ID: <CAGtf9xO4x4+HaHn1DTJEoeM5LULMshnktWTQiO-pw_bMcxujig@mail.gmail.com>

On Sat, Sep 20, 2014 at 10:26 PM, Gilles DALMAS <gdalmas at wanadoo.fr> wrote:

> i comment emac line from :
>
> # Ethernet
> device        loop
> device        ether
> device        mii
> device        smscphy
> #device     cpsw
> device        bpf
>
> device        emac
>
> # USB ethernet support, requires miibus
> device        miibus
>
>
>
> and re run the compilation ?
>

Just build kernel only and try.

Ganbold

>
>
>
>
> no need to re created the sd card ? just the USB flash ?
>
>
>
> > Message du 20/09/14 16:09
> > De : "Ganbold Tsagaankhuu" <ganbold at gmail.com>
> > A : "Gilles DALMAS" <gdalmas at wanadoo.fr>
> > Copie ? : "freebsd-arm at freebsd.org" <freebsd-arm at freebsd.org>
>
> > Objet : Re: kernel debugger on cubietruck
> >
> >
>
> >
>
> >
> On Sat, Sep 20, 2014 at 9:25 PM, Gilles DALMAS <gdalmas at wanadoo.fr> wrote:
> >
>>
>> I did not know much about debug kernel, but when I pass the trace
>> command, I get:
>> >
>> > db> trace
>> > Tracing pid 0 tid 100000 td 0xc08ba870
>> > db_trace_self() at db_trace_self
>> >          pc = 0xc04eba6c  lr = 0xc0232780 (db_hex2dec+0x4d8)
>> >          sp = 0xc08e5750  fp = 0xc08e5768
>> >         r10 = 0xc08ba1c4
>> > db_hex2dec() at db_hex2dec+0x4d8
>> >          pc = 0xc0232780  lr = 0xc02320f0 (db_command_loop+0x2fc)
>> >          sp = 0xc08e5770  fp = 0xc08e5810
>> >          r4 = 0x00000000  r5 = 0x00000000
>> >          r6 = 0x00000063
>> > db_command_loop() at db_command_loop+0x2fc
>> >          pc = 0xc02320f0  lr = 0xc0231e54 (db_command_loop+0x60)
>> >          sp = 0xc08e5818  fp = 0xc08e5828
>> >          r4 = 0xc0528609  r5 = 0xc0540c1c
>> >          r6 = 0xc08ba1b0  r7 = 0xc08e5a48
>> >          r8 = 0x00000001  r9 = 0xc05d2918
>> >         r10 = 0xc0615aa4
>> > db_command_loop() at db_command_loop+0x60
>> >          pc = 0xc0231e54  lr = 0xc023481c (X_db_symbol_values+0x250)
>> >          sp = 0xc08e5830  fp = 0xc08e5950
>> >          r4 = 0x00000000  r5 = 0xc08ba1bc
>> >          r6 = 0xc0615ac8
>> > X_db_symbol_values() at X_db_symbol_values+0x250
>> >          pc = 0xc023481c  lr = 0xc0352c88 (kdb_trap+0x15c)
>> >          sp = 0xc08e5958  fp = 0xc08e5978
>> >          r4 = 0x00000000  r5 = 0x00000005
>> >          r6 = 0xc0615ac8  r7 = 0xc08e5a48
>> > kdb_trap() at kdb_trap+0x15c
>> >          pc = 0xc0352c88  lr = 0xc050138c (data_abort_handler+0x680)
>> >          sp = 0xc08e5980  fp = 0xc08e5998
>> >          r4 = 0xc08e5a48  r5 = 0x00000005
>> >          r6 = 0x600001d3  r7 = 0x00000000
>> >          r8 = 0x00000013  r9 = 0xc08e5a48
>> >         r10 = 0x00000001
>> > data_abort_handler() at data_abort_handler+0x680
>> >          pc = 0xc050138c  lr = 0xc0501134 (data_abort_handler+0x428)
>> >          sp = 0xc08e59a0  fp = 0xc08e5a40
>> >          r4 = 0xc08e5eb0  r5 = 0xc08ba870
>> >          r6 = 0xc08ba548  r7 = 0x00000005
>> > data_abort_handler() at data_abort_handler+0x428
>> >          pc = 0xc0501134  lr = 0xc04ed754 (exception_exit)
>> >          sp = 0xc08e5a48  fp = 0xc08e5ab0
>> >          r4 = 0xc3b49f00  r5 = 0xc3b4a080
>> >          r6 = 0xc3b4a0b8  r7 = 0x00000000
>> >          r8 = 0xc056b038  r9 = 0xc3ae1700
>> >         r10 = 0xc05d4930
>> > exception_exit() at exception_exit
>> >          pc = 0xc04ed754  lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080)
>> >          sp = 0xc08e5a98  fp = 0xc08e5ab0
>> >          r0 = 0x00000000  r1 = 0xc0547c85
>> >          r2 = 0x00000072  r3 = 0x00000008
>> >          r4 = 0xc3b49f00  r5 = 0xc3b4a080
>> >          r6 = 0xc3b4a0b8  r7 = 0x00000000
>> >          r8 = 0xc056b038  r9 = 0xc3ae1700
>> >         r10 = 0xc05d4930 r12 = 0x00000000
>> > strcmp() at strcmp+0x4
>> >          pc = 0xc03d7604  lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080)
>> >          sp = 0xc08e5a98  fp = 0xc08e5ab0
>> > Unwind failure (no registers changed)
>> >
>
>
> >
> Please try without emac driver. MII in Cubietruck could be different.
> >
>
> >
> Ganbold
>
> >
>
> >
>
>
>>
>> >
>> >
>> >
>> >
>> > > Message du 20/09/14 15:13
>> > > De : "Boris Astardzhiev"
>> > > A : "Gilles DALMAS"
>> > > Copie ? : freebsd-arm at freebsd.org
>> > > Objet : Re: kernel debugger on cubietruck
>> > >
>> > >
>> > > Hi,
>> >
>> > > As far as I see strcmp() is passed a NULL pointer, try issuing a
>> backtrace to get the exact place of calling.
>> >
>> > > Regards
>> >
>> >
>> On Sep 20, 2014 4:11 PM, "Gilles DALMAS"  wrote:
>> >
>> > hi,
>> > >
>> > >
>> > >
>> > > I would compile freebsd for it run on a cubietruck. For this I used
>> the wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using
>> option confifuration "CUBIEBOARD2." everything goes well, but starting on
>> the "truck", I get this message:
>> > >
>> > >
>> > >
>> > > vm_fault(0xc08bab80, 0, 1, 0) -> 1
>> > > Fatal kernel mode data abort: 'Translation Fault (S)'
>> > > trapframe: 0xc08e5a48
>> > > FSR=00000005, FAR=00000000, spsr=a00001d3
>> > > r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008
>> > > r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000
>> > > r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0
>> > > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604
>> > >
>> > > [ thread pid 0 tid 100000 ]
>> > > Stopped at      strcmp+0x4:     ldrb    r3, [r0]
>> > >
>> > >
>> > >
>> > > where is the problem please ?
>> > >
>> > > _______________________________________________
>> > > freebsd-arm at freebsd.org mailing list
>> > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org
>> "
>> >
>> > _______________________________________________
>> > freebsd-arm at freebsd.org mailing list
>> > http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>>
>
> >
>
>

From gdalmas at wanadoo.fr  Sat Sep 20 14:31:24 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Sat, 20 Sep 2014 16:31:14 +0200 (CEST)
Subject: kernel debugger on cubietruck
In-Reply-To: <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
Message-ID: <584735728.12399.1411223474805.JavaMail.www@wwinf1p20>

no need to re make the kernel-toolchain ?






> Message du 20/09/14 16:26
> De : "Gilles DALMAS" 
> A : "Ganbold Tsagaankhuu" 
> Copie ? : "freebsd-arm at freebsd.org" 
> Objet : Re: kernel debugger on cubietruck
> 
> i comment emac line from : # Ethernet device??? ??? loop device??? ??? ether device??? ??? mii device??? ??? smscphy #device ??? cpsw device??? ??? bpf device??? ??? emac # USB ethernet support, requires miibus device??? ??? miibus ? and re run the compilation ? ? ? no need to re created the sd card ? just the USB flash ? ? > Message du 20/09/14 16:09 > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : "freebsd-arm at freebsd.org" > Objet : Re: kernel debugger on cubietruck > > > > On Sat, Sep 20, 2014 at 9:25 PM, Gilles DALMAS wrote: > I did not know much about debug kernel, but when I pass the trace command, I get: > > db> trace > Tracing pid 0 tid 100000 td 0xc08ba870 > db_trace_self() at db_trace_self > ???????? pc = 0xc04eba6c? lr = 0xc0232780 (db_hex2dec+0x4d8) > ???????? sp = 0xc08e5750? fp = 0xc08e5768 > ??????? r10 = 0xc08ba1c4 > db_hex2dec() at db_hex2dec+0x4d8 > ???????? pc = 0xc0232780? lr = 0xc02320f0 (db_command_loop+0x2fc) > ???????? sp = 0xc08e5770? fp = 0xc08e5810 > ???????? r4 = 0x00000000? r5 = 0x00000000 > ???????? r6 = 0x00000063 > db_command_loop() at db_command_loop+0x2fc > ???????? pc = 0xc02320f0? lr = 0xc0231e54 (db_command_loop+0x60) > ???????? sp = 0xc08e5818? fp = 0xc08e5828 > ???????? r4 = 0xc0528609? r5 = 0xc0540c1c > ???????? r6 = 0xc08ba1b0? r7 = 0xc08e5a48 > ???????? r8 = 0x00000001? r9 = 0xc05d2918 > ??????? r10 = 0xc0615aa4 > db_command_loop() at db_command_loop+0x60 > ???????? pc = 0xc0231e54? lr = 0xc023481c (X_db_symbol_values+0x250) > ???????? sp = 0xc08e5830? fp = 0xc08e5950 > ???????? r4 = 0x00000000? r5 = 0xc08ba1bc > ???????? r6 = 0xc0615ac8 > X_db_symbol_values() at X_db_symbol_values+0x250 > ???????? pc = 0xc023481c? lr = 0xc0352c88 (kdb_trap+0x15c) > ???????? sp = 0xc08e5958? fp = 0xc08e5978 > ???????? r4 = 0x00000000? r5 = 0x00000005 > ???????? r6 = 0xc0615ac8? r7 = 0xc08e5a48 > kdb_trap() at kdb_trap+0x15c > ???????? pc = 0xc0352c88? lr = 0xc050138c (data_abort_handler+0x680) > ???????? sp = 0xc08e5980? fp = 0xc08e5998 > ???????? r4 = 0xc08e5a48? r5 = 0x00000005 > ???????? r6 = 0x600001d3? r7 = 0x00000000 > ???????? r8 = 0x00000013? r9 = 0xc08e5a48 > ??????? r10 = 0x00000001 > data_abort_handler() at data_abort_handler+0x680 > ???????? pc = 0xc050138c? lr = 0xc0501134 (data_abort_handler+0x428) > ???????? sp = 0xc08e59a0? fp = 0xc08e5a40 > ???????? r4 = 0xc08e5eb0? r5 = 0xc08ba870 > ???????? r6 = 0xc08ba548? r7 = 0x00000005 > data_abort_handler() at data_abort_handler+0x428 > ???????? pc = 0xc0501134? lr = 0xc04ed754 (exception_exit) > ???????? sp = 0xc08e5a48? fp = 0xc08e5ab0 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 > exception_exit() at exception_exit > ???????? pc = 0xc04ed754? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > ???????? r0 = 0x00000000? r1 = 0xc0547c85 > ???????? r2 = 0x00000072? r3 = 0x00000008 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 r12 = 0x00000000 > strcmp() at strcmp+0x4 > ???????? pc = 0xc03d7604? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > Unwind failure (no registers changed) > > Please try without?emac?driver. MII in Cubietruck?could be different. > > Ganbold > > ? > > > ? > > > Message du 20/09/14 15:13 > > De : "Boris Astardzhiev" > > A : "Gilles DALMAS" > > Copie ? : freebsd-arm at freebsd.org > > Objet : Re: kernel debugger on cubietruck > > > > > > Hi, > > > As far as I see strcmp() is passed a NULL pointer, try issuing a backtrace to get the exact place of calling. > > > Regards > > On Sep 20, 2014 4:11 PM, "Gilles DALMAS"? wrote: > > hi, > > > > ? > > > > I would compile freebsd for it run on a cubietruck. For this I used the wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option confifuration "CUBIEBOARD2." everything goes well, but starting on the "truck", I get this message: > > > > ? > > > > vm_fault(0xc08bab80, 0, 1, 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (S)' > > trapframe: 0xc08e5a48 > > FSR=00000005, FAR=00000000, spsr=a00001d3 > > r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008 > > r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000 > > r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0 > > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604 > > > > [ thread pid 0 tid 100000 ] > > Stopped at????? strcmp+0x4:???? ldrb??? r3, [r0] > > > > > > > > where is the problem please ? > > > > _______________________________________________ > > freebsd-arm at freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > > _______________________________________________ > freebsd-arm at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > _______________________________________________ freebsd-arm at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

From che at bein.link  Sat Sep 20 18:44:28 2014
From: che at bein.link (Maxim V FIlimonov)
Date: Sat, 20 Sep 2014 22:44:23 +0400
Subject: FreeBSD-11.0-CURRENT on ARM: performance and load average
Message-ID: <7351653.A2UeEk9AA3@quad>

Hello everyone,

Recently, I encountered a problem with -CURRENT on an ARM board (cubieboard2 
to be precise). The problem was that the load average was above 2. Including 
the fact that the board has 2 CPU cores, that's strange. Also, the network 
throughput was way too slow: from 3 kilobytes per second earlier to 20..50 
about now. 

Here's a workaround for that:
> sysctl kern.eventtimer.periodic=1
With that, the network performance increased while LA decreased to a decent 
0.3..0.5.
-- 
wbr, Maxim Filimonov
che at bein.link

From gdalmas at wanadoo.fr  Sat Sep 20 18:45:45 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Sat, 20 Sep 2014 20:45:41 +0200 (CEST)
Subject: kernel debugger on cubietruck
In-Reply-To: <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
 <584735728.12399.1411223474805.JavaMail.www@wwinf1p20>
 <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
Message-ID: <139071258.18161.1411238741408.JavaMail.www@wwinf1p20>

when I try to put "ufs: / dev / da0", the system starts but I have a lot of "no such device" and "spurious interrupt detected"






> Message du 20/09/14 16:35
> De : "Ganbold Tsagaankhuu" 
> A : "Gilles DALMAS" 
> Copie ? : 
> Objet : Re: kernel debugger on cubietruck
> 
>

>

>
On Sat, Sep 20, 2014 at 10:31 PM, Gilles DALMAS  wrote:
>

> no need to re make the kernel-toolchain ?
>



>
No just build kernel only.

>
Ganbold
?

> 
> 
> 
> 
>

> Message du 20/09/14 16:26
> > De : "Gilles DALMAS" 
> > A : "Ganbold Tsagaankhuu" 
> > Copie ? : "freebsd-arm at freebsd.org" 
> > Objet : Re: kernel debugger on cubietruck
> > 
> > i comment emac line from : # Ethernet device??? ??? loop device??? ??? ether device??? ??? mii device??? ??? smscphy #device ??? cpsw device??? ??? bpf device??? ??? emac # USB ethernet support, requires miibus device??? ??? miibus ? and re run the compilation ? ? ? no need to re created the sd card ? just the USB flash ? ? > Message du 20/09/14 16:09 > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : "freebsd-arm at freebsd.org" > Objet : Re: kernel debugger on cubietruck > > > > On Sat, Sep 20, 2014 at 9:25 PM, Gilles DALMAS wrote: > I did not know much about debug kernel, but when I pass the trace command, I get: > > db> trace > Tracing pid 0 tid 100000 td 0xc08ba870 > db_trace_self() at db_trace_self > ???????? pc = 0xc04eba6c? lr = 0xc0232780 (db_hex2dec+0x4d8) > ???????? sp = 0xc08e5750? fp = 0xc08e5768 > ??????? r10 = 0xc08ba1c4 > db_hex2dec() at db_hex2dec+0x4d8 > ???????? pc = 0xc0232780? lr = 0xc02320f0 (db_command_loop+0x2fc) > ???????? sp = 0xc08e5770? fp = 0xc08e5810 > ???????? r4 = 0x00000000? r5 = 0x00000000 > ???????? r6 = 0x00000063 > db_command_loop() at db_command_loop+0x2fc > ???????? pc = 0xc02320f0? lr = 0xc0231e54 (db_command_loop+0x60) > ???????? sp = 0xc08e5818? fp = 0xc08e5828 > ???????? r4 = 0xc0528609? r5 = 0xc0540c1c > ???????? r6 = 0xc08ba1b0? r7 = 0xc08e5a48 > ???????? r8 = 0x00000001? r9 = 0xc05d2918 > ??????? r10 = 0xc0615aa4 > db_command_loop() at db_command_loop+0x60 > ???????? pc = 0xc0231e54? lr = 0xc023481c (X_db_symbol_values+0x250) > ???????? sp = 0xc08e5830? fp = 0xc08e5950 > ???????? r4 = 0x00000000? r5 = 0xc08ba1bc > ???????? r6 = 0xc0615ac8 > X_db_symbol_values() at X_db_symbol_values+0x250 > ???????? pc = 0xc023481c? lr = 0xc0352c88 (kdb_trap+0x15c) > ???????? sp = 0xc08e5958? fp = 0xc08e5978 > ???????? r4 = 0x00000000? r5 = 0x00000005 > ???????? r6 = 0xc0615ac8? r7 = 0xc08e5a48 > kdb_trap() at kdb_trap+0x15c > ???????? pc = 0xc0352c88? lr = 0xc050138c (data_abort_handler+0x680) > ???????? sp = 0xc08e5980? fp = 0xc08e5998 > ???????? r4 = 0xc08e5a48? r5 = 0x00000005 > ???????? r6 = 0x600001d3? r7 = 0x00000000 > ???????? r8 = 0x00000013? r9 = 0xc08e5a48 > ??????? r10 = 0x00000001 > data_abort_handler() at data_abort_handler+0x680 > ???????? pc = 0xc050138c? lr = 0xc0501134 (data_abort_handler+0x428) > ???????? sp = 0xc08e59a0? fp = 0xc08e5a40 > ???????? r4 = 0xc08e5eb0? r5 = 0xc08ba870 > ???????? r6 = 0xc08ba548? r7 = 0x00000005 > data_abort_handler() at data_abort_handler+0x428 > ???????? pc = 0xc0501134? lr = 0xc04ed754 (exception_exit) > ???????? sp = 0xc08e5a48? fp = 0xc08e5ab0 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 > exception_exit() at exception_exit > ???????? pc = 0xc04ed754? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > ???????? r0 = 0x00000000? r1 = 0xc0547c85 > ???????? r2 = 0x00000072? r3 = 0x00000008 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 r12 = 0x00000000 > strcmp() at strcmp+0x4 > ???????? pc = 0xc03d7604? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > Unwind failure (no registers changed) > > Please try without?emac?driver. MII in Cubietruck?could be different. > > Ganbold > > ? > > > ? > > > Message du 20/09/14 15:13 > > De : "Boris Astardzhiev" > > A : "Gilles DALMAS" > > Copie ? : freebsd-arm at freebsd.org > > Objet : Re: kernel debugger on cubietruck > > > > > > Hi, > > > As far as I see strcmp() is passed a NULL pointer, try issuing a backtrace to get the exact place of calling. > > > Regards > > On Sep 20, 2014 4:11 PM, "Gilles DALMAS"? wrote: > > hi, > > > > ? > > > > I would compile freebsd for it run on a cubietruck. For this I used the wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option confifuration "CUBIEBOARD2." everything goes well, but starting on the "truck", I get this message: > > > > ? > > > > vm_fault(0xc08bab80, 0, 1, 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (S)' > > trapframe: 0xc08e5a48 > > FSR=00000005, FAR=00000000, spsr=a00001d3 > > r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008 > > r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000 > > r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0 > > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604 > > > > [ thread pid 0 tid 100000 ] > > Stopped at????? strcmp+0x4:???? ldrb??? r3, [r0] > > > > > > > > where is the problem please ? > > > > _______________________________________________ > > freebsd-arm at freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > > _______________________________________________ > freebsd-arm at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > _______________________________________________ freebsd-arm at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"



>


From che at bein.link  Sat Sep 20 18:46:04 2014
From: che at bein.link (Maxim V FIlimonov)
Date: Sat, 20 Sep 2014 22:36:43 +0400
Subject: FreeBSD-11.0-CURRENT on ARM: performance and load average
Message-ID: <6819027.8v2Z16lWiU@quad>

Hello everyone,

Recently, I encountered a problem with -CURRENT on an ARM board (cubieboard2 
to be precise). The problem was that the load average was above 2. Including 
the fact that the board has 2 CPU cores, that's strange. Also, the network 
throughput was way too slow: from 3 kilobytes per second earlier to 20..50 
about now. 

Here's a workaround for that:
> sysctl kern.eventtimer.periodic=1
With that, the network performance increased while LA decreased to a decent 
0.3..0.5.
-- 
wbr, Maxim Filimonov
che at bein.link

From gdalmas at wanadoo.fr  Sat Sep 20 19:14:58 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Sat, 20 Sep 2014 21:14:54 +0200 (CEST)
Subject: kernel debugger on cubietruck
In-Reply-To: <139071258.18161.1411238741408.JavaMail.www@wwinf1p20>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
 <584735728.12399.1411223474805.JavaMail.www@wwinf1p20>
 <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
 <139071258.18161.1411238741408.JavaMail.www@wwinf1p20>
Message-ID: <857916216.19088.1411240494803.JavaMail.www@wwinf1p21>

the network interface is not detected






> Message du 20/09/14 20:45
> De : "Gilles DALMAS" 
> A : "Ganbold Tsagaankhuu" 
> Copie ? : "freebsd-arm" 
> Objet : Re: kernel debugger on cubietruck
> 
> when I try to put "ufs: / dev / da0", the system starts but I have a lot of "no such device" and "spurious interrupt detected" > Message du 20/09/14 16:35 > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : > Objet : Re: kernel debugger on cubietruck > > > > On Sat, Sep 20, 2014 at 10:31 PM, Gilles DALMAS wrote: > > no need to re make the kernel-toolchain ? > > No just build kernel only. > Ganbold ? > > > > > > Message du 20/09/14 16:26 > > De : "Gilles DALMAS" > > A : "Ganbold Tsagaankhuu" > > Copie ? : "freebsd-arm at freebsd.org" > > Objet : Re: kernel debugger on cubietruck > > > > i comment emac line from : # Ethernet device??? ??? loop device??? ??? ether device??? ??? mii device??? ??? smscphy #device ??? cpsw device??? ??? bpf device??? ??? emac # USB ethernet support, requires miibus device??? ??? miibus ? and re run the compilation ? ? ? no need to re created the sd card ? just the USB flash ? ? > Message du 20/09/14 16:09 > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : "freebsd-arm at freebsd.org" > Objet : Re: kernel debugger on cubietruck > > > > On Sat, Sep 20, 2014 at 9:25 PM, Gilles DALMAS wrote: > I did not know much about debug kernel, but when I pass the trace command, I get: > > db> trace > Tracing pid 0 tid 100000 td 0xc08ba870 > db_trace_self() at db_trace_self > ???????? pc = 0xc04eba6c? lr = 0xc0232780 (db_hex2dec+0x4d8) > ???????? sp = 0xc08e5750? fp = 0xc08e5768 > ??????? r10 = 0xc08ba1c4 > db_hex2dec() at db_hex2dec+0x4d8 > ???????? pc = 0xc0232780? lr = 0xc02320f0 (db_command_loop+0x2fc) > ???????? sp = 0xc08e5770? fp = 0xc08e5810 > ???????? r4 = 0x00000000? r5 = 0x00000000 > ???????? r6 = 0x00000063 > db_command_loop() at db_command_loop+0x2fc > ???????? pc = 0xc02320f0? lr = 0xc0231e54 (db_command_loop+0x60) > ???????? sp = 0xc08e5818? fp = 0xc08e5828 > ???????? r4 = 0xc0528609? r5 = 0xc0540c1c > ???????? r6 = 0xc08ba1b0? r7 = 0xc08e5a48 > ???????? r8 = 0x00000001? r9 = 0xc05d2918 > ??????? r10 = 0xc0615aa4 > db_command_loop() at db_command_loop+0x60 > ???????? pc = 0xc0231e54? lr = 0xc023481c (X_db_symbol_values+0x250) > ???????? sp = 0xc08e5830? fp = 0xc08e5950 > ???????? r4 = 0x00000000? r5 = 0xc08ba1bc > ???????? r6 = 0xc0615ac8 > X_db_symbol_values() at X_db_symbol_values+0x250 > ???????? pc = 0xc023481c? lr = 0xc0352c88 (kdb_trap+0x15c) > ???????? sp = 0xc08e5958? fp = 0xc08e5978 > ???????? r4 = 0x00000000? r5 = 0x00000005 > ???????? r6 = 0xc0615ac8? r7 = 0xc08e5a48 > kdb_trap() at kdb_trap+0x15c > ???????? pc = 0xc0352c88? lr = 0xc050138c (data_abort_handler+0x680) > ???????? sp = 0xc08e5980? fp = 0xc08e5998 > ???????? r4 = 0xc08e5a48? r5 = 0x00000005 > ???????? r6 = 0x600001d3? r7 = 0x00000000 > ???????? r8 = 0x00000013? r9 = 0xc08e5a48 > ??????? r10 = 0x00000001 > data_abort_handler() at data_abort_handler+0x680 > ???????? pc = 0xc050138c? lr = 0xc0501134 (data_abort_handler+0x428) > ???????? sp = 0xc08e59a0? fp = 0xc08e5a40 > ???????? r4 = 0xc08e5eb0? r5 = 0xc08ba870 > ???????? r6 = 0xc08ba548? r7 = 0x00000005 > data_abort_handler() at data_abort_handler+0x428 > ???????? pc = 0xc0501134? lr = 0xc04ed754 (exception_exit) > ???????? sp = 0xc08e5a48? fp = 0xc08e5ab0 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 > exception_exit() at exception_exit > ???????? pc = 0xc04ed754? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > ???????? r0 = 0x00000000? r1 = 0xc0547c85 > ???????? r2 = 0x00000072? r3 = 0x00000008 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 r12 = 0x00000000 > strcmp() at strcmp+0x4 > ???????? pc = 0xc03d7604? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > Unwind failure (no registers changed) > > Please try without?emac?driver. MII in Cubietruck?could be different. > > Ganbold > > ? > > > ? > > > Message du 20/09/14 15:13 > > De : "Boris Astardzhiev" > > A : "Gilles DALMAS" > > Copie ? : freebsd-arm at freebsd.org > > Objet : Re: kernel debugger on cubietruck > > > > > > Hi, > > > As far as I see strcmp() is passed a NULL pointer, try issuing a backtrace to get the exact place of calling. > > > Regards > > On Sep 20, 2014 4:11 PM, "Gilles DALMAS"? wrote: > > hi, > > > > ? > > > > I would compile freebsd for it run on a cubietruck. For this I used the wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option confifuration "CUBIEBOARD2." everything goes well, but starting on the "truck", I get this message: > > > > ? > > > > vm_fault(0xc08bab80, 0, 1, 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (S)' > > trapframe: 0xc08e5a48 > > FSR=00000005, FAR=00000000, spsr=a00001d3 > > r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008 > > r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000 > > r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0 > > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604 > > > > [ thread pid 0 tid 100000 ] > > Stopped at????? strcmp+0x4:???? ldrb??? r3, [r0] > > > > > > > > where is the problem please ? > > > > _______________________________________________ > > freebsd-arm at freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > > _______________________________________________ > freebsd-arm at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > _______________________________________________ freebsd-arm at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > _______________________________________________ freebsd-arm at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

From ian at FreeBSD.org  Sat Sep 20 19:24:18 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Sat, 20 Sep 2014 13:24:08 -0600
Subject: FreeBSD-11.0-CURRENT on ARM: performance and load average
In-Reply-To: <7351653.A2UeEk9AA3@quad>
References: <7351653.A2UeEk9AA3@quad>
Message-ID: <1411241048.66615.148.camel@revolution.hippie.lan>

On Sat, 2014-09-20 at 22:44 +0400, Maxim V FIlimonov wrote:
> Hello everyone,
> 
> Recently, I encountered a problem with -CURRENT on an ARM board (cubieboard2 
> to be precise). The problem was that the load average was above 2. Including 
> the fact that the board has 2 CPU cores, that's strange. Also, the network 
> throughput was way too slow: from 3 kilobytes per second earlier to 20..50 
> about now. 
> 
> Here's a workaround for that:
> > sysctl kern.eventtimer.periodic=1
> With that, the network performance increased while LA decreased to a decent 
> 0.3..0.5.

Since it's happening only on that hardware, there's a good chance the
problem is in the allwinner a10/a20 clock driver, not in the general
eventtimer code.  In fact, looking at the code it appears that a
divide-by-16 is being set in the hardware, but not accounted for when
setting the frequency of the eventtimer.

Hmm, it should affect the timecounter too, in which case you'd see
time-of-day advancing 16x too fast.  If ntpd is running it would need to
step the clock pretty frequently, which would show up in syslog.

I don't have hardware to test on, please see if the attached patch makes
a difference.

-- Ian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: allwinner_timer.diff
Type: text/x-patch
Size: 502 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140920/6d3acdd6/attachment.bin>

From che at bein.link  Sat Sep 20 21:04:32 2014
From: che at bein.link (Maxim V FIlimonov)
Date: Sun, 21 Sep 2014 01:04:27 +0400
Subject: FreeBSD-11.0-CURRENT on ARM: performance and load average
In-Reply-To: <1411241048.66615.148.camel@revolution.hippie.lan>
References: <7351653.A2UeEk9AA3@quad>
 <1411241048.66615.148.camel@revolution.hippie.lan>
Message-ID: <1989123.lKm0QJoZES@quad>

On Saturday 20 September 2014 13:24:08 Ian Lepore wrote:
> Since it's happening only on that hardware, there's a good chance the
> problem is in the allwinner a10/a20 clock driver, not in the general
> eventtimer code.  In fact, looking at the code it appears that a
> divide-by-16 is being set in the hardware, but not accounted for when
> setting the frequency of the eventtimer.
> 
> Hmm, it should affect the timecounter too, in which case you'd see
> time-of-day advancing 16x too fast.  If ntpd is running it would need to
> step the clock pretty frequently, which would show up in syslog.
> 

I'm running FreeBSD-current on the board right now, the time is just fine.

> I don't have hardware to test on, please see if the attached patch makes
> a difference.
> 
 
Well, it did: with the patch applied, the time ran about 60 times as fast as 
it should have. I didn't notice any changes with load average, though: maybe 
it's because I forgot to turn that sysctl setting I set before back to 0.

wbr, Maxim Filimonov
che at bein.link

From ian at FreeBSD.org  Sat Sep 20 23:46:13 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Sat, 20 Sep 2014 17:46:09 -0600
Subject: FreeBSD-11.0-CURRENT on ARM: performance and load average
In-Reply-To: <1989123.lKm0QJoZES@quad>
References: <7351653.A2UeEk9AA3@quad>
 <1411241048.66615.148.camel@revolution.hippie.lan>
 <1989123.lKm0QJoZES@quad>
Message-ID: <1411256769.66615.155.camel@revolution.hippie.lan>

On Sun, 2014-09-21 at 01:04 +0400, Maxim V FIlimonov wrote:
> On Saturday 20 September 2014 13:24:08 Ian Lepore wrote:
> > Since it's happening only on that hardware, there's a good chance the
> > problem is in the allwinner a10/a20 clock driver, not in the general
> > eventtimer code.  In fact, looking at the code it appears that a
> > divide-by-16 is being set in the hardware, but not accounted for when
> > setting the frequency of the eventtimer.
> > 
> > Hmm, it should affect the timecounter too, in which case you'd see
> > time-of-day advancing 16x too fast.  If ntpd is running it would need to
> > step the clock pretty frequently, which would show up in syslog.
> > 
> 
> I'm running FreeBSD-current on the board right now, the time is just fine.
> 
> > I don't have hardware to test on, please see if the attached patch makes
> > a difference.
> > 
>  
> Well, it did: with the patch applied, the time ran about 60 times as fast as 
> it should have. I didn't notice any changes with load average, though: maybe 
> it's because I forgot to turn that sysctl setting I set before back to 0.
> 
> wbr, Maxim Filimonov
> che at bein.link

60 times as fast doesn't make much sense for changing a divisor to 16.

Without that patch, what is the output of

 sysctl kern.eventtimer
 sysctl kern.timecounter

If you repeatedly do "ntpdate -q <some server>" every 15 seconds for a
couple minutes, does the offset stay pretty much the same?  (like no big
changes in the first two decimal places)  Don't use a server like
pool.ntp.org where you might get a different server every time, instead
do "host pool.ntp.org" and pick one of the IPs and use it every time.

-- Ian



From amdmi3 at amdmi3.ru  Sun Sep 21 02:37:20 2014
From: amdmi3 at amdmi3.ru (Dmitry Marakasov)
Date: Sun, 21 Sep 2014 06:37:08 +0400
Subject: FreeBSD-11.0-CURRENT on ARM: performance and load average
In-Reply-To: <7351653.A2UeEk9AA3@quad>
References: <7351653.A2UeEk9AA3@quad>
Message-ID: <20140921023708.GA29778@hades.panopticon>

* Maxim V FIlimonov (che at bein.link) wrote:

> Recently, I encountered a problem with -CURRENT on an ARM board (cubieboard2 
> to be precise). The problem was that the load average was above 2. Including 
> the fact that the board has 2 CPU cores, that's strange. Also, the network 
> throughput was way too slow: from 3 kilobytes per second earlier to 20..50 
> about now. 
> 
> Here's a workaround for that:
> > sysctl kern.eventtimer.periodic=1
> With that, the network performance increased while LA decreased to a decent 
> 0.3..0.5.

I'm just started to experiment with cubieboard (1) as well.

I've also noticed poor network performance at first, however later
(without any tuning) it gave out 111 kBps. kern.eventtimer.periodic
doesn't seem to affect it.

I've also played with clocks a bit, and was able to increase CPU
rate 3x by configuring PLL1. I've experienced some instability later
(board doesn't always boot from USB, perl build fails), and now I'm
checking if reclocking was the cause.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3 at amdmi3.ru  ..:  jabber: amdmi3 at jabber.ru    http://www.amdmi3.ru

From ganbold at gmail.com  Sun Sep 21 04:25:43 2014
From: ganbold at gmail.com (Ganbold Tsagaankhuu)
Date: Sun, 21 Sep 2014 12:25:42 +0800
Subject: kernel debugger on cubietruck
In-Reply-To: <857916216.19088.1411240494803.JavaMail.www@wwinf1p21>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
 <584735728.12399.1411223474805.JavaMail.www@wwinf1p20>
 <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
 <139071258.18161.1411238741408.JavaMail.www@wwinf1p20>
 <857916216.19088.1411240494803.JavaMail.www@wwinf1p21>
Message-ID: <CAGtf9xNwCxsmrdn-2pQg_E8zo=Mqyi+yozLJTExrtbQxyXKSZw@mail.gmail.com>

On Sun, Sep 21, 2014 at 3:14 AM, Gilles DALMAS <gdalmas at wanadoo.fr> wrote:

> the network interface is not detected
>
>
>
Cubietruck should have GMAC ethernet, currently it is not supported in
FreeBSD.

Ganbold


>
>
> > Message du 20/09/14 20:45
> > De : "Gilles DALMAS" <gdalmas at wanadoo.fr>
> > A : "Ganbold Tsagaankhuu" <ganbold at gmail.com>
> > Copie ? : "freebsd-arm" <freebsd-arm at freebsd.org>
> > Objet : Re: kernel debugger on cubietruck
> >
> > when I try to put "ufs: / dev / da0", the system starts but I have a lot
> of "no such device" and "spurious interrupt detected" > Message du 20/09/14
> 16:35 > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : >
> Objet : Re: kernel debugger on cubietruck > > > > On Sat, Sep 20, 2014 at
> 10:31 PM, Gilles DALMAS wrote: > > no need to re make the kernel-toolchain
> ? > > No just build kernel only. > Ganbold   > > > > > > Message du
> 20/09/14 16:26 > > De : "Gilles DALMAS" > > A : "Ganbold Tsagaankhuu" > >
> Copie ? : "freebsd-arm at freebsd.org" > > Objet : Re: kernel debugger on
> cubietruck > > > > i comment emac line from : # Ethernet device        loop
> device        ether device        mii device        smscphy #device
> cpsw device        bpf device        emac # USB ethernet support, requires
> miibus device        miibus   and re run the compilation ?     no need to
> re created the sd card ? just the USB flash ?   > Message du 20/09/14 16:09
> > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : "
> freebsd-arm at freebsd.org" > Objet : Re: kernel debugger on cubietruck > >
> > > On Sat, Sep 20, 2014 at 9:25 PM, Gilles DALMAS wrote: > I did not know
> much about debug kernel, but when I pass the trace command, I get: > > db>
> trace > Tracing pid 0 tid 100000 td 0xc08ba870 > db_trace_self() at
> db_trace_self >          pc = 0xc04eba6c  lr = 0xc0232780
> (db_hex2dec+0x4d8) >          sp = 0xc08e5750  fp = 0xc08e5768 >
> r10 = 0xc08ba1c4 > db_hex2dec() at db_hex2dec+0x4d8 >          pc =
> 0xc0232780  lr = 0xc02320f0 (db_command_loop+0x2fc) >          sp =
> 0xc08e5770  fp = 0xc08e5810 >          r4 = 0x00000000  r5 = 0x00000000 >
>          r6 = 0x00000063 > db_command_loop() at db_command_loop+0x2fc >
>          pc = 0xc02320f0  lr = 0xc0231e54 (db_command_loop+0x60) >
> sp = 0xc08e5818  fp = 0xc08e5828 >          r4 = 0xc0528609  r5 =
> 0xc0540c1c >          r6 = 0xc08ba1b0  r7 = 0xc08e5a48 >          r8 =
> 0x00000001  r9 = 0xc05d2918 >         r10 = 0xc0615aa4 > db_command_loop()
> at db_command_loop+0x60 >          pc = 0xc0231e54  lr = 0xc023481c
> (X_db_symbol_values+0x250) >          sp = 0xc08e5830  fp = 0xc08e5950 >
>          r4 = 0x00000000  r5 = 0xc08ba1bc >          r6 = 0xc0615ac8 >
> X_db_symbol_values() at X_db_symbol_values+0x250 >          pc =
> 0xc023481c  lr = 0xc0352c88 (kdb_trap+0x15c) >          sp = 0xc08e5958  fp
> = 0xc08e5978 >          r4 = 0x00000000  r5 = 0x00000005 >          r6 =
> 0xc0615ac8  r7 = 0xc08e5a48 > kdb_trap() at kdb_trap+0x15c >          pc =
> 0xc0352c88  lr = 0xc050138c (data_abort_handler+0x680) >          sp =
> 0xc08e5980  fp = 0xc08e5998 >          r4 = 0xc08e5a48  r5 = 0x00000005 >
>          r6 = 0x600001d3  r7 = 0x00000000 >          r8 = 0x00000013  r9 =
> 0xc08e5a48 >         r10 = 0x00000001 > data_abort_handler() at
> data_abort_handler+0x680 >          pc = 0xc050138c  lr = 0xc0501134
> (data_abort_handler+0x428) >          sp = 0xc08e59a0  fp = 0xc08e5a40 >
>          r4 = 0xc08e5eb0  r5 = 0xc08ba870 >          r6 = 0xc08ba548  r7 =
> 0x00000005 > data_abort_handler() at data_abort_handler+0x428 >          pc
> = 0xc0501134  lr = 0xc04ed754 (exception_exit) >          sp = 0xc08e5a48
> fp = 0xc08e5ab0 >          r4 = 0xc3b49f00  r5 = 0xc3b4a080 >          r6 =
> 0xc3b4a0b8  r7 = 0x00000000 >          r8 = 0xc056b038  r9 = 0xc3ae1700 >
>         r10 = 0xc05d4930 > exception_exit() at exception_exit >          pc
> = 0xc04ed754  lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) >          sp =
> 0xc08e5a98  fp = 0xc08e5ab0 >          r0 = 0x00000000  r1 = 0xc0547c85 >
>          r2 = 0x00000072  r3 = 0x00000008 >          r4 = 0xc3b49f00  r5 =
> 0xc3b4a080 >          r6 = 0xc3b4a0b8  r7 = 0x00000000 >          r8 =
> 0xc056b038  r9 = 0xc3ae1700 >         r10 = 0xc05d4930 r12 = 0x00000000 >
> strcmp() at strcmp+0x4 >          pc = 0xc03d7604  lr = 0xc024e0f0
> (mii_phy_flowstatus+0x2080) >          sp = 0xc08e5a98  fp = 0xc08e5ab0 >
> Unwind failure (no registers changed) > > Please try without emac driver.
> MII in Cubietruck could be different. > > Ganbold > >   > > >   > > >
> Message du 20/09/14 15:13 > > De : "Boris Astardzhiev" > > A : "Gilles
> DALMAS" > > Copie ? : freebsd-arm at freebsd.org > > Objet : Re: kernel
> debugger on cubietruck > > > > > > Hi, > > > As far as I see strcmp() is
> passed a NULL pointer, try issuing a backtrace to get the exact place of
> calling. > > > Regards > > On Sep 20, 2014 4:11 PM, "Gilles DALMAS"  wrote:
> > > hi, > > > >   > > > > I would compile freebsd for it run on a
> cubietruck. For this I used the wiki page:
> https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option
> confifuration "CUBIEBOARD2." everything goes well, but starting on the
> "truck", I get this message: > > > >   > > > > vm_fault(0xc08bab80, 0, 1,
> 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (S)' > >
> trapframe: 0xc08e5a48 > > FSR=00000005, FAR=00000000, spsr=a00001d3 > > r0
> =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008 > > r4 =c3b49f00, r5
> =c3b4a080, r6 =c3b4a0b8, r7 =00000000 > > r8 =c056b038, r9 =c3ae1700,
> r10=c05d4930, r11=c08e5ab0 > > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc
> =c03d7604 > > > > [ thread pid 0 tid 100000 ] > > Stopped at
> strcmp+0x4:     ldrb    r3, [r0] > > > > > > > > where is the problem
> please ? > > > > _______________________________________________ > >
> freebsd-arm at freebsd.org mailing list > >
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe,
> send any mail to "freebsd-arm-unsubscribe at freebsd.org" > >
> _______________________________________________ > freebsd-arm at freebsd.org
> mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To
> unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" >
> _______________________________________________ freebsd-arm at freebsd.org
> mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To
> unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" >
> _______________________________________________ freebsd-arm at freebsd.org
> mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To
> unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>
>

From ganbold at gmail.com  Sun Sep 21 04:28:40 2014
From: ganbold at gmail.com (Ganbold Tsagaankhuu)
Date: Sun, 21 Sep 2014 12:28:39 +0800
Subject: kernel debugger on cubietruck
In-Reply-To: <139071258.18161.1411238741408.JavaMail.www@wwinf1p20>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
 <584735728.12399.1411223474805.JavaMail.www@wwinf1p20>
 <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
 <139071258.18161.1411238741408.JavaMail.www@wwinf1p20>
Message-ID: <CAGtf9xMzZeXSNpfes2ChLSvpaFMXHs2kgNY+ZLdjCo7fq=yekg@mail.gmail.com>

On Sun, Sep 21, 2014 at 2:45 AM, Gilles DALMAS <gdalmas at wanadoo.fr> wrote:

> when I try to put "ufs: / dev / da0", the system starts but I have a lot
> of "no such device" and "spurious interrupt detected"
>

For now, you can comment out "Spurious interrupt detected" in
http://svnweb.freebsd.org/base/head/sys/arm/arm/gic.c?revision=271630&view=markup#l364
and rebuild the kernel again and try.

I didn't find yet the solution for it.

Ganbold




>
>
>
>
>
> > Message du 20/09/14 16:35
> > De : "Ganbold Tsagaankhuu" <ganbold at gmail.com>
> > A : "Gilles DALMAS" <gdalmas at wanadoo.fr>
> > Copie ? :
> > Objet : Re: kernel debugger on cubietruck
> >
> >
>
> >
>
> >
> On Sat, Sep 20, 2014 at 10:31 PM, Gilles DALMAS <gdalmas at wanadoo.fr>
> wrote:
> >
>>
>> > no need to re make the kernel-toolchain ?
>> >
>>
>
> >
> No just build kernel only.
>
> >
> Ganbold
>
>
>> >
>> >
>> >
>> >
>> >
>>
>> > Message du 20/09/14 16:26
>> > > De : "Gilles DALMAS" <gdalmas at wanadoo.fr>
>> > > A : "Ganbold Tsagaankhuu" <ganbold at gmail.com>
>> > > Copie ? : "freebsd-arm at freebsd.org" <freebsd-arm at freebsd.org>
>> > > Objet : Re: kernel debugger on cubietruck
>> > >
>> > > i comment emac line from : # Ethernet device        loop device
>>     ether device        mii device        smscphy #device     cpsw
>> device        bpf device        emac # USB ethernet support, requires
>> miibus device        miibus   and re run the compilation ?     no need to
>> re created the sd card ? just the USB flash ?   > Message du 20/09/14 16:09
>> > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : "
>> freebsd-arm at freebsd.org" > Objet : Re: kernel debugger on cubietruck > >
>> > > On Sat, Sep 20, 2014 at 9:25 PM, Gilles DALMAS wrote: > I did not know
>> much about debug kernel, but when I pass the trace command, I get: > > db>
>> trace > Tracing pid 0 tid 100000 td 0xc08ba870 > db_trace_self() at
>> db_trace_self >          pc = 0xc04eba6c  lr = 0xc0232780
>> (db_hex2dec+0x4d8) >          sp = 0xc08e5750  fp = 0xc08e5768 >
>> r10 = 0xc08ba1c4 > db_hex2dec() at db_hex2dec+0x4d8 >          pc =
>> 0xc0232780  lr = 0xc02320f0 (db_command_loop+0x2fc) >          sp =
>> 0xc08e5770  fp = 0xc08e5810 >          r4 = 0x00000000  r5 = 0x00000000 >
>>          r6 = 0x00000063 > db_command_loop() at db_command_loop+0x2fc >
>>          pc = 0xc02320f0  lr = 0xc0231e54 (db_command_loop+0x60) >
>> sp = 0xc08e5818  fp = 0xc08e5828 >          r4 = 0xc0528609  r5 =
>> 0xc0540c1c >          r6 = 0xc08ba1b0  r7 = 0xc08e5a48 >          r8 =
>> 0x00000001  r9 = 0xc05d2918 >         r10 = 0xc0615aa4 > db_command_loop()
>> at db_command_loop+0x60 >          pc = 0xc0231e54  lr = 0xc023481c
>> (X_db_symbol_values+0x250) >          sp = 0xc08e5830  fp = 0xc08e5950 >
>>          r4 = 0x00000000  r5 = 0xc08ba1bc >          r6 = 0xc0615ac8 >
>> X_db_symbol_values() at X_db_symbol_values+0x250 >          pc =
>> 0xc023481c  lr = 0xc0352c88 (kdb_trap+0x15c) >          sp = 0xc08e5958  fp
>> = 0xc08e5978 >          r4 = 0x00000000  r5 = 0x00000005 >          r6 =
>> 0xc0615ac8  r7 = 0xc08e5a48 > kdb_trap() at kdb_trap+0x15c >          pc =
>> 0xc0352c88  lr = 0xc050138c (data_abort_handler+0x680) >          sp =
>> 0xc08e5980  fp = 0xc08e5998 >          r4 = 0xc08e5a48  r5 = 0x00000005 >
>>          r6 = 0x600001d3  r7 = 0x00000000 >          r8 = 0x00000013  r9 =
>> 0xc08e5a48 >         r10 = 0x00000001 > data_abort_handler() at
>> data_abort_handler+0x680 >          pc = 0xc050138c  lr = 0xc0501134
>> (data_abort_handler+0x428) >          sp = 0xc08e59a0  fp = 0xc08e5a40 >
>>          r4 = 0xc08e5eb0  r5 = 0xc08ba870 >          r6 = 0xc08ba548  r7 =
>> 0x00000005 > data_abort_handler() at data_abort_handler+0x428 >          pc
>> = 0xc0501134  lr = 0xc04ed754 (exception_exit) >          sp = 0xc08e5a48
>> fp = 0xc08e5ab0 >          r4 = 0xc3b49f00  r5 = 0xc3b4a080 >          r6 =
>> 0xc3b4a0b8  r7 = 0x00000000 >          r8 = 0xc056b038  r9 = 0xc3ae1700 >
>>         r10 = 0xc05d4930 > exception_exit() at exception_exit >          pc
>> = 0xc04ed754  lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) >          sp =
>> 0xc08e5a98  fp = 0xc08e5ab0 >          r0 = 0x00000000  r1 = 0xc0547c85 >
>>          r2 = 0x00000072  r3 = 0x00000008 >          r4 = 0xc3b49f00  r5 =
>> 0xc3b4a080 >          r6 = 0xc3b4a0b8  r7 = 0x00000000 >          r8 =
>> 0xc056b038  r9 = 0xc3ae1700 >         r10 = 0xc05d4930 r12 = 0x00000000 >
>> strcmp() at strcmp+0x4 >          pc = 0xc03d7604  lr = 0xc024e0f0
>> (mii_phy_flowstatus+0x2080) >          sp = 0xc08e5a98  fp = 0xc08e5ab0 >
>> Unwind failure (no registers changed) > > Please try without emac driver.
>> MII in Cubietruck could be different. > > Ganbold > >   > > >   > > >
>> Message du 20/09/14 15:13 > > De : "Boris Astardzhiev" > > A : "Gilles
>> DALMAS" > > Copie ? : freebsd-arm at freebsd.org > > Objet : Re: kernel
>> debugger on cubietruck > > > > > > Hi, > > > As far as I see strcmp() is
>> passed a NULL pointer, try issuing a backtrace to get the exact place of
>> calling. > > > Regards > > On Sep 20, 2014 4:11 PM, "Gilles DALMAS"  wrote:
>> > > hi, > > > >   > > > > I would compile freebsd for it run on a
>> cubietruck. For this I used the wiki page:
>> https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option
>> confifuration "CUBIEBOARD2." everything goes well, but starting on the
>> "truck", I get this message: > > > >   > > > > vm_fault(0xc08bab80, 0, 1,
>> 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (S)' > >
>> trapframe: 0xc08e5a48 > > FSR=00000005, FAR=00000000, spsr=a00001d3 > > r0
>> =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008 > > r4 =c3b49f00, r5
>> =c3b4a080, r6 =c3b4a0b8, r7 =00000000 > > r8 =c056b038, r9 =c3ae1700,
>> r10=c05d4930, r11=c08e5ab0 > > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc
>> =c03d7604 > > > > [ thread pid 0 tid 100000 ] > > Stopped at
>> strcmp+0x4:     ldrb    r3, [r0] > > > > > > > > where is the problem
>> please ? > > > > _______________________________________________ > >
>> freebsd-arm at freebsd.org mailing list > >
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To
>> unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > >
>> _______________________________________________ > freebsd-arm at freebsd.org
>> mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm >
>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" >
>> _______________________________________________ freebsd-arm at freebsd.org
>> mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To
>> unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>>
>>
> >
>
>

From ganbold at gmail.com  Sun Sep 21 04:39:08 2014
From: ganbold at gmail.com (Ganbold Tsagaankhuu)
Date: Sun, 21 Sep 2014 12:39:07 +0800
Subject: FreeBSD-11.0-CURRENT on ARM: performance and load average
In-Reply-To: <20140921023708.GA29778@hades.panopticon>
References: <7351653.A2UeEk9AA3@quad> <20140921023708.GA29778@hades.panopticon>
Message-ID: <CAGtf9xNh1sWw2d7Jd1hN5R+ML1WdfEpEYZZQc7eRG=2spWUC=A@mail.gmail.com>

On Sun, Sep 21, 2014 at 10:37 AM, Dmitry Marakasov <amdmi3 at amdmi3.ru> wrote:

> * Maxim V FIlimonov (che at bein.link) wrote:
>
> > Recently, I encountered a problem with -CURRENT on an ARM board
> (cubieboard2
> > to be precise). The problem was that the load average was above 2.
> Including
> > the fact that the board has 2 CPU cores, that's strange. Also, the
> network
> > throughput was way too slow: from 3 kilobytes per second earlier to
> 20..50
> > about now.
> >
> > Here's a workaround for that:
> > > sysctl kern.eventtimer.periodic=1
> > With that, the network performance increased while LA decreased to a
> decent
> > 0.3..0.5.
>
> I'm just started to experiment with cubieboard (1) as well.
>
> I've also noticed poor network performance at first, however later
> (without any tuning) it gave out 111 kBps. kern.eventtimer.periodic
> doesn't seem to affect it.
>

As for EMAC driver, RX performance is poor right now. Please see some info
at:

http://linux-sunxi.org/Ethernet#EMAC

It needs improvement with the assistance of external DMA controller (dma
driver) in case there is bulk TCP receiver.

Ganbold



>
> I've also played with clocks a bit, and was able to increase CPU
> rate 3x by configuring PLL1. I've experienced some instability later
> (board doesn't always boot from USB, perl build fails), and now I'm
> checking if reclocking was the cause.
>
> --
> Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
> amdmi3 at amdmi3.ru  ..:  jabber: amdmi3 at jabber.ru    http://www.amdmi3.ru
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>

From johannes at brilliantservice.co.jp  Sun Sep 21 07:45:31 2014
From: johannes at brilliantservice.co.jp (Lundberg, Johannes)
Date: Sun, 21 Sep 2014 16:45:08 +0900
Subject: Jetson TK1 board support
In-Reply-To: <D041D0CA.4C994%john@thehowies.com>
References: <CAASDrVkKEPUeoQqfo0_O9XpCB7Tdqgjs_VgjM9UeqWMVKt5+TQ@mail.gmail.com>
 <D041D0CA.4C994%john@thehowies.com>
Message-ID: <CAASDrVkY3uSZUPV7r0LrzfxPhLsMvvLN5=eg9zd7pgKEisVifw@mail.gmail.com>

Great!

What I've done so far is

- build and patch (enable API) u-boot-nvidia on freebsd (i think i got it
from git://nv-tegra.nvidia.com/3rdparty/u-boot.git, the normal u-boot
wouldn't work...)
- flash u-boot-dtb-tegra.img onto the board's mmc using nvidia's flash tool
on ubuntu
- build an image using crochet and dd to sd card (so far I copied the
beaglebone setup, just to get a ubldr and a kernel file)


From u-boot I can see all devices. I load ubldr with
fatload mmc 1:1 0x80200000 ubldr
bootelf 0x80200000

ubldr load fine but, from ubldr I can only see the mmc 0 and net devices.
There's no sd card (mmc 1), and no ufs partition..




--
Johannes Lundberg
BRILLIANTSERVICE CO., LTD.

On Fri, Sep 19, 2014 at 8:25 PM, John Howie <john at thehowies.com> wrote:

> Hi all,
>
> I am up for testing and supporting this board. I ordered and received
> mine, but have not really had a chance to use it due to work to-date. The
> good news is the next few months I will have bandwidth.
>
> Regards,
>
> John
>
>
> On 9/19/14, 12:15 PM, "Lundberg, Johannes"
> <johannes at brilliantservice.co.jp> wrote:
>
> >Hi
> >
> >I started working on adding the Jetson TK1 board to Crochet. Is there any
> >work in progress on this?
> >I guess there is quite a lot of work that has to been done to get full
> >support for it in the kernel as well..
> >
> >Best regards
> >--
> >Johannes Lundberg
> >
> >--
> >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >??????????????????????????????????????????????
> ??????
> >??????????????????????????????????????????????
> >???????????????????????????????????????????????
> >---
> >CONFIDENTIALITY NOTE: The information in this email is confidential
> >and intended solely for the addressee.
> >Disclosure, copying, distribution or any other action of use of this
> >email by person other than intended recipient, is prohibited.
> >If you are not the intended recipient and have received this email in
> >error, please destroy the original message.
> >_______________________________________________
> >freebsd-arm at freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> >To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>
>

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
????????????????????????????????????????????????????
??????????????????????????????????????????????
???????????????????????????????????????????????
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.

From gdalmas at wanadoo.fr  Sun Sep 21 08:58:25 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Sun, 21 Sep 2014 10:58:21 +0200 (CEST)
Subject: kernel debugger on cubietruck
In-Reply-To: <CAGtf9xMzZeXSNpfes2ChLSvpaFMXHs2kgNY+ZLdjCo7fq=yekg@mail.gmail.com>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
 <584735728.12399.1411223474805.JavaMail.www@wwinf1p20>
 <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
 <139071258.18161.1411238741408.JavaMail.www@wwinf1p20>
 <CAGtf9xMzZeXSNpfes2ChLSvpaFMXHs2kgNY+ZLdjCo7fq=yekg@mail.gmail.com>
Message-ID: <1878422084.4858.1411289901179.JavaMail.www@wwinf1p21>

by cons, for managing sata disks, I can enable the "ahci"?






> Message du 21/09/14 06:28
> De : "Ganbold Tsagaankhuu" 
> A : "Gilles DALMAS" 
> Copie ? : "freebsd-arm" 
> Objet : Re: kernel debugger on cubietruck
> 
>

>

>
On Sun, Sep 21, 2014 at 2:45 AM, Gilles DALMAS  wrote:
>

> when I try to put "ufs: / dev / da0", the system starts but I have a lot of "no such device" and "spurious interrupt detected"



>
For now, you can comment out "Spurious interrupt detected" in?http://svnweb.freebsd.org/base/head/sys/arm/arm/gic.c?revision=271630&view=markup#l364 and rebuild the kernel again and try.

>
I didn't find yet the solution for it.

>
Ganbold

>

>
?

> 
> 
> 
> 
> 
>

> Message du 20/09/14 16:35
> > De : "Ganbold Tsagaankhuu" 
> > A : "Gilles DALMAS" 
> > Copie ? : 
> > Objet : Re: kernel debugger on cubietruck
> > 
> >

> >

> >
On Sat, Sep 20, 2014 at 10:31 PM, Gilles DALMAS  wrote:
> >

> > no need to re make the kernel-toolchain ?
> >



> >
No just build kernel only.

> >
Ganbold
?

> > 
> > 
> > 
> > 
> >

> Message du 20/09/14 16:26
> > > De : "Gilles DALMAS" 
> > > A : "Ganbold Tsagaankhuu" 
> > > Copie ? : "freebsd-arm at freebsd.org" 
> > > Objet : Re: kernel debugger on cubietruck
> > > 
> > > i comment emac line from : # Ethernet device??? ??? loop device??? ??? ether device??? ??? mii device??? ??? smscphy #device ??? cpsw device??? ??? bpf device??? ??? emac # USB ethernet support, requires miibus device??? ??? miibus ? and re run the compilation ? ? ? no need to re created the sd card ? just the USB flash ? ? > Message du 20/09/14 16:09 > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : "freebsd-arm at freebsd.org" > Objet : Re: kernel debugger on cubietruck > > > > On Sat, Sep 20, 2014 at 9:25 PM, Gilles DALMAS wrote: > I did not know much about debug kernel, but when I pass the trace command, I get: > > db> trace > Tracing pid 0 tid 100000 td 0xc08ba870 > db_trace_self() at db_trace_self > ???????? pc = 0xc04eba6c? lr = 0xc0232780 (db_hex2dec+0x4d8) > ???????? sp = 0xc08e5750? fp = 0xc08e5768 > ??????? r10 = 0xc08ba1c4 > db_hex2dec() at db_hex2dec+0x4d8 > ???????? pc = 0xc0232780? lr = 0xc02320f0 (db_command_loop+0x2fc) > ???????? sp = 0xc08e5770? fp = 0xc08e5810 > ???????? r4 = 0x00000000? r5 = 0x00000000 > ???????? r6 = 0x00000063 > db_command_loop() at db_command_loop+0x2fc > ???????? pc = 0xc02320f0? lr = 0xc0231e54 (db_command_loop+0x60) > ???????? sp = 0xc08e5818? fp = 0xc08e5828 > ???????? r4 = 0xc0528609? r5 = 0xc0540c1c > ???????? r6 = 0xc08ba1b0? r7 = 0xc08e5a48 > ???????? r8 = 0x00000001? r9 = 0xc05d2918 > ??????? r10 = 0xc0615aa4 > db_command_loop() at db_command_loop+0x60 > ???????? pc = 0xc0231e54? lr = 0xc023481c (X_db_symbol_values+0x250) > ???????? sp = 0xc08e5830? fp = 0xc08e5950 > ???????? r4 = 0x00000000? r5 = 0xc08ba1bc > ???????? r6 = 0xc0615ac8 > X_db_symbol_values() at X_db_symbol_values+0x250 > ???????? pc = 0xc023481c? lr = 0xc0352c88 (kdb_trap+0x15c) > ???????? sp = 0xc08e5958? fp = 0xc08e5978 > ???????? r4 = 0x00000000? r5 = 0x00000005 > ???????? r6 = 0xc0615ac8? r7 = 0xc08e5a48 > kdb_trap() at kdb_trap+0x15c > ???????? pc = 0xc0352c88? lr = 0xc050138c (data_abort_handler+0x680) > ???????? sp = 0xc08e5980? fp = 0xc08e5998 > ???????? r4 = 0xc08e5a48? r5 = 0x00000005 > ???????? r6 = 0x600001d3? r7 = 0x00000000 > ???????? r8 = 0x00000013? r9 = 0xc08e5a48 > ??????? r10 = 0x00000001 > data_abort_handler() at data_abort_handler+0x680 > ???????? pc = 0xc050138c? lr = 0xc0501134 (data_abort_handler+0x428) > ???????? sp = 0xc08e59a0? fp = 0xc08e5a40 > ???????? r4 = 0xc08e5eb0? r5 = 0xc08ba870 > ???????? r6 = 0xc08ba548? r7 = 0x00000005 > data_abort_handler() at data_abort_handler+0x428 > ???????? pc = 0xc0501134? lr = 0xc04ed754 (exception_exit) > ???????? sp = 0xc08e5a48? fp = 0xc08e5ab0 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 > exception_exit() at exception_exit > ???????? pc = 0xc04ed754? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > ???????? r0 = 0x00000000? r1 = 0xc0547c85 > ???????? r2 = 0x00000072? r3 = 0x00000008 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 r12 = 0x00000000 > strcmp() at strcmp+0x4 > ???????? pc = 0xc03d7604? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > Unwind failure (no registers changed) > > Please try without?emac?driver. MII in Cubietruck?could be different. > > Ganbold > > ? > > > ? > > > Message du 20/09/14 15:13 > > De : "Boris Astardzhiev" > > A : "Gilles DALMAS" > > Copie ? : freebsd-arm at freebsd.org > > Objet : Re: kernel debugger on cubietruck > > > > > > Hi, > > > As far as I see strcmp() is passed a NULL pointer, try issuing a backtrace to get the exact place of calling. > > > Regards > > On Sep 20, 2014 4:11 PM, "Gilles DALMAS"? wrote: > > hi, > > > > ? > > > > I would compile freebsd for it run on a cubietruck. For this I used the wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option confifuration "CUBIEBOARD2." everything goes well, but starting on the "truck", I get this message: > > > > ? > > > > vm_fault(0xc08bab80, 0, 1, 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (S)' > > trapframe: 0xc08e5a48 > > FSR=00000005, FAR=00000000, spsr=a00001d3 > > r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008 > > r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000 > > r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0 > > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604 > > > > [ thread pid 0 tid 100000 ] > > Stopped at????? strcmp+0x4:???? ldrb??? r3, [r0] > > > > > > > > where is the problem please ? > > > > _______________________________________________ > > freebsd-arm at freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > > _______________________________________________ > freebsd-arm at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > _______________________________________________ freebsd-arm at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"



> >





>


From che at bein.link  Sun Sep 21 09:06:07 2014
From: che at bein.link (Maxim V FIlimonov)
Date: Sun, 21 Sep 2014 13:06:02 +0400
Subject: FreeBSD-11.0-CURRENT on ARM: performance and load average
In-Reply-To: <1411256769.66615.155.camel@revolution.hippie.lan>
References: <7351653.A2UeEk9AA3@quad> <1989123.lKm0QJoZES@quad>
 <1411256769.66615.155.camel@revolution.hippie.lan>
Message-ID: <16223180.9Q4Ic3raYi@quad>

On Saturday 20 September 2014 17:46:09 Ian Lepore wrote:
> 
> 60 times as fast doesn't make much sense for changing a divisor to 16.
> 
> Without that patch, what is the output of
> 
>  sysctl kern.eventtimer
>  sysctl kern.timecounter

Here it is:
root at cubie:~ # sysctl kern.eventtimer
kern.eventtimer.et.a10_timer Eventtimer.flags: 3
kern.eventtimer.et.a10_timer Eventtimer.frequency: 24000000
kern.eventtimer.et.a10_timer Eventtimer.quality: 1000
kern.eventtimer.choice: a10_timer Eventtimer(1000)
kern.eventtimer.singlemul: 4
kern.eventtimer.idletick: 0
kern.eventtimer.timer: a10_timer Eventtimer
kern.eventtimer.periodic: 1
root at cubie:~ # sysctl kern.timecounter
kern.timecounter.tc.a10_timer timer0.mask: 4294967295
kern.timecounter.tc.a10_timer timer0.counter: 4271639596
kern.timecounter.tc.a10_timer timer0.frequency: 24000000
kern.timecounter.tc.a10_timer timer0.quality: 1000
kern.timecounter.stepwarnings: 0
kern.timecounter.alloweddeviation: 5
kern.timecounter.hardware: a10_timer timer0
kern.timecounter.choice: a10_timer timer0(1000) dummy(-1000000)
kern.timecounter.tick: 1
kern.timecounter.fast_gettime: 1


> 
> If you repeatedly do "ntpdate -q <some server>" every 15 seconds for a
> couple minutes, does the offset stay pretty much the same?  (like no big
> changes in the first two decimal places)  Don't use a server like
> pool.ntp.org where you might get a different server every time, instead
> do "host pool.ntp.org" and pick one of the IPs and use it every time.
> 

root at cubie:~ # ntpdate time.nist.gov
21 Sep 13:04:55 ntpdate[2236]: adjust time server 24.56.178.140 offset 
-0.117727 sec
root at cubie:~ # ntpdate time.nist.gov
21 Sep 13:04:57 ntpdate[2237]: adjust time server 24.56.178.140 offset 
-0.117018 sec
root at cubie:~ # ntpdate time.nist.gov
21 Sep 13:05:00 ntpdate[2238]: adjust time server 24.56.178.140 offset 
-0.116026 sec
root at cubie:~ # ntpdate time.nist.gov
21 Sep 13:05:08 ntpdate[2241]: adjust time server 24.56.178.140 offset 
-0.111525 sec
root at cubie:~ # ntpdate time.nist.gov
21 Sep 13:05:26 ntpdate[2242]: adjust time server 24.56.178.140 offset 
-0.103121 sec
root at cubie:~ # ntpdate time.nist.gov
21 Sep 13:05:34 ntpdate[2243]: adjust time server 24.56.178.140 offset 
-0.099055 sec

So as you could notice, the offset doesn't change much.

> -- Ian
-- 
wbr, Maxim Filimonov
che at bein.link

From ganbold at gmail.com  Sun Sep 21 09:11:41 2014
From: ganbold at gmail.com (Ganbold Tsagaankhuu)
Date: Sun, 21 Sep 2014 17:11:40 +0800
Subject: kernel debugger on cubietruck
In-Reply-To: <1878422084.4858.1411289901179.JavaMail.www@wwinf1p21>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
 <584735728.12399.1411223474805.JavaMail.www@wwinf1p20>
 <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
 <139071258.18161.1411238741408.JavaMail.www@wwinf1p20>
 <CAGtf9xMzZeXSNpfes2ChLSvpaFMXHs2kgNY+ZLdjCo7fq=yekg@mail.gmail.com>
 <1878422084.4858.1411289901179.JavaMail.www@wwinf1p21>
Message-ID: <CAGtf9xPj+xj7m018w+iHdHtj_or7nBMGkWbFS0YY+yBiHaaH4w@mail.gmail.com>

On Sun, Sep 21, 2014 at 4:58 PM, Gilles DALMAS <gdalmas at wanadoo.fr> wrote:

> by cons, for managing sata disks, I can enable the "ahci"?
>
>
There is no SATA driver yet in src tree. imp@ hopefully will commit a10/a20
sata driver soon to current.

Ganbold



>
>
>
> > Message du 21/09/14 06:28
> > De : "Ganbold Tsagaankhuu" <ganbold at gmail.com>
> > A : "Gilles DALMAS" <gdalmas at wanadoo.fr>
> > Copie ? : "freebsd-arm" <freebsd-arm at freebsd.org>
> > Objet : Re: kernel debugger on cubietruck
> >
> >
>
> >
>
> >
> On Sun, Sep 21, 2014 at 2:45 AM, Gilles DALMAS <gdalmas at wanadoo.fr> wrote:
> >
>>
>> > when I try to put "ufs: / dev / da0", the system starts but I have a
>> lot of "no such device" and "spurious interrupt detected"
>>
>
> >
> For now, you can comment out "Spurious interrupt detected" in
> http://svnweb.freebsd.org/base/head/sys/arm/arm/gic.c?revision=271630&view=markup#l364
> and rebuild the kernel again and try.
>
> >
> I didn't find yet the solution for it.
>
> >
> Ganbold
>
> >
>
> >
>
>
>> >
>> >
>> >
>> >
>> >
>> >
>>
>> > Message du 20/09/14 16:35
>> > > De : "Ganbold Tsagaankhuu" <ganbold at gmail.com>
>> > > A : "Gilles DALMAS" <gdalmas at wanadoo.fr>
>> > > Copie ? :
>> > > Objet : Re: kernel debugger on cubietruck
>> > >
>> > >
>>
>> > >
>>
>> > >
>> On Sat, Sep 20, 2014 at 10:31 PM, Gilles DALMAS <gdalmas at wanadoo.fr>
>> wrote:
>> > >
>>>
>>> > > no need to re make the kernel-toolchain ?
>>> > >
>>>
>>
>> > >
>> No just build kernel only.
>>
>> > >
>> Ganbold
>>
>>
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>>
>>> > Message du 20/09/14 16:26
>>> > > > De : "Gilles DALMAS" <gdalmas at wanadoo.fr>
>>> > > > A : "Ganbold Tsagaankhuu" <ganbold at gmail.com>
>>> > > > Copie ? : "freebsd-arm at freebsd.org" <freebsd-arm at freebsd.org>
>>> > > > Objet : Re: kernel debugger on cubietruck
>>> > > >
>>> > > > i comment emac line from : # Ethernet device        loop
>>> device        ether device        mii device        smscphy #device
>>> cpsw device        bpf device        emac # USB ethernet support, requires
>>> miibus device        miibus   and re run the compilation ?     no need to
>>> re created the sd card ? just the USB flash ?   > Message du 20/09/14 16:09
>>> > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : "
>>> freebsd-arm at freebsd.org" > Objet : Re: kernel debugger on cubietruck >
>>> > > > On Sat, Sep 20, 2014 at 9:25 PM, Gilles DALMAS wrote: > I did not
>>> know much about debug kernel, but when I pass the trace command, I get: > >
>>> db> trace > Tracing pid 0 tid 100000 td 0xc08ba870 > db_trace_self() at
>>> db_trace_self >          pc = 0xc04eba6c  lr = 0xc0232780
>>> (db_hex2dec+0x4d8) >          sp = 0xc08e5750  fp = 0xc08e5768 >
>>> r10 = 0xc08ba1c4 > db_hex2dec() at db_hex2dec+0x4d8 >          pc =
>>> 0xc0232780  lr = 0xc02320f0 (db_command_loop+0x2fc) >          sp =
>>> 0xc08e5770  fp = 0xc08e5810 >          r4 = 0x00000000  r5 = 0x00000000 >
>>>          r6 = 0x00000063 > db_command_loop() at db_command_loop+0x2fc >
>>>          pc = 0xc02320f0  lr = 0xc0231e54 (db_command_loop+0x60) >
>>> sp = 0xc08e5818  fp = 0xc08e5828 >          r4 = 0xc0528609  r5 =
>>> 0xc0540c1c >          r6 = 0xc08ba1b0  r7 = 0xc08e5a48 >          r8 =
>>> 0x00000001  r9 = 0xc05d2918 >         r10 = 0xc0615aa4 > db_command_loop()
>>> at db_command_loop+0x60 >          pc = 0xc0231e54  lr = 0xc023481c
>>> (X_db_symbol_values+0x250) >          sp = 0xc08e5830  fp = 0xc08e5950 >
>>>          r4 = 0x00000000  r5 = 0xc08ba1bc >          r6 = 0xc0615ac8 >
>>> X_db_symbol_values() at X_db_symbol_values+0x250 >          pc =
>>> 0xc023481c  lr = 0xc0352c88 (kdb_trap+0x15c) >          sp = 0xc08e5958  fp
>>> = 0xc08e5978 >          r4 = 0x00000000  r5 = 0x00000005 >          r6 =
>>> 0xc0615ac8  r7 = 0xc08e5a48 > kdb_trap() at kdb_trap+0x15c >          pc =
>>> 0xc0352c88  lr = 0xc050138c (data_abort_handler+0x680) >          sp =
>>> 0xc08e5980  fp = 0xc08e5998 >          r4 = 0xc08e5a48  r5 = 0x00000005 >
>>>          r6 = 0x600001d3  r7 = 0x00000000 >          r8 = 0x00000013  r9 =
>>> 0xc08e5a48 >         r10 = 0x00000001 > data_abort_handler() at
>>> data_abort_handler+0x680 >          pc = 0xc050138c  lr = 0xc0501134
>>> (data_abort_handler+0x428) >          sp = 0xc08e59a0  fp = 0xc08e5a40 >
>>>          r4 = 0xc08e5eb0  r5 = 0xc08ba870 >          r6 = 0xc08ba548  r7 =
>>> 0x00000005 > data_abort_handler() at data_abort_handler+0x428 >          pc
>>> = 0xc0501134  lr = 0xc04ed754 (exception_exit) >          sp = 0xc08e5a48
>>> fp = 0xc08e5ab0 >          r4 = 0xc3b49f00  r5 = 0xc3b4a080 >          r6 =
>>> 0xc3b4a0b8  r7 = 0x00000000 >          r8 = 0xc056b038  r9 = 0xc3ae1700 >
>>>         r10 = 0xc05d4930 > exception_exit() at exception_exit >          pc
>>> = 0xc04ed754  lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) >          sp =
>>> 0xc08e5a98  fp = 0xc08e5ab0 >          r0 = 0x00000000  r1 = 0xc0547c85 >
>>>          r2 = 0x00000072  r3 = 0x00000008 >          r4 = 0xc3b49f00  r5 =
>>> 0xc3b4a080 >          r6 = 0xc3b4a0b8  r7 = 0x00000000 >          r8 =
>>> 0xc056b038  r9 = 0xc3ae1700 >         r10 = 0xc05d4930 r12 = 0x00000000 >
>>> strcmp() at strcmp+0x4 >          pc = 0xc03d7604  lr = 0xc024e0f0
>>> (mii_phy_flowstatus+0x2080) >          sp = 0xc08e5a98  fp = 0xc08e5ab0 >
>>> Unwind failure (no registers changed) > > Please try without emac driver.
>>> MII in Cubietruck could be different. > > Ganbold > >   > > >   > > >
>>> Message du 20/09/14 15:13 > > De : "Boris Astardzhiev" > > A : "Gilles
>>> DALMAS" > > Copie ? : freebsd-arm at freebsd.org > > Objet : Re: kernel
>>> debugger on cubietruck > > > > > > Hi, > > > As far as I see strcmp() is
>>> passed a NULL pointer, try issuing a backtrace to get the exact place of
>>> calling. > > > Regards > > On Sep 20, 2014 4:11 PM, "Gilles DALMAS"  wrote:
>>> > > hi, > > > >   > > > > I would compile freebsd for it run on a
>>> cubietruck. For this I used the wiki page:
>>> https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option
>>> confifuration "CUBIEBOARD2." everything goes well, but starting on the
>>> "truck", I get this message: > > > >   > > > > vm_fault(0xc08bab80, 0, 1,
>>> 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (S)' > >
>>> trapframe: 0xc08e5a48 > > FSR=00000005, FAR=00000000, spsr=a00001d3 > > r0
>>> =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008 > > r4 =c3b49f00, r5
>>> =c3b4a080, r6 =c3b4a0b8, r7 =00000000 > > r8 =c056b038, r9 =c3ae1700,
>>> r10=c05d4930, r11=c08e5ab0 > > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc
>>> =c03d7604 > > > > [ thread pid 0 tid 100000 ] > > Stopped at
>>> strcmp+0x4:     ldrb    r3, [r0] > > > > > > > > where is the problem
>>> please ? > > > > _______________________________________________ > >
>>> freebsd-arm at freebsd.org mailing list > >
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To
>>> unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > >
>>> _______________________________________________ >
>>> freebsd-arm at freebsd.org mailing list >
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe,
>>> send any mail to "freebsd-arm-unsubscribe at freebsd.org" >
>>> _______________________________________________ freebsd-arm at freebsd.org
>>> mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To
>>> unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>>>
>>>
>> > >
>>
>>
> >
>
>

From gdalmas at wanadoo.fr  Sun Sep 21 09:23:29 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Sun, 21 Sep 2014 11:23:26 +0200 (CEST)
Subject: kernel debugger on cubietruck
In-Reply-To: <CAGtf9xNwCxsmrdn-2pQg_E8zo=Mqyi+yozLJTExrtbQxyXKSZw@mail.gmail.com>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
 <584735728.12399.1411223474805.JavaMail.www@wwinf1p20>
 <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
 <139071258.18161.1411238741408.JavaMail.www@wwinf1p20>
 <857916216.19088.1411240494803.JavaMail.www@wwinf1p21>
 <CAGtf9xNwCxsmrdn-2pQg_E8zo=Mqyi+yozLJTExrtbQxyXKSZw@mail.gmail.com>
Message-ID: <508883102.5548.1411291406971.JavaMail.www@wwinf1p21>

it is therefore impossible to have ethernet with "cubietruck"?






> Message du 21/09/14 06:25
> De : "Ganbold Tsagaankhuu" 
> A : "Gilles DALMAS" 
> Copie ? : "freebsd-arm" 
> Objet : Re: kernel debugger on cubietruck
> 
>

>

>
On Sun, Sep 21, 2014 at 3:14 AM, Gilles DALMAS  wrote:
>

> the network interface is not detected
> 
> 
>



>
Cubietruck should have GMAC ethernet, currently it is not supported in FreeBSD.

>
Ganbold
?

> 
> 
>

> Message du 20/09/14 20:45
> > De : "Gilles DALMAS" 
> > A : "Ganbold Tsagaankhuu" 
> > Copie ? : "freebsd-arm" 
> > Objet : Re: kernel debugger on cubietruck
> > 
> > when I try to put "ufs: / dev / da0", the system starts but I have a lot of "no such device" and "spurious interrupt detected" > Message du 20/09/14 16:35 > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : > Objet : Re: kernel debugger on cubietruck > > > > On Sat, Sep 20, 2014 at 10:31 PM, Gilles DALMAS wrote: > > no need to re make the kernel-toolchain ? > > No just build kernel only. > Ganbold ? > > > > > > Message du 20/09/14 16:26 > > De : "Gilles DALMAS" > > A : "Ganbold Tsagaankhuu" > > Copie ? : "freebsd-arm at freebsd.org" > > Objet : Re: kernel debugger on cubietruck > > > > i comment emac line from : # Ethernet device??? ??? loop device??? ??? ether device??? ??? mii device??? ??? smscphy #device ??? cpsw device??? ??? bpf device??? ??? emac # USB ethernet support, requires miibus device??? ??? miibus ? and re run the compilation ? ? ? no need to re created the sd card ? just the USB flash ? ? > Message du 20/09/14 16:09 > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : "freebsd-arm at freebsd.org" > Objet : Re: kernel debugger on cubietruck > > > > On Sat, Sep 20, 2014 at 9:25 PM, Gilles DALMAS wrote: > I did not know much about debug kernel, but when I pass the trace command, I get: > > db> trace > Tracing pid 0 tid 100000 td 0xc08ba870 > db_trace_self() at db_trace_self > ???????? pc = 0xc04eba6c? lr = 0xc0232780 (db_hex2dec+0x4d8) > ???????? sp = 0xc08e5750? fp = 0xc08e5768 > ??????? r10 = 0xc08ba1c4 > db_hex2dec() at db_hex2dec+0x4d8 > ???????? pc = 0xc0232780? lr = 0xc02320f0 (db_command_loop+0x2fc) > ???????? sp = 0xc08e5770? fp = 0xc08e5810 > ???????? r4 = 0x00000000? r5 = 0x00000000 > ???????? r6 = 0x00000063 > db_command_loop() at db_command_loop+0x2fc > ???????? pc = 0xc02320f0? lr = 0xc0231e54 (db_command_loop+0x60) > ???????? sp = 0xc08e5818? fp = 0xc08e5828 > ???????? r4 = 0xc0528609? r5 = 0xc0540c1c > ???????? r6 = 0xc08ba1b0? r7 = 0xc08e5a48 > ???????? r8 = 0x00000001? r9 = 0xc05d2918 > ??????? r10 = 0xc0615aa4 > db_command_loop() at db_command_loop+0x60 > ???????? pc = 0xc0231e54? lr = 0xc023481c (X_db_symbol_values+0x250) > ???????? sp = 0xc08e5830? fp = 0xc08e5950 > ???????? r4 = 0x00000000? r5 = 0xc08ba1bc > ???????? r6 = 0xc0615ac8 > X_db_symbol_values() at X_db_symbol_values+0x250 > ???????? pc = 0xc023481c? lr = 0xc0352c88 (kdb_trap+0x15c) > ???????? sp = 0xc08e5958? fp = 0xc08e5978 > ???????? r4 = 0x00000000? r5 = 0x00000005 > ???????? r6 = 0xc0615ac8? r7 = 0xc08e5a48 > kdb_trap() at kdb_trap+0x15c > ???????? pc = 0xc0352c88? lr = 0xc050138c (data_abort_handler+0x680) > ???????? sp = 0xc08e5980? fp = 0xc08e5998 > ???????? r4 = 0xc08e5a48? r5 = 0x00000005 > ???????? r6 = 0x600001d3? r7 = 0x00000000 > ???????? r8 = 0x00000013? r9 = 0xc08e5a48 > ??????? r10 = 0x00000001 > data_abort_handler() at data_abort_handler+0x680 > ???????? pc = 0xc050138c? lr = 0xc0501134 (data_abort_handler+0x428) > ???????? sp = 0xc08e59a0? fp = 0xc08e5a40 > ???????? r4 = 0xc08e5eb0? r5 = 0xc08ba870 > ???????? r6 = 0xc08ba548? r7 = 0x00000005 > data_abort_handler() at data_abort_handler+0x428 > ???????? pc = 0xc0501134? lr = 0xc04ed754 (exception_exit) > ???????? sp = 0xc08e5a48? fp = 0xc08e5ab0 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 > exception_exit() at exception_exit > ???????? pc = 0xc04ed754? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > ???????? r0 = 0x00000000? r1 = 0xc0547c85 > ???????? r2 = 0x00000072? r3 = 0x00000008 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 r12 = 0x00000000 > strcmp() at strcmp+0x4 > ???????? pc = 0xc03d7604? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > Unwind failure (no registers changed) > > Please try without?emac?driver. MII in Cubietruck?could be different. > > Ganbold > > ? > > > ? > > > Message du 20/09/14 15:13 > > De : "Boris Astardzhiev" > > A : "Gilles DALMAS" > > Copie ? : freebsd-arm at freebsd.org > > Objet : Re: kernel debugger on cubietruck > > > > > > Hi, > > > As far as I see strcmp() is passed a NULL pointer, try issuing a backtrace to get the exact place of calling. > > > Regards > > On Sep 20, 2014 4:11 PM, "Gilles DALMAS"? wrote: > > hi, > > > > ? > > > > I would compile freebsd for it run on a cubietruck. For this I used the wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option confifuration "CUBIEBOARD2." everything goes well, but starting on the "truck", I get this message: > > > > ? > > > > vm_fault(0xc08bab80, 0, 1, 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (S)' > > trapframe: 0xc08e5a48 > > FSR=00000005, FAR=00000000, spsr=a00001d3 > > r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008 > > r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000 > > r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0 > > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604 > > > > [ thread pid 0 tid 100000 ] > > Stopped at????? strcmp+0x4:???? ldrb??? r3, [r0] > > > > > > > > where is the problem please ? > > > > _______________________________________________ > > freebsd-arm at freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > > _______________________________________________ > freebsd-arm at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > _______________________________________________ freebsd-arm at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > _______________________________________________ freebsd-arm at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"



>


From gdalmas at wanadoo.fr  Sun Sep 21 09:26:13 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Sun, 21 Sep 2014 11:26:04 +0200 (CEST)
Subject: kernel debugger on cubietruck
In-Reply-To: <CAGtf9xNwCxsmrdn-2pQg_E8zo=Mqyi+yozLJTExrtbQxyXKSZw@mail.gmail.com>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
 <584735728.12399.1411223474805.JavaMail.www@wwinf1p20>
 <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
 <139071258.18161.1411238741408.JavaMail.www@wwinf1p20>
 <857916216.19088.1411240494803.JavaMail.www@wwinf1p21>
 <CAGtf9xNwCxsmrdn-2pQg_E8zo=Mqyi+yozLJTExrtbQxyXKSZw@mail.gmail.com>
Message-ID: <1080334865.5589.1411291564251.JavaMail.www@wwinf1p21>

the "wifi" supported?






> Message du 21/09/14 06:25
> De : "Ganbold Tsagaankhuu" 
> A : "Gilles DALMAS" 
> Copie ? : "freebsd-arm" 
> Objet : Re: kernel debugger on cubietruck
> 
>

>

>
On Sun, Sep 21, 2014 at 3:14 AM, Gilles DALMAS  wrote:
>

> the network interface is not detected
> 
> 
>



>
Cubietruck should have GMAC ethernet, currently it is not supported in FreeBSD.

>
Ganbold
?

> 
> 
>

> Message du 20/09/14 20:45
> > De : "Gilles DALMAS" 
> > A : "Ganbold Tsagaankhuu" 
> > Copie ? : "freebsd-arm" 
> > Objet : Re: kernel debugger on cubietruck
> > 
> > when I try to put "ufs: / dev / da0", the system starts but I have a lot of "no such device" and "spurious interrupt detected" > Message du 20/09/14 16:35 > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : > Objet : Re: kernel debugger on cubietruck > > > > On Sat, Sep 20, 2014 at 10:31 PM, Gilles DALMAS wrote: > > no need to re make the kernel-toolchain ? > > No just build kernel only. > Ganbold ? > > > > > > Message du 20/09/14 16:26 > > De : "Gilles DALMAS" > > A : "Ganbold Tsagaankhuu" > > Copie ? : "freebsd-arm at freebsd.org" > > Objet : Re: kernel debugger on cubietruck > > > > i comment emac line from : # Ethernet device??? ??? loop device??? ??? ether device??? ??? mii device??? ??? smscphy #device ??? cpsw device??? ??? bpf device??? ??? emac # USB ethernet support, requires miibus device??? ??? miibus ? and re run the compilation ? ? ? no need to re created the sd card ? just the USB flash ? ? > Message du 20/09/14 16:09 > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : "freebsd-arm at freebsd.org" > Objet : Re: kernel debugger on cubietruck > > > > On Sat, Sep 20, 2014 at 9:25 PM, Gilles DALMAS wrote: > I did not know much about debug kernel, but when I pass the trace command, I get: > > db> trace > Tracing pid 0 tid 100000 td 0xc08ba870 > db_trace_self() at db_trace_self > ???????? pc = 0xc04eba6c? lr = 0xc0232780 (db_hex2dec+0x4d8) > ???????? sp = 0xc08e5750? fp = 0xc08e5768 > ??????? r10 = 0xc08ba1c4 > db_hex2dec() at db_hex2dec+0x4d8 > ???????? pc = 0xc0232780? lr = 0xc02320f0 (db_command_loop+0x2fc) > ???????? sp = 0xc08e5770? fp = 0xc08e5810 > ???????? r4 = 0x00000000? r5 = 0x00000000 > ???????? r6 = 0x00000063 > db_command_loop() at db_command_loop+0x2fc > ???????? pc = 0xc02320f0? lr = 0xc0231e54 (db_command_loop+0x60) > ???????? sp = 0xc08e5818? fp = 0xc08e5828 > ???????? r4 = 0xc0528609? r5 = 0xc0540c1c > ???????? r6 = 0xc08ba1b0? r7 = 0xc08e5a48 > ???????? r8 = 0x00000001? r9 = 0xc05d2918 > ??????? r10 = 0xc0615aa4 > db_command_loop() at db_command_loop+0x60 > ???????? pc = 0xc0231e54? lr = 0xc023481c (X_db_symbol_values+0x250) > ???????? sp = 0xc08e5830? fp = 0xc08e5950 > ???????? r4 = 0x00000000? r5 = 0xc08ba1bc > ???????? r6 = 0xc0615ac8 > X_db_symbol_values() at X_db_symbol_values+0x250 > ???????? pc = 0xc023481c? lr = 0xc0352c88 (kdb_trap+0x15c) > ???????? sp = 0xc08e5958? fp = 0xc08e5978 > ???????? r4 = 0x00000000? r5 = 0x00000005 > ???????? r6 = 0xc0615ac8? r7 = 0xc08e5a48 > kdb_trap() at kdb_trap+0x15c > ???????? pc = 0xc0352c88? lr = 0xc050138c (data_abort_handler+0x680) > ???????? sp = 0xc08e5980? fp = 0xc08e5998 > ???????? r4 = 0xc08e5a48? r5 = 0x00000005 > ???????? r6 = 0x600001d3? r7 = 0x00000000 > ???????? r8 = 0x00000013? r9 = 0xc08e5a48 > ??????? r10 = 0x00000001 > data_abort_handler() at data_abort_handler+0x680 > ???????? pc = 0xc050138c? lr = 0xc0501134 (data_abort_handler+0x428) > ???????? sp = 0xc08e59a0? fp = 0xc08e5a40 > ???????? r4 = 0xc08e5eb0? r5 = 0xc08ba870 > ???????? r6 = 0xc08ba548? r7 = 0x00000005 > data_abort_handler() at data_abort_handler+0x428 > ???????? pc = 0xc0501134? lr = 0xc04ed754 (exception_exit) > ???????? sp = 0xc08e5a48? fp = 0xc08e5ab0 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 > exception_exit() at exception_exit > ???????? pc = 0xc04ed754? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > ???????? r0 = 0x00000000? r1 = 0xc0547c85 > ???????? r2 = 0x00000072? r3 = 0x00000008 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 r12 = 0x00000000 > strcmp() at strcmp+0x4 > ???????? pc = 0xc03d7604? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > Unwind failure (no registers changed) > > Please try without?emac?driver. MII in Cubietruck?could be different. > > Ganbold > > ? > > > ? > > > Message du 20/09/14 15:13 > > De : "Boris Astardzhiev" > > A : "Gilles DALMAS" > > Copie ? : freebsd-arm at freebsd.org > > Objet : Re: kernel debugger on cubietruck > > > > > > Hi, > > > As far as I see strcmp() is passed a NULL pointer, try issuing a backtrace to get the exact place of calling. > > > Regards > > On Sep 20, 2014 4:11 PM, "Gilles DALMAS"? wrote: > > hi, > > > > ? > > > > I would compile freebsd for it run on a cubietruck. For this I used the wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option confifuration "CUBIEBOARD2." everything goes well, but starting on the "truck", I get this message: > > > > ? > > > > vm_fault(0xc08bab80, 0, 1, 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (S)' > > trapframe: 0xc08e5a48 > > FSR=00000005, FAR=00000000, spsr=a00001d3 > > r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008 > > r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000 > > r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0 > > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604 > > > > [ thread pid 0 tid 100000 ] > > Stopped at????? strcmp+0x4:???? ldrb??? r3, [r0] > > > > > > > > where is the problem please ? > > > > _______________________________________________ > > freebsd-arm at freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > > _______________________________________________ > freebsd-arm at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > _______________________________________________ freebsd-arm at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > _______________________________________________ freebsd-arm at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"



>


From ronald-lists at klop.ws  Sun Sep 21 09:43:36 2014
From: ronald-lists at klop.ws (Ronald Klop)
Date: Sun, 21 Sep 2014 11:43:25 +0200
Subject: SD card support on Sheevaplug
In-Reply-To: <1410562928.1909.YahooMailBasic@web122404.mail.ne1.yahoo.com>
References: <1410562928.1909.YahooMailBasic@web122404.mail.ne1.yahoo.com>
Message-ID: <op.xmi6mnawkndu52@82-171-231-144.ip.telfort.nl>

On Sat, 13 Sep 2014 01:02:08 +0200, Faraz Vahabzadeh via freebsd-arm  
<freebsd-arm at freebsd.org> wrote:

> Hi,
>
> I am wondering if the state of SD card support on Sheevaplug for FreeBSD  
> has seen any changes
> lately. The latest news I have is from a year ago:
>
> https://forums.freebsd.org/viewtopic.php?&t=41592
>
> Or if there are any workaround to make it work, I'd really appreciate it.
>
> Thanks,
> Raz


I would love to see this working too. But I'm afraid most developers work  
on more modern ARM boards nowadays.

Ronald.

From gdalmas at wanadoo.fr  Sun Sep 21 10:33:41 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Sun, 21 Sep 2014 12:33:32 +0200 (CEST)
Subject: kernel debugger on cubietruck
In-Reply-To: <CAGtf9xPj+xj7m018w+iHdHtj_or7nBMGkWbFS0YY+yBiHaaH4w@mail.gmail.com>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
 <584735728.12399.1411223474805.JavaMail.www@wwinf1p20>
 <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
 <139071258.18161.1411238741408.JavaMail.www@wwinf1p20>
 <CAGtf9xMzZeXSNpfes2ChLSvpaFMXHs2kgNY+ZLdjCo7fq=yekg@mail.gmail.com>
 <1878422084.4858.1411289901179.JavaMail.www@wwinf1p21>
 <CAGtf9xPj+xj7m018w+iHdHtj_or7nBMGkWbFS0YY+yBiHaaH4w@mail.gmail.com>
Message-ID: <1806716327.7584.1411295612240.JavaMail.www@wwinf1p21>

now it hangs with the message:

usbus0: EHCI version 1.0
usbus0 on ehci0
ehci1:  mem 0x1c1c000-0x1c1cfff irq 72 on simplebus0
usbus1: EHCI version 1.0
usbus1 on ehci1
uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 33 on simplebus0
uart0: console (115200,n,8,1)
Timecounters tick every 10.000 msec

?

I don't understand why

> Message du 21/09/14 11:11
> De : "Ganbold Tsagaankhuu" 
> A : "Gilles DALMAS" 
> Copie ? : "freebsd-arm" 
> Objet : Re: kernel debugger on cubietruck
> 
>

>

>
On Sun, Sep 21, 2014 at 4:58 PM, Gilles DALMAS  wrote:
>

> by cons, for managing sata disks, I can enable the "ahci"?
> 
>



>
There is no SATA driver yet in src tree. imp@ hopefully will commit a10/a20 sata driver soon to current.

>
Ganbold

>
?

> 
> 
> 
>

> Message du 21/09/14 06:28
> > De : "Ganbold Tsagaankhuu" 
> > A : "Gilles DALMAS" 
> > Copie ? : "freebsd-arm" 
> > Objet : Re: kernel debugger on cubietruck
> > 
> >

> >

> >
On Sun, Sep 21, 2014 at 2:45 AM, Gilles DALMAS  wrote:
> >

> > when I try to put "ufs: / dev / da0", the system starts but I have a lot of "no such device" and "spurious interrupt detected"



> >
For now, you can comment out "Spurious interrupt detected" in?http://svnweb.freebsd.org/base/head/sys/arm/arm/gic.c?revision=271630&view=markup#l364 and rebuild the kernel again and try.

> >
I didn't find yet the solution for it.

> >
Ganbold

> >

> >
?

> > 
> > 
> > 
> > 
> > 
> >

> Message du 20/09/14 16:35
> > > De : "Ganbold Tsagaankhuu" 
> > > A : "Gilles DALMAS" 
> > > Copie ? : 
> > > Objet : Re: kernel debugger on cubietruck
> > > 
> > >

> > >

> > >
On Sat, Sep 20, 2014 at 10:31 PM, Gilles DALMAS  wrote:
> > >

> > > no need to re make the kernel-toolchain ?
> > >



> > >
No just build kernel only.

> > >
Ganbold
?

> > > 
> > > 
> > > 
> > > 
> > >

> Message du 20/09/14 16:26
> > > > De : "Gilles DALMAS" 
> > > > A : "Ganbold Tsagaankhuu" 
> > > > Copie ? : "freebsd-arm at freebsd.org" 
> > > > Objet : Re: kernel debugger on cubietruck
> > > > 
> > > > i comment emac line from : # Ethernet device??? ??? loop device??? ??? ether device??? ??? mii device??? ??? smscphy #device ??? cpsw device??? ??? bpf device??? ??? emac # USB ethernet support, requires miibus device??? ??? miibus ? and re run the compilation ? ? ? no need to re created the sd card ? just the USB flash ? ? > Message du 20/09/14 16:09 > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : "freebsd-arm at freebsd.org" > Objet : Re: kernel debugger on cubietruck > > > > On Sat, Sep 20, 2014 at 9:25 PM, Gilles DALMAS wrote: > I did not know much about debug kernel, but when I pass the trace command, I get: > > db> trace > Tracing pid 0 tid 100000 td 0xc08ba870 > db_trace_self() at db_trace_self > ???????? pc = 0xc04eba6c? lr = 0xc0232780 (db_hex2dec+0x4d8) > ???????? sp = 0xc08e5750? fp = 0xc08e5768 > ??????? r10 = 0xc08ba1c4 > db_hex2dec() at db_hex2dec+0x4d8 > ???????? pc = 0xc0232780? lr = 0xc02320f0 (db_command_loop+0x2fc) > ???????? sp = 0xc08e5770? fp = 0xc08e5810 > ???????? r4 = 0x00000000? r5 = 0x00000000 > ???????? r6 = 0x00000063 > db_command_loop() at db_command_loop+0x2fc > ???????? pc = 0xc02320f0? lr = 0xc0231e54 (db_command_loop+0x60) > ???????? sp = 0xc08e5818? fp = 0xc08e5828 > ???????? r4 = 0xc0528609? r5 = 0xc0540c1c > ???????? r6 = 0xc08ba1b0? r7 = 0xc08e5a48 > ???????? r8 = 0x00000001? r9 = 0xc05d2918 > ??????? r10 = 0xc0615aa4 > db_command_loop() at db_command_loop+0x60 > ???????? pc = 0xc0231e54? lr = 0xc023481c (X_db_symbol_values+0x250) > ???????? sp = 0xc08e5830? fp = 0xc08e5950 > ???????? r4 = 0x00000000? r5 = 0xc08ba1bc > ???????? r6 = 0xc0615ac8 > X_db_symbol_values() at X_db_symbol_values+0x250 > ???????? pc = 0xc023481c? lr = 0xc0352c88 (kdb_trap+0x15c) > ???????? sp = 0xc08e5958? fp = 0xc08e5978 > ???????? r4 = 0x00000000? r5 = 0x00000005 > ???????? r6 = 0xc0615ac8? r7 = 0xc08e5a48 > kdb_trap() at kdb_trap+0x15c > ???????? pc = 0xc0352c88? lr = 0xc050138c (data_abort_handler+0x680) > ???????? sp = 0xc08e5980? fp = 0xc08e5998 > ???????? r4 = 0xc08e5a48? r5 = 0x00000005 > ???????? r6 = 0x600001d3? r7 = 0x00000000 > ???????? r8 = 0x00000013? r9 = 0xc08e5a48 > ??????? r10 = 0x00000001 > data_abort_handler() at data_abort_handler+0x680 > ???????? pc = 0xc050138c? lr = 0xc0501134 (data_abort_handler+0x428) > ???????? sp = 0xc08e59a0? fp = 0xc08e5a40 > ???????? r4 = 0xc08e5eb0? r5 = 0xc08ba870 > ???????? r6 = 0xc08ba548? r7 = 0x00000005 > data_abort_handler() at data_abort_handler+0x428 > ???????? pc = 0xc0501134? lr = 0xc04ed754 (exception_exit) > ???????? sp = 0xc08e5a48? fp = 0xc08e5ab0 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 > exception_exit() at exception_exit > ???????? pc = 0xc04ed754? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > ???????? r0 = 0x00000000? r1 = 0xc0547c85 > ???????? r2 = 0x00000072? r3 = 0x00000008 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 r12 = 0x00000000 > strcmp() at strcmp+0x4 > ???????? pc = 0xc03d7604? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > Unwind failure (no registers changed) > > Please try without?emac?driver. MII in Cubietruck?could be different. > > Ganbold > > ? > > > ? > > > Message du 20/09/14 15:13 > > De : "Boris Astardzhiev" > > A : "Gilles DALMAS" > > Copie ? : freebsd-arm at freebsd.org > > Objet : Re: kernel debugger on cubietruck > > > > > > Hi, > > > As far as I see strcmp() is passed a NULL pointer, try issuing a backtrace to get the exact place of calling. > > > Regards > > On Sep 20, 2014 4:11 PM, "Gilles DALMAS"? wrote: > > hi, > > > > ? > > > > I would compile freebsd for it run on a cubietruck. For this I used the wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option confifuration "CUBIEBOARD2." everything goes well, but starting on the "truck", I get this message: > > > > ? > > > > vm_fault(0xc08bab80, 0, 1, 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (S)' > > trapframe: 0xc08e5a48 > > FSR=00000005, FAR=00000000, spsr=a00001d3 > > r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008 > > r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000 > > r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0 > > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604 > > > > [ thread pid 0 tid 100000 ] > > Stopped at????? strcmp+0x4:???? ldrb??? r3, [r0] > > > > > > > > where is the problem please ? > > > > _______________________________________________ > > freebsd-arm at freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > > _______________________________________________ > freebsd-arm at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > _______________________________________________ freebsd-arm at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"



> > >





> >





>


From ganbold at gmail.com  Sun Sep 21 11:01:12 2014
From: ganbold at gmail.com (Ganbold Tsagaankhuu)
Date: Sun, 21 Sep 2014 19:01:11 +0800
Subject: kernel debugger on cubietruck
In-Reply-To: <1080334865.5589.1411291564251.JavaMail.www@wwinf1p21>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
 <584735728.12399.1411223474805.JavaMail.www@wwinf1p20>
 <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
 <139071258.18161.1411238741408.JavaMail.www@wwinf1p20>
 <857916216.19088.1411240494803.JavaMail.www@wwinf1p21>
 <CAGtf9xNwCxsmrdn-2pQg_E8zo=Mqyi+yozLJTExrtbQxyXKSZw@mail.gmail.com>
 <1080334865.5589.1411291564251.JavaMail.www@wwinf1p21>
Message-ID: <CAGtf9xPxJE-MdUvF-qpfWL8+8--44REw_tC6C6zpL-5RTz+WQQ@mail.gmail.com>

On Sun, Sep 21, 2014 at 5:26 PM, Gilles DALMAS <gdalmas at wanadoo.fr> wrote:

> the "wifi" supported?
>

As far as I can tell no one is working on GMAC ethernet driver. Since I
don't have the hardware I'm not sure which wifi it has.
https://linux-sunxi.org/Cubietruck#Wifi says something related to Broadcom.

Ganbold


>
>
>
>
>
> > Message du 21/09/14 06:25
> > De : "Ganbold Tsagaankhuu" <ganbold at gmail.com>
> > A : "Gilles DALMAS" <gdalmas at wanadoo.fr>
> > Copie ? : "freebsd-arm" <freebsd-arm at freebsd.org>
> > Objet : Re: kernel debugger on cubietruck
> >
> >
>
> >
>
> >
> On Sun, Sep 21, 2014 at 3:14 AM, Gilles DALMAS <gdalmas at wanadoo.fr> wrote:
> >
>>
>> > the network interface is not detected
>> >
>> >
>> >
>>
>
> >
> Cubietruck should have GMAC ethernet, currently it is not supported in
> FreeBSD.
>
> >
> Ganbold
>
>
>> >
>> >
>> >
>>
>> > Message du 20/09/14 20:45
>> > > De : "Gilles DALMAS" <gdalmas at wanadoo.fr>
>> > > A : "Ganbold Tsagaankhuu" <ganbold at gmail.com>
>> > > Copie ? : "freebsd-arm" <freebsd-arm at freebsd.org>
>> > > Objet : Re: kernel debugger on cubietruck
>> > >
>> > > when I try to put "ufs: / dev / da0", the system starts but I have a
>> lot of "no such device" and "spurious interrupt detected" > Message du
>> 20/09/14 16:35 > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ?
>> : > Objet : Re: kernel debugger on cubietruck > > > > On Sat, Sep 20, 2014
>> at 10:31 PM, Gilles DALMAS wrote: > > no need to re make the
>> kernel-toolchain ? > > No just build kernel only. > Ganbold   > > > > > >
>> Message du 20/09/14 16:26 > > De : "Gilles DALMAS" > > A : "Ganbold
>> Tsagaankhuu" > > Copie ? : "freebsd-arm at freebsd.org" > > Objet : Re:
>> kernel debugger on cubietruck > > > > i comment emac line from : # Ethernet
>> device        loop device        ether device        mii device
>> smscphy #device     cpsw device        bpf device        emac # USB
>> ethernet support, requires miibus device        miibus   and re run the
>> compilation ?     no need to re created the sd card ? just the USB flash ?
>>   > Message du 20/09/14 16:09 > De : "Ganbold Tsagaankhuu" > A : "Gilles
>> DALMAS" > Copie ? : "freebsd-arm at freebsd.org" > Objet : Re: kernel
>> debugger on cubietruck > > > > On Sat, Sep 20, 2014 at 9:25 PM, Gilles
>> DALMAS wrote: > I did not know much about debug kernel, but when I pass the
>> trace command, I get: > > db> trace > Tracing pid 0 tid 100000 td
>> 0xc08ba870 > db_trace_self() at db_trace_self >          pc = 0xc04eba6c
>> lr = 0xc0232780 (db_hex2dec+0x4d8) >          sp = 0xc08e5750  fp =
>> 0xc08e5768 >         r10 = 0xc08ba1c4 > db_hex2dec() at db_hex2dec+0x4d8 >
>>          pc = 0xc0232780  lr = 0xc02320f0 (db_command_loop+0x2fc) >
>>          sp = 0xc08e5770  fp = 0xc08e5810 >          r4 = 0x00000000  r5 =
>> 0x00000000 >          r6 = 0x00000063 > db_command_loop() at
>> db_command_loop+0x2fc >          pc = 0xc02320f0  lr = 0xc0231e54
>> (db_command_loop+0x60) >          sp = 0xc08e5818  fp = 0xc08e5828 >
>>          r4 = 0xc0528609  r5 = 0xc0540c1c >          r6 = 0xc08ba1b0  r7 =
>> 0xc08e5a48 >          r8 = 0x00000001  r9 = 0xc05d2918 >         r10 =
>> 0xc0615aa4 > db_command_loop() at db_command_loop+0x60 >          pc =
>> 0xc0231e54  lr = 0xc023481c (X_db_symbol_values+0x250) >          sp =
>> 0xc08e5830  fp = 0xc08e5950 >          r4 = 0x00000000  r5 = 0xc08ba1bc >
>>          r6 = 0xc0615ac8 > X_db_symbol_values() at X_db_symbol_values+0x250
>> >          pc = 0xc023481c  lr = 0xc0352c88 (kdb_trap+0x15c) >          sp
>> = 0xc08e5958  fp = 0xc08e5978 >          r4 = 0x00000000  r5 = 0x00000005 >
>>          r6 = 0xc0615ac8  r7 = 0xc08e5a48 > kdb_trap() at kdb_trap+0x15c >
>>          pc = 0xc0352c88  lr = 0xc050138c (data_abort_handler+0x680) >
>>          sp = 0xc08e5980  fp = 0xc08e5998 >          r4 = 0xc08e5a48  r5 =
>> 0x00000005 >          r6 = 0x600001d3  r7 = 0x00000000 >          r8 =
>> 0x00000013  r9 = 0xc08e5a48 >         r10 = 0x00000001 >
>> data_abort_handler() at data_abort_handler+0x680 >          pc =
>> 0xc050138c  lr = 0xc0501134 (data_abort_handler+0x428) >          sp =
>> 0xc08e59a0  fp = 0xc08e5a40 >          r4 = 0xc08e5eb0  r5 = 0xc08ba870 >
>>          r6 = 0xc08ba548  r7 = 0x00000005 > data_abort_handler() at
>> data_abort_handler+0x428 >          pc = 0xc0501134  lr = 0xc04ed754
>> (exception_exit) >          sp = 0xc08e5a48  fp = 0xc08e5ab0 >          r4
>> = 0xc3b49f00  r5 = 0xc3b4a080 >          r6 = 0xc3b4a0b8  r7 = 0x00000000 >
>>          r8 = 0xc056b038  r9 = 0xc3ae1700 >         r10 = 0xc05d4930 >
>> exception_exit() at exception_exit >          pc = 0xc04ed754  lr =
>> 0xc024e0f0 (mii_phy_flowstatus+0x2080) >          sp = 0xc08e5a98  fp =
>> 0xc08e5ab0 >          r0 = 0x00000000  r1 = 0xc0547c85 >          r2 =
>> 0x00000072  r3 = 0x00000008 >          r4 = 0xc3b49f00  r5 = 0xc3b4a080 >
>>          r6 = 0xc3b4a0b8  r7 = 0x00000000 >          r8 = 0xc056b038  r9 =
>> 0xc3ae1700 >         r10 = 0xc05d4930 r12 = 0x00000000 > strcmp() at
>> strcmp+0x4 >          pc = 0xc03d7604  lr = 0xc024e0f0
>> (mii_phy_flowstatus+0x2080) >          sp = 0xc08e5a98  fp = 0xc08e5ab0 >
>> Unwind failure (no registers changed) > > Please try without emac driver.
>> MII in Cubietruck could be different. > > Ganbold > >   > > >   > > >
>> Message du 20/09/14 15:13 > > De : "Boris Astardzhiev" > > A : "Gilles
>> DALMAS" > > Copie ? : freebsd-arm at freebsd.org > > Objet : Re: kernel
>> debugger on cubietruck > > > > > > Hi, > > > As far as I see strcmp() is
>> passed a NULL pointer, try issuing a backtrace to get the exact place of
>> calling. > > > Regards > > On Sep 20, 2014 4:11 PM, "Gilles DALMAS"  wrote:
>> > > hi, > > > >   > > > > I would compile freebsd for it run on a
>> cubietruck. For this I used the wiki page:
>> https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option
>> confifuration "CUBIEBOARD2." everything goes well, but starting on the
>> "truck", I get this message: > > > >   > > > > vm_fault(0xc08bab80, 0, 1,
>> 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (S)' > >
>> trapframe: 0xc08e5a48 > > FSR=00000005, FAR=00000000, spsr=a00001d3 > > r0
>> =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008 > > r4 =c3b49f00, r5
>> =c3b4a080, r6 =c3b4a0b8, r7 =00000000 > > r8 =c056b038, r9 =c3ae1700,
>> r10=c05d4930, r11=c08e5ab0 > > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc
>> =c03d7604 > > > > [ thread pid 0 tid 100000 ] > > Stopped at
>> strcmp+0x4:     ldrb    r3, [r0] > > > > > > > > where is the problem
>> please ? > > > > _______________________________________________ > >
>> freebsd-arm at freebsd.org mailing list > >
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To
>> unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > >
>> _______________________________________________ > freebsd-arm at freebsd.org
>> mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm >
>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" >
>> _______________________________________________ freebsd-arm at freebsd.org
>> mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To
>> unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" >
>> _______________________________________________ freebsd-arm at freebsd.org
>> mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To
>> unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>>
>>
> >
>
>

From gdalmas at wanadoo.fr  Sun Sep 21 11:50:59 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Sun, 21 Sep 2014 13:50:55 +0200 (CEST)
Subject: kernel debugger on cubietruck
In-Reply-To: <CAGtf9xPxJE-MdUvF-qpfWL8+8--44REw_tC6C6zpL-5RTz+WQQ@mail.gmail.com>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
 <584735728.12399.1411223474805.JavaMail.www@wwinf1p20>
 <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
 <139071258.18161.1411238741408.JavaMail.www@wwinf1p20>
 <857916216.19088.1411240494803.JavaMail.www@wwinf1p21>
 <CAGtf9xNwCxsmrdn-2pQg_E8zo=Mqyi+yozLJTExrtbQxyXKSZw@mail.gmail.com>
 <1080334865.5589.1411291564251.JavaMail.www@wwinf1p21>
 <CAGtf9xPxJE-MdUvF-qpfWL8+8--44REw_tC6C6zpL-5RTz+WQQ@mail.gmail.com>
Message-ID: <1445366845.8901.1411300255792.JavaMail.www@wwinf1p21>

but yes, there it is said, is only available for "linux". the "bcmdhd" module is also available on "freebsd"?






> Message du 21/09/14 13:07
> De : "Ganbold Tsagaankhuu" 
> A : "Gilles DALMAS" 
> Copie ? : "freebsd-arm" 
> Objet : Re: kernel debugger on cubietruck
> 
>

>

>
On Sun, Sep 21, 2014 at 5:26 PM, Gilles DALMAS  wrote:
>

> the "wifi" supported?



>
As far as I can tell no one is working on GMAC ethernet driver. Since I don't have the hardware I'm not sure which wifi it has.
https://linux-sunxi.org/Cubietruck#Wifi says something related to Broadcom.
>

>
Ganbold
?

> 
> 
> 
> 
> 
>

> Message du 21/09/14 06:25
> > De : "Ganbold Tsagaankhuu" 
> > A : "Gilles DALMAS" 
> 

> Copie ? : "freebsd-arm" 
> > Objet : Re: kernel debugger on cubietruck
> > 
> >

> >

> >
On Sun, Sep 21, 2014 at 3:14 AM, Gilles DALMAS  wrote:
> >

> > the network interface is not detected
> > 
> > 
> >



> >
Cubietruck should have GMAC ethernet, currently it is not supported in FreeBSD.

> >
Ganbold
?

> > 
> > 
> >

> Message du 20/09/14 20:45
> > > De : "Gilles DALMAS" 
> > > A : "Ganbold Tsagaankhuu" 
> > > Copie ? : "freebsd-arm" 
> > > Objet : Re: kernel debugger on cubietruck
> > > 
> > > when I try to put "ufs: / dev / da0", the system starts but I have a lot of "no such device" and "spurious interrupt detected" > Message du 20/09/14 16:35 > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : > Objet : Re: kernel debugger on cubietruck > > > > On Sat, Sep 20, 2014 at 10:31 PM, Gilles DALMAS wrote: > > no need to re make the kernel-toolchain ? > > No just build kernel only. > Ganbold ? > > > > > > Message du 20/09/14 16:26 > > De : "Gilles DALMAS" > > A : "Ganbold Tsagaankhuu" > > Copie ? : "freebsd-arm at freebsd.org" > > Objet : Re: kernel debugger on cubietruck > > > > i comment emac line from : # Ethernet device??? ??? loop device??? ??? ether device??? ??? mii device??? ??? smscphy #device ??? cpsw device??? ??? bpf device??? ??? emac # USB ethernet support, requires miibus device??? ??? miibus ? and re run the compilation ? ? ? no need to re created the sd card ? just the USB flash ? ? > Message du 20/09/14 16:09 > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : "freebsd-arm at freebsd.org" > Objet : Re: kernel debugger on cubietruck > > > > On Sat, Sep 20, 2014 at 9:25 PM, Gilles DALMAS wrote: > I did not know much about debug kernel, but when I pass the trace command, I get: > > db> trace > Tracing pid 0 tid 100000 td 0xc08ba870 > db_trace_self() at db_trace_self > ???????? pc = 0xc04eba6c? lr = 0xc0232780 (db_hex2dec+0x4d8) > ???????? sp = 0xc08e5750? fp = 0xc08e5768 > ??????? r10 = 0xc08ba1c4 > db_hex2dec() at db_hex2dec+0x4d8 > ???????? pc = 0xc0232780? lr = 0xc02320f0 (db_command_loop+0x2fc) > ???????? sp = 0xc08e5770? fp = 0xc08e5810 > ???????? r4 = 0x00000000? r5 = 0x00000000 > ???????? r6 = 0x00000063 > db_command_loop() at db_command_loop+0x2fc > ???????? pc = 0xc02320f0? lr = 0xc0231e54 (db_command_loop+0x60) > ???????? sp = 0xc08e5818? fp = 0xc08e5828 > ???????? r4 = 0xc0528609? r5 = 0xc0540c1c > ???????? r6 = 0xc08ba1b0? r7 = 0xc08e5a48 > ???????? r8 = 0x00000001? r9 = 0xc05d2918 > ??????? r10 = 0xc0615aa4 > db_command_loop() at db_command_loop+0x60 > ???????? pc = 0xc0231e54? lr = 0xc023481c (X_db_symbol_values+0x250) > ???????? sp = 0xc08e5830? fp = 0xc08e5950 > ???????? r4 = 0x00000000? r5 = 0xc08ba1bc > ???????? r6 = 0xc0615ac8 > X_db_symbol_values() at X_db_symbol_values+0x250 > ???????? pc = 0xc023481c? lr = 0xc0352c88 (kdb_trap+0x15c) > ???????? sp = 0xc08e5958? fp = 0xc08e5978 > ???????? r4 = 0x00000000? r5 = 0x00000005 > ???????? r6 = 0xc0615ac8? r7 = 0xc08e5a48 > kdb_trap() at kdb_trap+0x15c > ???????? pc = 0xc0352c88? lr = 0xc050138c (data_abort_handler+0x680) > ???????? sp = 0xc08e5980? fp = 0xc08e5998 > ???????? r4 = 0xc08e5a48? r5 = 0x00000005 > ???????? r6 = 0x600001d3? r7 = 0x00000000 > ???????? r8 = 0x00000013? r9 = 0xc08e5a48 > ??????? r10 = 0x00000001 > data_abort_handler() at data_abort_handler+0x680 > ???????? pc = 0xc050138c? lr = 0xc0501134 (data_abort_handler+0x428) > ???????? sp = 0xc08e59a0? fp = 0xc08e5a40 > ???????? r4 = 0xc08e5eb0? r5 = 0xc08ba870 > ???????? r6 = 0xc08ba548? r7 = 0x00000005 > data_abort_handler() at data_abort_handler+0x428 > ???????? pc = 0xc0501134? lr = 0xc04ed754 (exception_exit) > ???????? sp = 0xc08e5a48? fp = 0xc08e5ab0 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 > exception_exit() at exception_exit > ???????? pc = 0xc04ed754? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > ???????? r0 = 0x00000000? r1 = 0xc0547c85 > ???????? r2 = 0x00000072? r3 = 0x00000008 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 r12 = 0x00000000 > strcmp() at strcmp+0x4 > ???????? pc = 0xc03d7604? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > Unwind failure (no registers changed) > > Please try without?emac?driver. MII in Cubietruck?could be different. > > Ganbold > > ? > > > ? > > > Message du 20/09/14 15:13 > > De : "Boris Astardzhiev" > > A : "Gilles DALMAS" > > Copie ? : freebsd-arm at freebsd.org > > Objet : Re: kernel debugger on cubietruck > > > > > > Hi, > > > As far as I see strcmp() is passed a NULL pointer, try issuing a backtrace to get the exact place of calling. > > > Regards > > On Sep 20, 2014 4:11 PM, "Gilles DALMAS"? wrote: > > hi, > > > > ? > > > > I would compile freebsd for it run on a cubietruck. For this I used the wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option confifuration "CUBIEBOARD2." everything goes well, but starting on the "truck", I get this message: > > > > ? > > > > vm_fault(0xc08bab80, 0, 1, 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (S)' > > trapframe: 0xc08e5a48 > > FSR=00000005, FAR=00000000, spsr=a00001d3 > > r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008 > > r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000 > > r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0 > > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604 > > > > [ thread pid 0 tid 100000 ] > > Stopped at????? strcmp+0x4:???? ldrb??? r3, [r0] > > > > > > > > where is the problem please ? > > > > _______________________________________________ > > freebsd-arm at freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > > _______________________________________________ > freebsd-arm at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > _______________________________________________ freebsd-arm at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > _______________________________________________ freebsd-arm at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"



> >







>


From gdalmas at wanadoo.fr  Sun Sep 21 12:43:38 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Sun, 21 Sep 2014 14:43:29 +0200 (CEST)
Subject: freebsd 10 toolchain compilation
Message-ID: <1404516519.9523.1411303409543.JavaMail.www@wwinf1p21>

hello,

?

good I begins again. my problems so far, concerned version 11 of freebsd. I did that to understand a little how it worked, but in the purpose, I would have a version 10 of freebsd. if possible. 

So my current problem is an error message when I compile the toolchain:

?

===> lib/libelf (obj,depend,all,install)
/usr/obj/arm.armv6/usr/home/gilles/freebsd-release-10.0.0/tmp/usr/home/gilles/freebsd-release-10.0.0/lib/libelf created for /usr/home/gilles/freebsd-release-10.0.0/lib/libelf
make[3]: don't know how to make elf_memory.c. Stop

make[3]: stopped in /usr/home/gilles/freebsd-release-10.0.0/lib/libelf
*** Error code 2

Stop.
make[2]: stopped in /usr/home/gilles/freebsd-release-10.0.0
*** Error code 1

Stop.
make[1]: stopped in /usr/home/gilles/freebsd-release-10.0.0
*** Error code 1

Stop.
make: stopped in /usr/home/gilles/freebsd-release-10.0.0



?

?


I have yet to make any changes.

From gdalmas at wanadoo.fr  Sun Sep 21 13:43:07 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Sun, 21 Sep 2014 15:42:58 +0200 (CEST)
Subject: freebsd 10 toolchain compilation
In-Reply-To: <1404516519.9523.1411303409543.JavaMail.www@wwinf1p21>
References: <1404516519.9523.1411303409543.JavaMail.www@wwinf1p21>
Message-ID: <1821354288.10901.1411306978210.JavaMail.www@wwinf1p21>

sorry, I was wrong source,
by cons, I get this error now:

===> lib/libc (cleandir)
make[4]: "/usr/home/gilles/freebsd-stable-10/lib/libc/Makefile" line 77: Cannot open /usr/home/gilles/freebsd-stable-10/lib/libc/md/Makefile.inc
make[4]: "/usr/home/gilles/freebsd-stable-10/lib/libc/Makefile" line 78: Cannot open /usr/home/gilles/freebsd-stable-10/lib/libc/nameser/Makefile.inc
make[4]: "/usr/home/gilles/freebsd-stable-10/lib/libc/Makefile" line 79: Cannot open /usr/home/gilles/freebsd-stable-10/lib/libc/net/Makefile.inc
make[4]: Fatal errors encountered -- cannot continue
make[4]: stopped in /usr/home/gilles/freebsd-stable-10/lib/libc
*** Error code 1

Stop.
make[3]: stopped in /usr/home/gilles/freebsd-stable-10/lib
*** Error code 1

Stop.
make[2]: stopped in /usr/home/gilles/freebsd-stable-10
*** Error code 1

Stop.
make[1]: stopped in /usr/home/gilles/freebsd-stable-10
*** Error code 1

Stop.
make: stopped in /usr/home/gilles/freebsd-stable-10




I went into the directory of makefile.inc. but that file is broken link.

> Message du 21/09/14 14:43
> De : "Gilles DALMAS" 
> A : "freebsd-arm" 
> Copie ? : 
> Objet : freebsd 10 toolchain compilation
> 
> hello, ? good I begins again. my problems so far, concerned version 11 of freebsd. I did that to understand a little how it worked, but in the purpose, I would have a version 10 of freebsd. if possible. So my current problem is an error message when I compile the toolchain: ? ===> lib/libelf (obj,depend,all,install) /usr/obj/arm.armv6/usr/home/gilles/freebsd-release-10.0.0/tmp/usr/home/gilles/freebsd-release-10.0.0/lib/libelf created for /usr/home/gilles/freebsd-release-10.0.0/lib/libelf make[3]: don't know how to make elf_memory.c. Stop make[3]: stopped in /usr/home/gilles/freebsd-release-10.0.0/lib/libelf *** Error code 2 Stop. make[2]: stopped in /usr/home/gilles/freebsd-release-10.0.0 *** Error code 1 Stop. make[1]: stopped in /usr/home/gilles/freebsd-release-10.0.0 *** Error code 1 Stop. make: stopped in /usr/home/gilles/freebsd-release-10.0.0 ? ? I have yet to make any changes. _______________________________________________ freebsd-arm at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

From ian at FreeBSD.org  Sun Sep 21 13:43:44 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Sun, 21 Sep 2014 07:43:39 -0600
Subject: Jetson TK1 board support
In-Reply-To: <CAASDrVkY3uSZUPV7r0LrzfxPhLsMvvLN5=eg9zd7pgKEisVifw@mail.gmail.com>
References: <CAASDrVkKEPUeoQqfo0_O9XpCB7Tdqgjs_VgjM9UeqWMVKt5+TQ@mail.gmail.com>
 <D041D0CA.4C994%john@thehowies.com>
 <CAASDrVkY3uSZUPV7r0LrzfxPhLsMvvLN5=eg9zd7pgKEisVifw@mail.gmail.com>
Message-ID: <1411307019.66615.158.camel@revolution.hippie.lan>

On Sun, 2014-09-21 at 16:45 +0900, Lundberg, Johannes wrote:
> Great!
> 
> What I've done so far is
> 
> - build and patch (enable API) u-boot-nvidia on freebsd (i think i got it
> from git://nv-tegra.nvidia.com/3rdparty/u-boot.git, the normal u-boot
> wouldn't work...)
> - flash u-boot-dtb-tegra.img onto the board's mmc using nvidia's flash tool
> on ubuntu
> - build an image using crochet and dd to sd card (so far I copied the
> beaglebone setup, just to get a ubldr and a kernel file)
> 
> 
> From u-boot I can see all devices. I load ubldr with
> fatload mmc 1:1 0x80200000 ubldr
> bootelf 0x80200000
> 
> ubldr load fine but, from ubldr I can only see the mmc 0 and net devices.
> There's no sd card (mmc 1), and no ufs partition..
> 
> 
> 
> 
> --
> Johannes Lundberg
> BRILLIANTSERVICE CO., LTD.
> 
> On Fri, Sep 19, 2014 at 8:25 PM, John Howie <john at thehowies.com> wrote:
> 
> > Hi all,
> >
> > I am up for testing and supporting this board. I ordered and received
> > mine, but have not really had a chance to use it due to work to-date. The
> > good news is the next few months I will have bandwidth.
> >
> > Regards,
> >
> > John
> >
> >
> > On 9/19/14, 12:15 PM, "Lundberg, Johannes"
> > <johannes at brilliantservice.co.jp> wrote:
> >
> > >Hi
> > >
> > >I started working on adding the Jetson TK1 board to Crochet. Is there any
> > >work in progress on this?
> > >I guess there is quite a lot of work that has to been done to get full
> > >support for it in the kernel as well..
> > >
> > >Best regards
> > >--
> > >Johannes Lundberg
> > >

You may have to change some u-boot options to support multiple mmc/sd
interfaces.  Look in the config header for CONFIG_SYS_MMC_MAX_DEVICE; if
it's not there you may need to add it.  For wandboard I also had to add
a freescale-specific one, CONFIG_SYS_FSL_USDHC_NUM, so there may be
something like that you need to find as well.

-- Ian



From ian at FreeBSD.org  Sun Sep 21 13:56:04 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Sun, 21 Sep 2014 07:56:01 -0600
Subject: FreeBSD-11.0-CURRENT on ARM: performance and load average
In-Reply-To: <16223180.9Q4Ic3raYi@quad>
References: <7351653.A2UeEk9AA3@quad> <1989123.lKm0QJoZES@quad>
 <1411256769.66615.155.camel@revolution.hippie.lan>
 <16223180.9Q4Ic3raYi@quad>
Message-ID: <1411307761.66615.166.camel@revolution.hippie.lan>

On Sun, 2014-09-21 at 13:06 +0400, Maxim V FIlimonov wrote:
> On Saturday 20 September 2014 17:46:09 Ian Lepore wrote:
> > 
> > 60 times as fast doesn't make much sense for changing a divisor to 16.
> > 
> > Without that patch, what is the output of
> > 
> >  sysctl kern.eventtimer
> >  sysctl kern.timecounter
> 
> Here it is:
> root at cubie:~ # sysctl kern.eventtimer
> kern.eventtimer.et.a10_timer Eventtimer.flags: 3
> kern.eventtimer.et.a10_timer Eventtimer.frequency: 24000000
> kern.eventtimer.et.a10_timer Eventtimer.quality: 1000
> kern.eventtimer.choice: a10_timer Eventtimer(1000)
> kern.eventtimer.singlemul: 4
> kern.eventtimer.idletick: 0
> kern.eventtimer.timer: a10_timer Eventtimer
> kern.eventtimer.periodic: 1
> root at cubie:~ # sysctl kern.timecounter
> kern.timecounter.tc.a10_timer timer0.mask: 4294967295
> kern.timecounter.tc.a10_timer timer0.counter: 4271639596
> kern.timecounter.tc.a10_timer timer0.frequency: 24000000
> kern.timecounter.tc.a10_timer timer0.quality: 1000
> kern.timecounter.stepwarnings: 0
> kern.timecounter.alloweddeviation: 5
> kern.timecounter.hardware: a10_timer timer0
> kern.timecounter.choice: a10_timer timer0(1000) dummy(-1000000)
> kern.timecounter.tick: 1
> kern.timecounter.fast_gettime: 1
> 
> 
> > 
> > If you repeatedly do "ntpdate -q <some server>" every 15 seconds for a
> > couple minutes, does the offset stay pretty much the same?  (like no big
> > changes in the first two decimal places)  Don't use a server like
> > pool.ntp.org where you might get a different server every time, instead
> > do "host pool.ntp.org" and pick one of the IPs and use it every time.
> > 
> 
> root at cubie:~ # ntpdate time.nist.gov
> 21 Sep 13:04:55 ntpdate[2236]: adjust time server 24.56.178.140 offset 
> -0.117727 sec
> root at cubie:~ # ntpdate time.nist.gov
> 21 Sep 13:04:57 ntpdate[2237]: adjust time server 24.56.178.140 offset 
> -0.117018 sec
> root at cubie:~ # ntpdate time.nist.gov
> 21 Sep 13:05:00 ntpdate[2238]: adjust time server 24.56.178.140 offset 
> -0.116026 sec
> root at cubie:~ # ntpdate time.nist.gov
> 21 Sep 13:05:08 ntpdate[2241]: adjust time server 24.56.178.140 offset 
> -0.111525 sec
> root at cubie:~ # ntpdate time.nist.gov
> 21 Sep 13:05:26 ntpdate[2242]: adjust time server 24.56.178.140 offset 
> -0.103121 sec
> root at cubie:~ # ntpdate time.nist.gov
> 21 Sep 13:05:34 ntpdate[2243]: adjust time server 24.56.178.140 offset 
> -0.099055 sec
> 
> So as you could notice, the offset doesn't change much.

No, quite to the contrary, the time is changing rapidly -- it moved
about 19 milliseconds in 39 seconds, or roughly a millisecond every two
seconds.  That's an error rate of 500 parts per million, which is huge.
However, it's not off by a factor of 16, so that's a bit confusing.

BTW, time.nist.gov is not one server, it's a pool just like pool.ntp.org
(we run one of the time.nist.gov server installations out of our
building at $work).  I think it probably worked for you because of some
sort of dns caching effect, because you clearly kept getting the same
server each time.

-- Ian



From weiss at uni-mainz.de  Sun Sep 21 14:30:16 2014
From: weiss at uni-mainz.de (=?iso-8859-1?Q?Wei=DF=2C__Dr=2E_J=FCrgen?=)
Date: Sun, 21 Sep 2014 14:30:09 +0000
Subject: Jetson TK1 board support
In-Reply-To: <1411307019.66615.158.camel@revolution.hippie.lan>
References: <CAASDrVkKEPUeoQqfo0_O9XpCB7Tdqgjs_VgjM9UeqWMVKt5+TQ@mail.gmail.com>
 <D041D0CA.4C994%john@thehowies.com>
 <CAASDrVkY3uSZUPV7r0LrzfxPhLsMvvLN5=eg9zd7pgKEisVifw@mail.gmail.com>
 <1411307019.66615.158.camel@revolution.hippie.lan>
Message-ID: <fd18f77d7e6d4de4b1a26aece9e3956b@e15be-02.zdv.Uni-Mainz.DE>

Hi,

I have a rather rough port of FreeBSD current on arm to Jetson TK1. I
used Stephen Warren's tegra u-boot sources, which initialize and configure
USB and PCIe. 

So SMP, USB and the onboard PCIe Ethernet adapter work.

After Ian's changes to busdma_machdep-v6 (r269212) I had problems with
cache coherency with the Ethernet adapter. Seems this is due to the aggressive
L2 prefetcher of Cortex A15. Disabling L2 prefetch does help, as well as
invalidating the cache a second time after the dma transfer. I'm not
sure what the correct solution to this problem is. I wonder how
other Cortex A15 platforms (exynos5) handle this. 

I will probably be able to do some cleanups and put patches on the web
within a week.

Regards

Juergen

Juergen Weiss      |Universitaet Mainz, Zentrum fuer Datenverarbeitung,
weiss at uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407

> -----Original Message-----
> From: owner-freebsd-arm at freebsd.org [mailto:owner-freebsd-arm at freebsd.org] On Behalf Of
> Ian Lepore
> Sent: Sunday, September 21, 2014 3:44 PM
> To: Lundberg, Johannes
> Cc: freebsd-arm at freebsd.org
> Subject: Re: Jetson TK1 board support
> 
> On Sun, 2014-09-21 at 16:45 +0900, Lundberg, Johannes wrote:
> > Great!
> >
> > What I've done so far is
> >
> > - build and patch (enable API) u-boot-nvidia on freebsd (i think i got it
> > from git://nv-tegra.nvidia.com/3rdparty/u-boot.git, the normal u-boot
> > wouldn't work...)
> > - flash u-boot-dtb-tegra.img onto the board's mmc using nvidia's flash tool
> > on ubuntu
> > - build an image using crochet and dd to sd card (so far I copied the
> > beaglebone setup, just to get a ubldr and a kernel file)
> >
> >
> > From u-boot I can see all devices. I load ubldr with
> > fatload mmc 1:1 0x80200000 ubldr
> > bootelf 0x80200000
> >
> > ubldr load fine but, from ubldr I can only see the mmc 0 and net devices.
> > There's no sd card (mmc 1), and no ufs partition..
> >
> >
> >
> >
> > --
> > Johannes Lundberg
> > BRILLIANTSERVICE CO., LTD.
> >
> > On Fri, Sep 19, 2014 at 8:25 PM, John Howie <john at thehowies.com> wrote:
> >
> > > Hi all,
> > >
> > > I am up for testing and supporting this board. I ordered and received
> > > mine, but have not really had a chance to use it due to work to-date. The
> > > good news is the next few months I will have bandwidth.
> > >
> > > Regards,
> > >
> > > John
> > >
> > >
> > > On 9/19/14, 12:15 PM, "Lundberg, Johannes"
> > > <johannes at brilliantservice.co.jp> wrote:
> > >
> > > >Hi
> > > >
> > > >I started working on adding the Jetson TK1 board to Crochet. Is there any
> > > >work in progress on this?
> > > >I guess there is quite a lot of work that has to been done to get full
> > > >support for it in the kernel as well..
> > > >
> > > >Best regards
> > > >--
> > > >Johannes Lundberg
> > > >
> 
> You may have to change some u-boot options to support multiple mmc/sd
> interfaces.  Look in the config header for CONFIG_SYS_MMC_MAX_DEVICE; if
> it's not there you may need to add it.  For wandboard I also had to add
> a freescale-specific one, CONFIG_SYS_FSL_USDHC_NUM, so there may be
> something like that you need to find as well.
> 
> -- Ian
> 
> 
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

From che at bein.link  Sun Sep 21 18:34:03 2014
From: che at bein.link (Maxim V FIlimonov)
Date: Sun, 21 Sep 2014 22:33:58 +0400
Subject: FreeBSD-11.0-CURRENT on ARM: performance and load average
In-Reply-To: <1411307761.66615.166.camel@revolution.hippie.lan>
References: <7351653.A2UeEk9AA3@quad> <16223180.9Q4Ic3raYi@quad>
 <1411307761.66615.166.camel@revolution.hippie.lan>
Message-ID: <8990779.WPLHzDdnAo@quad>

On Sunday 21 September 2014 07:56:01 Ian Lepore wrote:
> On Sun, 2014-09-21 at 13:06 +0400, Maxim V FIlimonov wrote:
> > 
> > root at cubie:~ # ntpdate time.nist.gov
> > 21 Sep 13:04:55 ntpdate[2236]: adjust time server 24.56.178.140 offset
> > -0.117727 sec
> > root at cubie:~ # ntpdate time.nist.gov
> > 21 Sep 13:04:57 ntpdate[2237]: adjust time server 24.56.178.140 offset
> > -0.117018 sec
> > root at cubie:~ # ntpdate time.nist.gov
> > 21 Sep 13:05:00 ntpdate[2238]: adjust time server 24.56.178.140 offset
> > -0.116026 sec
> > root at cubie:~ # ntpdate time.nist.gov
> > 21 Sep 13:05:08 ntpdate[2241]: adjust time server 24.56.178.140 offset
> > -0.111525 sec
> > root at cubie:~ # ntpdate time.nist.gov
> > 21 Sep 13:05:26 ntpdate[2242]: adjust time server 24.56.178.140 offset
> > -0.103121 sec
> > root at cubie:~ # ntpdate time.nist.gov
> > 21 Sep 13:05:34 ntpdate[2243]: adjust time server 24.56.178.140 offset
> > -0.099055 sec
> > 
> > So as you could notice, the offset doesn't change much.
> 
> No, quite to the contrary, the time is changing rapidly -- it moved
> about 19 milliseconds in 39 seconds, or roughly a millisecond every two
> seconds.  That's an error rate of 500 parts per million, which is huge.
> However, it's not off by a factor of 16, so that's a bit confusing.
> 

Let me not agree with you. As you might have noticed, the time has the same 
offset no matter what exatc timeout I made before actually getting the time 
from the NTP pool. Here's another example of what I'm speaking about:

root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:24:56 ntpdate[660]: step time server 85.21.78.23 offset 7525.060549 
sec
root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:25:03 ntpdate[661]: adjust time server 95.213.132.250 offset 
-0.014318 sec
root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:25:07 ntpdate[662]: adjust time server 31.131.249.19 offset -0.010051 
sec
root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:25:24 ntpdate[663]: adjust time server 95.213.132.250 offset 
-0.005744 sec

You could notice that the offset changes a bit, and sometimes it can even 
decrease.
Here's one more example: I ran ntpdate some times in a row, then waited for 
about a minute:

root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:28:36 ntpdate[664]: adjust time server 95.213.132.250 offset 0.004790 
sec
root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:28:41 ntpdate[665]: adjust time server 31.131.249.19 offset 0.005558 
sec
root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:28:43 ntpdate[666]: adjust time server 31.131.249.19 offset 0.003983 
sec
root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:28:45 ntpdate[667]: adjust time server 31.131.249.19 offset -0.000497 
sec
root at cubie:~ # ntpdate pool.ntp.org
21 Sep 22:29:24 ntpdate[668]: adjust time server 31.131.249.19 offset 0.003195 
sec

If what I understood about what you said was right, the offset would increase, 
wouldn't it? This time it is approximately the same no matter what the time 
gap between two ntpdate's is.

Furthermore, here's what my PC says on ntpdate:

[22:32:07] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
21 Sep 22:32:11 ntpdate[40593]: signal_no_reset: signal 14 had flags 40
21 Sep 22:32:15 ntpdate[40593]: adjust time server 85.21.78.23 offset 0.008892 
sec
[22:32:15] 0 [che at quad:~]$ 
[22:32:15] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
21 Sep 22:32:18 ntpdate[40595]: signal_no_reset: signal 14 had flags 40
21 Sep 22:32:23 ntpdate[40595]: adjust time server 85.21.78.23 offset 0.007959 
sec
[22:32:23] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
21 Sep 22:32:25 ntpdate[40597]: signal_no_reset: signal 14 had flags 40
21 Sep 22:32:30 ntpdate[40597]: adjust time server 85.21.78.23 offset 0.004498 
sec
[22:32:30] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
21 Sep 22:32:45 ntpdate[40599]: signal_no_reset: signal 14 had flags 40
21 Sep 22:32:49 ntpdate[40599]: adjust time server 85.21.78.23 offset -0.005016 
sec

See, the offset differs much more (note the last try, it changed its sign) yet 
it's about the same value as on my cubieboard.

> BTW, time.nist.gov is not one server, it's a pool just like pool.ntp.org
> (we run one of the time.nist.gov server installations out of our
> building at $work).  I think it probably worked for you because of some
> sort of dns caching effect, because you clearly kept getting the same
> server each time.
> 
> -- Ian
-- 
wbr, Maxim Filimonov
che at bein.link

From ganbold at gmail.com  Mon Sep 22 01:45:58 2014
From: ganbold at gmail.com (Ganbold Tsagaankhuu)
Date: Mon, 22 Sep 2014 09:45:57 +0800
Subject: FreeBSD-11.0-CURRENT on ARM: performance and load average
In-Reply-To: <8990779.WPLHzDdnAo@quad>
References: <7351653.A2UeEk9AA3@quad> <16223180.9Q4Ic3raYi@quad>
 <1411307761.66615.166.camel@revolution.hippie.lan>
 <8990779.WPLHzDdnAo@quad>
Message-ID: <CAGtf9xNcjrfK4E8jDWhMgXeaF5c49HADgfHVTef_f8ZT-yjoMg@mail.gmail.com>

Max, Dmitry,

On Mon, Sep 22, 2014 at 2:33 AM, Maxim V FIlimonov <che at bein.link> wrote:

> On Sunday 21 September 2014 07:56:01 Ian Lepore wrote:
> > On Sun, 2014-09-21 at 13:06 +0400, Maxim V FIlimonov wrote:
> > >
> > > root at cubie:~ # ntpdate time.nist.gov
> > > 21 Sep 13:04:55 ntpdate[2236]: adjust time server 24.56.178.140 offset
> > > -0.117727 sec
> > > root at cubie:~ # ntpdate time.nist.gov
> > > 21 Sep 13:04:57 ntpdate[2237]: adjust time server 24.56.178.140 offset
> > > -0.117018 sec
> > > root at cubie:~ # ntpdate time.nist.gov
> > > 21 Sep 13:05:00 ntpdate[2238]: adjust time server 24.56.178.140 offset
> > > -0.116026 sec
> > > root at cubie:~ # ntpdate time.nist.gov
> > > 21 Sep 13:05:08 ntpdate[2241]: adjust time server 24.56.178.140 offset
> > > -0.111525 sec
> > > root at cubie:~ # ntpdate time.nist.gov
> > > 21 Sep 13:05:26 ntpdate[2242]: adjust time server 24.56.178.140 offset
> > > -0.103121 sec
> > > root at cubie:~ # ntpdate time.nist.gov
> > > 21 Sep 13:05:34 ntpdate[2243]: adjust time server 24.56.178.140 offset
> > > -0.099055 sec
> > >
> > > So as you could notice, the offset doesn't change much.
> >
> > No, quite to the contrary, the time is changing rapidly -- it moved
> > about 19 milliseconds in 39 seconds, or roughly a millisecond every two
> > seconds.  That's an error rate of 500 parts per million, which is huge.
> > However, it's not off by a factor of 16, so that's a bit confusing.
> >
>
> Let me not agree with you. As you might have noticed, the time has the same
> offset no matter what exatc timeout I made before actually getting the time
> from the NTP pool. Here's another example of what I'm speaking about:
>
> root at cubie:~ # ntpdate pool.ntp.org
> 21 Sep 22:24:56 ntpdate[660]: step time server 85.21.78.23 offset
> 7525.060549
> sec
> root at cubie:~ # ntpdate pool.ntp.org
> 21 Sep 22:25:03 ntpdate[661]: adjust time server 95.213.132.250 offset
> -0.014318 sec
> root at cubie:~ # ntpdate pool.ntp.org
> 21 Sep 22:25:07 ntpdate[662]: adjust time server 31.131.249.19 offset
> -0.010051
> sec
> root at cubie:~ # ntpdate pool.ntp.org
> 21 Sep 22:25:24 ntpdate[663]: adjust time server 95.213.132.250 offset
> -0.005744 sec
>
> You could notice that the offset changes a bit, and sometimes it can even
> decrease.
> Here's one more example: I ran ntpdate some times in a row, then waited for
> about a minute:
>
> root at cubie:~ # ntpdate pool.ntp.org
> 21 Sep 22:28:36 ntpdate[664]: adjust time server 95.213.132.250 offset
> 0.004790
> sec
> root at cubie:~ # ntpdate pool.ntp.org
> 21 Sep 22:28:41 ntpdate[665]: adjust time server 31.131.249.19 offset
> 0.005558
> sec
> root at cubie:~ # ntpdate pool.ntp.org
> 21 Sep 22:28:43 ntpdate[666]: adjust time server 31.131.249.19 offset
> 0.003983
> sec
> root at cubie:~ # ntpdate pool.ntp.org
> 21 Sep 22:28:45 ntpdate[667]: adjust time server 31.131.249.19 offset
> -0.000497
> sec
> root at cubie:~ # ntpdate pool.ntp.org
> 21 Sep 22:29:24 ntpdate[668]: adjust time server 31.131.249.19 offset
> 0.003195
> sec
>
> If what I understood about what you said was right, the offset would
> increase,
> wouldn't it? This time it is approximately the same no matter what the time
> gap between two ntpdate's is.
>
> Furthermore, here's what my PC says on ntpdate:
>
> [22:32:07] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
> 21 Sep 22:32:11 ntpdate[40593]: signal_no_reset: signal 14 had flags 40
> 21 Sep 22:32:15 ntpdate[40593]: adjust time server 85.21.78.23 offset
> 0.008892
> sec
> [22:32:15] 0 [che at quad:~]$
> [22:32:15] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
> 21 Sep 22:32:18 ntpdate[40595]: signal_no_reset: signal 14 had flags 40
> 21 Sep 22:32:23 ntpdate[40595]: adjust time server 85.21.78.23 offset
> 0.007959
> sec
> [22:32:23] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
> 21 Sep 22:32:25 ntpdate[40597]: signal_no_reset: signal 14 had flags 40
> 21 Sep 22:32:30 ntpdate[40597]: adjust time server 85.21.78.23 offset
> 0.004498
> sec
> [22:32:30] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
> 21 Sep 22:32:45 ntpdate[40599]: signal_no_reset: signal 14 had flags 40
> 21 Sep 22:32:49 ntpdate[40599]: adjust time server 85.21.78.23 offset
> -0.005016
> sec
>
> See, the offset differs much more (note the last try, it changed its sign)
> yet
> it's about the same value as on my cubieboard.
>


Can you apply following change to timer.c and try again?
Please also check load average using uptime.


Index: timer.c
===================================================================
--- timer.c (revision 271185)
+++ timer.c (working copy)
@@ -72,7 +72,7 @@
 #define TIMER_ENABLE (1<<0)
 #define TIMER_AUTORELOAD (1<<1)
 #define TIMER_OSC24M (1<<2) /* oscillator = 24mhz */
-#define TIMER_PRESCALAR (4<<4) /* prescalar = 16 */
+#define TIMER_PRESCALAR (0<<4) /* prescalar = 1 */

 #define SYS_TIMER_CLKSRC 24000000 /* clock source */

thanks,

Ganbold




>
> > BTW, time.nist.gov is not one server, it's a pool just like pool.ntp.org
> > (we run one of the time.nist.gov server installations out of our
> > building at $work).  I think it probably worked for you because of some
> > sort of dns caching effect, because you clearly kept getting the same
> > server each time.
> >
> > -- Ian
> --
> wbr, Maxim Filimonov
> che at bein.link
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>

From sbruno at ignoranthack.me  Mon Sep 22 06:38:05 2014
From: sbruno at ignoranthack.me (Sean Bruno)
Date: Sun, 21 Sep 2014 23:37:55 -0700
Subject: ARMv6 ports status
Message-ID: <1411367875.4191.13.camel@bruno>

I thought I'd actually subscribe here and post some status for your
entertainment.

http://chips.ysv.freebsd.org/index.html is the current host building
FreeBSD ARMv6 ports for Current in the cluster.  As you can see, it has
a good chunk of packages built already.

This machine is also acting as a pkg repo at the moment:
http://chips.ysv.freebsd.org/packages/11armv632-default/

Things like perl/python are useable and X is approaching the point where
we can start trying to use it on RPi and BBB architectures.

This is being accomplished via qemu-bsd-user and poudriere with support
for a cross architecture tool chain on AMD64 hosts.  Some of the
malfunctions with ports building are QEMU related (probably any that
show up as coredump).

Others are more interesting and I'm looking for patches or feedback on
the builds.

Big blockers at the moment:
   no working gcc port
   boost-libs
   mysql
   postgresql
   tex-luatex
    
But, I can review and commit any patches people have for ports to
resolve these issues.

Sean

p.s. blt was just fixed in ports/head.  I'll kick a ports update/build
when the current run is finished.


From che at bein.link  Mon Sep 22 16:20:48 2014
From: che at bein.link (Maxim V FIlimonov)
Date: Mon, 22 Sep 2014 20:20:36 +0400
Subject: ARMv6 ports status
In-Reply-To: <1411367875.4191.13.camel@bruno>
References: <1411367875.4191.13.camel@bruno>
Message-ID: <1477814.BUZ47FdRvh@quad>

On Sunday 21 September 2014 23:37:55 Sean Bruno wrote:
> I thought I'd actually subscribe here and post some status for your
> entertainment.
> 
> http://chips.ysv.freebsd.org/index.html is the current host building
> FreeBSD ARMv6 ports for Current in the cluster.  As you can see, it has
> a good chunk of packages built already.
> 
> This machine is also acting as a pkg repo at the moment:
> http://chips.ysv.freebsd.org/packages/11armv632-default/

Good to hear that again. But there's a problem: pkg doesn't see any packages 
in this repo. I add it to pkg's repo configs, run pkg update, it downloads the 
.txz files and says that 0 packages added and 0 packages found. 
-- 
wbr, Maxim Filimonov
che at bein.link

From sbruno at ignoranthack.me  Mon Sep 22 16:34:03 2014
From: sbruno at ignoranthack.me (Sean Bruno)
Date: Mon, 22 Sep 2014 09:34:01 -0700
Subject: ARMv6 ports status
In-Reply-To: <1477814.BUZ47FdRvh@quad>
References: <1411367875.4191.13.camel@bruno>  <1477814.BUZ47FdRvh@quad>
Message-ID: <1411403641.4191.17.camel@bruno>

On Mon, 2014-09-22 at 20:20 +0400, Maxim V FIlimonov wrote:
> On Sunday 21 September 2014 23:37:55 Sean Bruno wrote:
> > I thought I'd actually subscribe here and post some status for your
> > entertainment.
> > 
> > http://chips.ysv.freebsd.org/index.html is the current host building
> > FreeBSD ARMv6 ports for Current in the cluster.  As you can see, it has
> > a good chunk of packages built already.
> > 
> > This machine is also acting as a pkg repo at the moment:
> > http://chips.ysv.freebsd.org/packages/11armv632-default/
> 
> Good to hear that again. But there's a problem: pkg doesn't see any packages 
> in this repo. I add it to pkg's repo configs, run pkg update, it downloads the 
> .txz files and says that 0 packages added and 0 packages found. 


Hrm, confirmed.  Opened PR here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193840


From che at bein.link  Mon Sep 22 17:05:41 2014
From: che at bein.link (Maxim V FIlimonov)
Date: Mon, 22 Sep 2014 21:05:38 +0400
Subject: FreeBSD-11.0-CURRENT on ARM: performance and load average
In-Reply-To: <CAGtf9xNcjrfK4E8jDWhMgXeaF5c49HADgfHVTef_f8ZT-yjoMg@mail.gmail.com>
References: <7351653.A2UeEk9AA3@quad> <8990779.WPLHzDdnAo@quad>
 <CAGtf9xNcjrfK4E8jDWhMgXeaF5c49HADgfHVTef_f8ZT-yjoMg@mail.gmail.com>
Message-ID: <2629767.V12UkVKH9N@quad>

On Monday 22 September 2014 09:45:57 Ganbold Tsagaankhuu wrote:
> Max, Dmitry,
> 
> On Mon, Sep 22, 2014 at 2:33 AM, Maxim V FIlimonov <che at bein.link> wrote:
> > On Sunday 21 September 2014 07:56:01 Ian Lepore wrote:
> > > On Sun, 2014-09-21 at 13:06 +0400, Maxim V FIlimonov wrote:
> > > > root at cubie:~ # ntpdate time.nist.gov
> > > > 21 Sep 13:04:55 ntpdate[2236]: adjust time server 24.56.178.140 offset
> > > > -0.117727 sec
> > > > root at cubie:~ # ntpdate time.nist.gov
> > > > 21 Sep 13:04:57 ntpdate[2237]: adjust time server 24.56.178.140 offset
> > > > -0.117018 sec
> > > > root at cubie:~ # ntpdate time.nist.gov
> > > > 21 Sep 13:05:00 ntpdate[2238]: adjust time server 24.56.178.140 offset
> > > > -0.116026 sec
> > > > root at cubie:~ # ntpdate time.nist.gov
> > > > 21 Sep 13:05:08 ntpdate[2241]: adjust time server 24.56.178.140 offset
> > > > -0.111525 sec
> > > > root at cubie:~ # ntpdate time.nist.gov
> > > > 21 Sep 13:05:26 ntpdate[2242]: adjust time server 24.56.178.140 offset
> > > > -0.103121 sec
> > > > root at cubie:~ # ntpdate time.nist.gov
> > > > 21 Sep 13:05:34 ntpdate[2243]: adjust time server 24.56.178.140 offset
> > > > -0.099055 sec
> > > > 
> > > > So as you could notice, the offset doesn't change much.
> > > 
> > > No, quite to the contrary, the time is changing rapidly -- it moved
> > > about 19 milliseconds in 39 seconds, or roughly a millisecond every two
> > > seconds.  That's an error rate of 500 parts per million, which is huge.
> > > However, it's not off by a factor of 16, so that's a bit confusing.
> > 
> > Let me not agree with you. As you might have noticed, the time has the
> > same
> > offset no matter what exatc timeout I made before actually getting the
> > time
> > from the NTP pool. Here's another example of what I'm speaking about:
> > 
> > root at cubie:~ # ntpdate pool.ntp.org
> > 21 Sep 22:24:56 ntpdate[660]: step time server 85.21.78.23 offset
> > 7525.060549
> > sec
> > root at cubie:~ # ntpdate pool.ntp.org
> > 21 Sep 22:25:03 ntpdate[661]: adjust time server 95.213.132.250 offset
> > -0.014318 sec
> > root at cubie:~ # ntpdate pool.ntp.org
> > 21 Sep 22:25:07 ntpdate[662]: adjust time server 31.131.249.19 offset
> > -0.010051
> > sec
> > root at cubie:~ # ntpdate pool.ntp.org
> > 21 Sep 22:25:24 ntpdate[663]: adjust time server 95.213.132.250 offset
> > -0.005744 sec
> > 
> > You could notice that the offset changes a bit, and sometimes it can even
> > decrease.
> > Here's one more example: I ran ntpdate some times in a row, then waited
> > for
> > about a minute:
> > 
> > root at cubie:~ # ntpdate pool.ntp.org
> > 21 Sep 22:28:36 ntpdate[664]: adjust time server 95.213.132.250 offset
> > 0.004790
> > sec
> > root at cubie:~ # ntpdate pool.ntp.org
> > 21 Sep 22:28:41 ntpdate[665]: adjust time server 31.131.249.19 offset
> > 0.005558
> > sec
> > root at cubie:~ # ntpdate pool.ntp.org
> > 21 Sep 22:28:43 ntpdate[666]: adjust time server 31.131.249.19 offset
> > 0.003983
> > sec
> > root at cubie:~ # ntpdate pool.ntp.org
> > 21 Sep 22:28:45 ntpdate[667]: adjust time server 31.131.249.19 offset
> > -0.000497
> > sec
> > root at cubie:~ # ntpdate pool.ntp.org
> > 21 Sep 22:29:24 ntpdate[668]: adjust time server 31.131.249.19 offset
> > 0.003195
> > sec
> > 
> > If what I understood about what you said was right, the offset would
> > increase,
> > wouldn't it? This time it is approximately the same no matter what the
> > time
> > gap between two ntpdate's is.
> > 
> > Furthermore, here's what my PC says on ntpdate:
> > 
> > [22:32:07] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
> > 21 Sep 22:32:11 ntpdate[40593]: signal_no_reset: signal 14 had flags 40
> > 21 Sep 22:32:15 ntpdate[40593]: adjust time server 85.21.78.23 offset
> > 0.008892
> > sec
> > [22:32:15] 0 [che at quad:~]$
> > [22:32:15] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
> > 21 Sep 22:32:18 ntpdate[40595]: signal_no_reset: signal 14 had flags 40
> > 21 Sep 22:32:23 ntpdate[40595]: adjust time server 85.21.78.23 offset
> > 0.007959
> > sec
> > [22:32:23] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
> > 21 Sep 22:32:25 ntpdate[40597]: signal_no_reset: signal 14 had flags 40
> > 21 Sep 22:32:30 ntpdate[40597]: adjust time server 85.21.78.23 offset
> > 0.004498
> > sec
> > [22:32:30] 0 [che at quad:~]$ sudo ntpdate pool.ntp.org
> > 21 Sep 22:32:45 ntpdate[40599]: signal_no_reset: signal 14 had flags 40
> > 21 Sep 22:32:49 ntpdate[40599]: adjust time server 85.21.78.23 offset
> > -0.005016
> > sec
> > 
> > See, the offset differs much more (note the last try, it changed its sign)
> > yet
> > it's about the same value as on my cubieboard.
> 
> Can you apply following change to timer.c and try again?
> Please also check load average using uptime.
> 
> 

Here's what I got after applying the below patch:

root at cubie:~ # sysctl kern.eventtimer.periodic
kern.eventtimer.periodic: 0
root at cubie:~ # uptime 
 8:29PM  up 2 mins, 1 user, load averages: 0.52, 0.31, 0.13

Please note that I switched kern.eventtimer.periodic off beforehand.
I experimented a bit with uptime: it never showed me more than 0.2, and with 
ntpdate/date: the time isn't running faster than it should. So your patch 
really works which is great.

> Index: timer.c
> ===================================================================
> --- timer.c (revision 271185)
> +++ timer.c (working copy)
> @@ -72,7 +72,7 @@
>  #define TIMER_ENABLE (1<<0)
>  #define TIMER_AUTORELOAD (1<<1)
>  #define TIMER_OSC24M (1<<2) /* oscillator = 24mhz */
> -#define TIMER_PRESCALAR (4<<4) /* prescalar = 16 */
> +#define TIMER_PRESCALAR (0<<4) /* prescalar = 1 */
> 
>  #define SYS_TIMER_CLKSRC 24000000 /* clock source */
> 
> thanks,
> 
> Ganbold
> 
> > > BTW, time.nist.gov is not one server, it's a pool just like pool.ntp.org
> > > (we run one of the time.nist.gov server installations out of our
> > > building at $work).  I think it probably worked for you because of some
> > > sort of dns caching effect, because you clearly kept getting the same
> > > server each time.
> > > 
> > > -- Ian
> > 
> > --
> > wbr, Maxim Filimonov
> > che at bein.link
> > _______________________________________________
> > freebsd-arm at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
-- 
wbr, Maxim Filimonov
che at bein.link

From jczhang80 at gmail.com  Wed Sep 24 05:12:44 2014
From: jczhang80 at gmail.com (Jingcheng zhang)
Date: Wed, 24 Sep 2014 13:12:43 +0800
Subject: Does FreeBSD 10 supports ARM well?
Message-ID: <CABSuJbMMFz0PmBWzv8WdnuddQieVDE5qN5n_jSdsCRE=ozog7g@mail.gmail.com>

Hi all,

We have a storage system based on FreeBSD 10.  We want to run the system on
ARM platform.  We know that the FreeBSD support development is in
progress.   Could some guys help answer the following questions?
1)  Does FreeBSD 10 supports ARM?
2)  Are the disk and network adapters support ready for ARM?

Thanks very much!

From drayson at andrew.cmu.edu  Wed Sep 24 07:30:38 2014
From: drayson at andrew.cmu.edu (David Rayson)
Date: Wed, 24 Sep 2014 03:24:30 -0400
Subject: Jetson TK1 board support
Message-ID: <542271AE.6070807@andrew.cmu.edu>

Hi,

What other work would be useful to get this port working well?  I might 
be interested in working on improving it, but first I want to make sure 
I have a clear sense of what's been done so far (and how stable/not it 
is) and what still remains to be done.

--David

> Hi,
>
> I have a rather rough port of FreeBSD current on arm to Jetson TK1. I
> used Stephen Warren's tegra u-boot sources, which initialize and configure
> USB and PCIe.
>
> So SMP, USB and the onboard PCIe Ethernet adapter work.
>
> After Ian's changes to busdma_machdep-v6 (r269212) I had problems with
> cache coherency with the Ethernet adapter. Seems this is due to the aggressive
> L2 prefetcher of Cortex A15. Disabling L2 prefetch does help, as well as
> invalidating the cache a second time after the dma transfer. I'm not
> sure what the correct solution to this problem is. I wonder how
> other Cortex A15 platforms (exynos5) handle this.
>
> I will probably be able to do some cleanups and put patches on the web
> within a week.
>
> Regards
>
> Juergen
>
> Juergen Weiss      |Universitaet Mainz, Zentrum fuer Datenverarbeitung,
> weiss at uni-mainz.de  <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>  |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407
>
> >/  -----Original Message-----
> />/  From:owner-freebsd-arm at freebsd.org  <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>  [mailto:owner-freebsd-arm at freebsd.org  <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>] On Behalf Of
> />/  Ian Lepore
> />/  Sent: Sunday, September 21, 2014 3:44 PM
> />/  To: Lundberg, Johannes
> />/  Cc:freebsd-arm at freebsd.org  <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>
> />/  Subject: Re: Jetson TK1 board support
> />/  
> />/  On Sun, 2014-09-21 at 16:45 +0900, Lundberg, Johannes wrote:
> />/  > Great!
> />/  >
> />/  > What I've done so far is
> />/  >
> />/  > - build and patch (enable API) u-boot-nvidia on freebsd (i think i got it
> />/  > fromgit://nv-tegra.nvidia.com/3rdparty/u-boot.git,  the normal u-boot
> />/  > wouldn't work...)
> />/  > - flash u-boot-dtb-tegra.img onto the board's mmc using nvidia's flash tool
> />/  > on ubuntu
> />/  > - build an image using crochet and dd to sd card (so far I copied the
> />/  > beaglebone setup, just to get a ubldr and a kernel file)
> />/  >
> />/  >
> />/  > From u-boot I can see all devices. I load ubldr with
> />/  > fatload mmc 1:1 0x80200000 ubldr
> />/  > bootelf 0x80200000
> />/  >
> />/  > ubldr load fine but, from ubldr I can only see the mmc 0 and net devices.
> />/  > There's no sd card (mmc 1), and no ufs partition..
> />/  >
> />/  >
> />/  >
> />/  >
> />/  > --
> />/  > Johannes Lundberg
> />/  > BRILLIANTSERVICE CO., LTD.
> />/  >
> />/  > On Fri, Sep 19, 2014 at 8:25 PM, John Howie <john at thehowies.com  <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>> wrote:
> />/  >
> />/  > > Hi all,
> />/  > >
> />/  > > I am up for testing and supporting this board. I ordered and received
> />/  > > mine, but have not really had a chance to use it due to work to-date. The
> />/  > > good news is the next few months I will have bandwidth.
> />/  > >
> />/  > > Regards,
> />/  > >
> />/  > > John
> />/  > >
> />/  > >
> />/  > > On 9/19/14, 12:15 PM, "Lundberg, Johannes"
> />/  > > <johannes at brilliantservice.co.jp  <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>> wrote:
> />/  > >
> />/  > > >Hi
> />/  > > >
> />/  > > >I started working on adding the Jetson TK1 board to Crochet. Is there any
> />/  > > >work in progress on this?
> />/  > > >I guess there is quite a lot of work that has to been done to get full
> />/  > > >support for it in the kernel as well..
> />/  > > >
> />/  > > >Best regards
> />/  > > >--
> />/  > > >Johannes Lundberg
> />/  > > >
> />/  
> />/  You may have to change some u-boot options to support multiple mmc/sd
> />/  interfaces.  Look in the config header for CONFIG_SYS_MMC_MAX_DEVICE; if
> />/  it's not there you may need to add it.  For wandboard I also had to add
> />/  a freescale-specific one, CONFIG_SYS_FSL_USDHC_NUM, so there may be
> />/  something like that you need to find as well.
> />/  
> />/  -- Ian
> />/  
> />/  
> />/  _______________________________________________
> />/  freebsd-arm at freebsd.org  <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>  mailing list
> />/  http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> />/  To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org  <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>"/

From erichsfreebsdlist at alogt.com  Wed Sep 24 09:08:54 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Wed, 24 Sep 2014 17:08:41 +0800
Subject: Does FreeBSD 10 supports ARM well?
In-Reply-To: <CABSuJbMMFz0PmBWzv8WdnuddQieVDE5qN5n_jSdsCRE=ozog7g@mail.gmail.com>
References: <CABSuJbMMFz0PmBWzv8WdnuddQieVDE5qN5n_jSdsCRE=ozog7g@mail.gmail.com>
Message-ID: <20140924170841.1c78b8eb@X220.alogt.com>

Hi,

On Wed, 24 Sep 2014 13:12:43 +0800
Jingcheng zhang <jczhang80 at gmail.com> wrote:

> We have a storage system based on FreeBSD 10.  We want to run the
> system on ARM platform.  We know that the FreeBSD support development
> is in progress.   Could some guys help answer the following questions?
> 1)  Does FreeBSD 10 supports ARM?

it very much depends on the ARM platform. I run 11 on a Raspberry B+.
The port support is very much limited. Others run 10 and/or 11 on some
other platforms.

> 2)  Are the disk and network adapters support ready for ARM?

I do not think that support has reached amd64 levels.

Erich

From gdalmas at wanadoo.fr  Wed Sep 24 14:32:20 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Wed, 24 Sep 2014 16:32:16 +0200 (CEST)
Subject: kernel debugger on cubietruck
In-Reply-To: <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
 <584735728.12399.1411223474805.JavaMail.www@wwinf1p20>
 <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
Message-ID: <186864560.21340.1411569136778.JavaMail.www@wwinf1p16>

hello,

there is something I misunderstands. In compiling the version "10", I fall back on the error:

?

?


vm_fault(0xc0670860, 0, 1, 0) -> 1
Fatal kernel mode data abort: 'Translation Fault (S)'
trapframe: 0xc0695a00
FSR=00000005, FAR=00000000, spsr=a00001d3
r0 =00000000, r1 =c05c14c3, r2 =00000072, r3 =00000008
r4 =c3923000, r5 =c3923100, r6 =c3923138, r7 =00000000
r8 =c05c3f8d, r9 =c38ba780, r10=c0629340, r11=c0695a68
r12=00000000, ssp=c0695a50, slr=c0253338, pc =c041747c

[ thread pid 0 tid 100000 ]
Stopped at????? strcmp+0x4:???? ldrb??? r3, [r0]

With the "11", I had the same error, and commenting Driver "emac" had properly start cubietruck. yet, in the log, "freebsd" well recognized my hardware:

?

ehci0:  mem 0x1c14000-0x1c14fff irq 71 on simplebus0
usbus0: EHCI version 1.0
usbus0 on ehci0
ehci1:  mem 0x1c1c000-0x1c1cfff irq 72 on simplebus0
usbus1: EHCI version 1.0
usbus1 on ehci1
uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 33 on simplebus0
uart0: console (115200,n,8,1)
emac0:  mem 0x1c0b000-0x1c0bfff irq 87 on simplebus0
miibus0:  on emac0
rgephy0:  PHY 0 on miibus0

?

?

> Message du 20/09/14 16:35
> De : "Ganbold Tsagaankhuu" 
> A : "Gilles DALMAS" 
> Copie ? : 
> Objet : Re: kernel debugger on cubietruck
> 
>

>

>
On Sat, Sep 20, 2014 at 10:31 PM, Gilles DALMAS  wrote:
>

> no need to re make the kernel-toolchain ?
>



>
No just build kernel only.

>
Ganbold
?

> 
> 
> 
> 
>

> Message du 20/09/14 16:26
> > De : "Gilles DALMAS" 
> > A : "Ganbold Tsagaankhuu" 
> > Copie ? : "freebsd-arm at freebsd.org" 
> > Objet : Re: kernel debugger on cubietruck
> > 
> > i comment emac line from : # Ethernet device??? ??? loop device??? ??? ether device??? ??? mii device??? ??? smscphy #device ??? cpsw device??? ??? bpf device??? ??? emac # USB ethernet support, requires miibus device??? ??? miibus ? and re run the compilation ? ? ? no need to re created the sd card ? just the USB flash ? ? > Message du 20/09/14 16:09 > De : "Ganbold Tsagaankhuu" > A : "Gilles DALMAS" > Copie ? : "freebsd-arm at freebsd.org" > Objet : Re: kernel debugger on cubietruck > > > > On Sat, Sep 20, 2014 at 9:25 PM, Gilles DALMAS wrote: > I did not know much about debug kernel, but when I pass the trace command, I get: > > db> trace > Tracing pid 0 tid 100000 td 0xc08ba870 > db_trace_self() at db_trace_self > ???????? pc = 0xc04eba6c? lr = 0xc0232780 (db_hex2dec+0x4d8) > ???????? sp = 0xc08e5750? fp = 0xc08e5768 > ??????? r10 = 0xc08ba1c4 > db_hex2dec() at db_hex2dec+0x4d8 > ???????? pc = 0xc0232780? lr = 0xc02320f0 (db_command_loop+0x2fc) > ???????? sp = 0xc08e5770? fp = 0xc08e5810 > ???????? r4 = 0x00000000? r5 = 0x00000000 > ???????? r6 = 0x00000063 > db_command_loop() at db_command_loop+0x2fc > ???????? pc = 0xc02320f0? lr = 0xc0231e54 (db_command_loop+0x60) > ???????? sp = 0xc08e5818? fp = 0xc08e5828 > ???????? r4 = 0xc0528609? r5 = 0xc0540c1c > ???????? r6 = 0xc08ba1b0? r7 = 0xc08e5a48 > ???????? r8 = 0x00000001? r9 = 0xc05d2918 > ??????? r10 = 0xc0615aa4 > db_command_loop() at db_command_loop+0x60 > ???????? pc = 0xc0231e54? lr = 0xc023481c (X_db_symbol_values+0x250) > ???????? sp = 0xc08e5830? fp = 0xc08e5950 > ???????? r4 = 0x00000000? r5 = 0xc08ba1bc > ???????? r6 = 0xc0615ac8 > X_db_symbol_values() at X_db_symbol_values+0x250 > ???????? pc = 0xc023481c? lr = 0xc0352c88 (kdb_trap+0x15c) > ???????? sp = 0xc08e5958? fp = 0xc08e5978 > ???????? r4 = 0x00000000? r5 = 0x00000005 > ???????? r6 = 0xc0615ac8? r7 = 0xc08e5a48 > kdb_trap() at kdb_trap+0x15c > ???????? pc = 0xc0352c88? lr = 0xc050138c (data_abort_handler+0x680) > ???????? sp = 0xc08e5980? fp = 0xc08e5998 > ???????? r4 = 0xc08e5a48? r5 = 0x00000005 > ???????? r6 = 0x600001d3? r7 = 0x00000000 > ???????? r8 = 0x00000013? r9 = 0xc08e5a48 > ??????? r10 = 0x00000001 > data_abort_handler() at data_abort_handler+0x680 > ???????? pc = 0xc050138c? lr = 0xc0501134 (data_abort_handler+0x428) > ???????? sp = 0xc08e59a0? fp = 0xc08e5a40 > ???????? r4 = 0xc08e5eb0? r5 = 0xc08ba870 > ???????? r6 = 0xc08ba548? r7 = 0x00000005 > data_abort_handler() at data_abort_handler+0x428 > ???????? pc = 0xc0501134? lr = 0xc04ed754 (exception_exit) > ???????? sp = 0xc08e5a48? fp = 0xc08e5ab0 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 > exception_exit() at exception_exit > ???????? pc = 0xc04ed754? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > ???????? r0 = 0x00000000? r1 = 0xc0547c85 > ???????? r2 = 0x00000072? r3 = 0x00000008 > ???????? r4 = 0xc3b49f00? r5 = 0xc3b4a080 > ???????? r6 = 0xc3b4a0b8? r7 = 0x00000000 > ???????? r8 = 0xc056b038? r9 = 0xc3ae1700 > ??????? r10 = 0xc05d4930 r12 = 0x00000000 > strcmp() at strcmp+0x4 > ???????? pc = 0xc03d7604? lr = 0xc024e0f0 (mii_phy_flowstatus+0x2080) > ???????? sp = 0xc08e5a98? fp = 0xc08e5ab0 > Unwind failure (no registers changed) > > Please try without?emac?driver. MII in Cubietruck?could be different. > > Ganbold > > ? > > > ? > > > Message du 20/09/14 15:13 > > De : "Boris Astardzhiev" > > A : "Gilles DALMAS" > > Copie ? : freebsd-arm at freebsd.org > > Objet : Re: kernel debugger on cubietruck > > > > > > Hi, > > > As far as I see strcmp() is passed a NULL pointer, try issuing a backtrace to get the exact place of calling. > > > Regards > > On Sep 20, 2014 4:11 PM, "Gilles DALMAS"? wrote: > > hi, > > > > ? > > > > I would compile freebsd for it run on a cubietruck. For this I used the wiki page: https://wiki.freebsd.org/FreeBSD/arm/Cubieboard using option confifuration "CUBIEBOARD2." everything goes well, but starting on the "truck", I get this message: > > > > ? > > > > vm_fault(0xc08bab80, 0, 1, 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (S)' > > trapframe: 0xc08e5a48 > > FSR=00000005, FAR=00000000, spsr=a00001d3 > > r0 =00000000, r1 =c0547c85, r2 =00000072, r3 =00000008 > > r4 =c3b49f00, r5 =c3b4a080, r6 =c3b4a0b8, r7 =00000000 > > r8 =c056b038, r9 =c3ae1700, r10=c05d4930, r11=c08e5ab0 > > r12=00000000, ssp=c08e5a98, slr=c024e0f0, pc =c03d7604 > > > > [ thread pid 0 tid 100000 ] > > Stopped at????? strcmp+0x4:???? ldrb??? r3, [r0] > > > > > > > > where is the problem please ? > > > > _______________________________________________ > > freebsd-arm at freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > > _______________________________________________ > freebsd-arm at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org" > _______________________________________________ freebsd-arm at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"



>


From gdalmas at wanadoo.fr  Wed Sep 24 16:11:29 2014
From: gdalmas at wanadoo.fr (Gilles DALMAS)
Date: Wed, 24 Sep 2014 18:11:26 +0200 (CEST)
Subject: kernel debugger on cubietruck
In-Reply-To: <186864560.21340.1411569136778.JavaMail.www@wwinf1p16>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
 <584735728.12399.1411223474805.JavaMail.www@wwinf1p20>
 <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
 <186864560.21340.1411569136778.JavaMail.www@wwinf1p16>
Message-ID: <1669855321.26200.1411575086488.JavaMail.www@wwinf1p16>

Moreover, in "u-boot", it detects well the "emac" for ethernet.

?

U-Boot SPL 2013.07-07794-gc0f3b94 (Aug 15 2013 - 18:01:45)
Board: Cubieboard2
DRAM: 1024 MiB
CPU: 960000000Hz, AXI/AHB/APB: 3/2/2
SUNXI SD/MMC: 0


U-Boot 2013.07-07794-gc0f3b94 (Aug 15 2013 - 18:01:45) Allwinner Technology

CPU:?? Allwinner A20 (SUN7I)
Board: Cubieboard2
I2C:?? ready
DRAM:? 1 GiB
MMC:?? SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:??? serial
Out:?? serial
Err:?? serial
Net:?? emac



From ganbold at gmail.com  Wed Sep 24 16:24:57 2014
From: ganbold at gmail.com (Ganbold Tsagaankhuu)
Date: Thu, 25 Sep 2014 00:24:56 +0800
Subject: kernel debugger on cubietruck
In-Reply-To: <1669855321.26200.1411575086488.JavaMail.www@wwinf1p16>
References: <568188637.10901.1411218668061.JavaMail.www@wwinf1p20>
 <CAP=KkTwhRpJRW8jTLCjYRf55RLc-xSi+FCEBd5WHpU0hn-bUmQ@mail.gmail.com>
 <1886035707.11136.1411219513483.JavaMail.www@wwinf1p20>
 <CAGtf9xNnNavZLsSkTEpku187z7cCA+tgmXNODa3UQJZ4Kncqcg@mail.gmail.com>
 <284420224.12277.1411223197278.JavaMail.www@wwinf1p20>
 <584735728.12399.1411223474805.JavaMail.www@wwinf1p20>
 <CAGtf9xNRanWo1F_hY4KHWCWDUNfNn=bcq__qxT-i2YbJCgE+WA@mail.gmail.com>
 <186864560.21340.1411569136778.JavaMail.www@wwinf1p16>
 <1669855321.26200.1411575086488.JavaMail.www@wwinf1p16>
Message-ID: <CAGtf9xM8DTbsCkaYtKn8J8TG2Fv4o2Ss346+NgiH6nD-SsyXhQ@mail.gmail.com>

On Thu, Sep 25, 2014 at 12:11 AM, Gilles DALMAS <gdalmas at wanadoo.fr> wrote:

> Moreover, in "u-boot", it detects well the "emac" for ethernet.
>

As I understand A20 supports both EMAC and GMAC MAC device however it is
connected to different PHY depending from board.
Cubieboard2 has MII, Cubietruck has RGMI.

FYI: http://linux-sunxi.org/Ethernet#EMAC

Ganbold


>
>
> U-Boot SPL 2013.07-07794-gc0f3b94 (Aug 15 2013 - 18:01:45)
> Board: Cubieboard2
> DRAM: 1024 MiB
> CPU: 960000000Hz, AXI/AHB/APB: 3/2/2
> SUNXI SD/MMC: 0
>
>
> U-Boot 2013.07-07794-gc0f3b94 (Aug 15 2013 - 18:01:45) Allwinner Technology
>
> CPU:   Allwinner A20 (SUN7I)
> Board: Cubieboard2
> I2C:   ready
> DRAM:  1 GiB
> MMC:   SUNXI SD/MMC: 0
> *** Warning - bad CRC, using default environment
>
> In:    serial
> Out:   serial
> Err:   serial
> Net:   emac
>
>

From freebsd.asc at strcmp.org  Wed Sep 24 19:46:44 2014
From: freebsd.asc at strcmp.org (Andreas Schwarz)
Date: Wed, 24 Sep 2014 21:46:34 +0200 (CEST)
Subject: Does FreeBSD 10 supports ARM well?
In-Reply-To: <20140924170841.1c78b8eb@X220.alogt.com>
References: <CABSuJbMMFz0PmBWzv8WdnuddQieVDE5qN5n_jSdsCRE=ozog7g@mail.gmail.com>
 <20140924170841.1c78b8eb@X220.alogt.com>
Message-ID: <4516fc986aa.321cd7ce@mail.schwarzes.net>

On 24.09.14, Erich Dollansky wrote:

Hi,

> it very much depends on the ARM platform. I run 11 on a Raspberry B+.
> The port support is very much limited. Others run 10 and/or 11 on some
> other platforms.

Working with the ports (tree) is fine so far, there is a lack regarding the precompiled 
packages.

Regards,
Andreas


From werner at thieprojects.ch  Wed Sep 24 20:42:12 2014
From: werner at thieprojects.ch (Werner Thie)
Date: Wed, 24 Sep 2014 10:33:31 -1000
Subject: Does FreeBSD 10 supports ARM well?
In-Reply-To: <CABSuJbMMFz0PmBWzv8WdnuddQieVDE5qN5n_jSdsCRE=ozog7g@mail.gmail.com>
References: <CABSuJbMMFz0PmBWzv8WdnuddQieVDE5qN5n_jSdsCRE=ozog7g@mail.gmail.com>
Message-ID: <54232A9B.3000806@thieprojects.ch>

On 9/23/14 7:12 PM, Jingcheng zhang wrote:
> Hi all,
>
> We have a storage system based on FreeBSD 10.  We want to run the system on
> ARM platform.  We know that the FreeBSD support development is in
> progress.   Could some guys help answer the following questions?
> 1)  Does FreeBSD 10 supports ARM?
> 2)  Are the disk and network adapters support ready for ARM?

Really depends on the hardware, I've been running a BeagleBone White 
with FreeBSD 10 now for several months with an MQTT (mosquitto) Queue as 
part of a hierarchical queue setup. This system collects data with a 
bridging daemon from Tinkerforge nodes, which is subsequently pushed to 
the mosquitto queue. This setup is running as quiet and stable as you 
could wish for, boot and forget. This is of course very network centric, 
almost no disk involved besides logging.

Werner


From ticso at cicely7.cicely.de  Wed Sep 24 22:30:49 2014
From: ticso at cicely7.cicely.de (Bernd Walter)
Date: Thu, 25 Sep 2014 00:09:47 +0200
Subject: Does FreeBSD 10 supports ARM well?
In-Reply-To: <CABSuJbMMFz0PmBWzv8WdnuddQieVDE5qN5n_jSdsCRE=ozog7g@mail.gmail.com>
References: <CABSuJbMMFz0PmBWzv8WdnuddQieVDE5qN5n_jSdsCRE=ozog7g@mail.gmail.com>
Message-ID: <20140924220947.GF26563@cicely7.cicely.de>

On Wed, Sep 24, 2014 at 01:12:43PM +0800, Jingcheng zhang wrote:
> Hi all,
> 
> We have a storage system based on FreeBSD 10.  We want to run the system on
> ARM platform.  We know that the FreeBSD support development is in
> progress.   Could some guys help answer the following questions?
> 1)  Does FreeBSD 10 supports ARM?
> 2)  Are the disk and network adapters support ready for ARM?

Well - it really depends on your requirements and system.
ARM systems are very different from each other - there is no single answer.
Same goes for disk and network adapters - they are very different too,
plus you need a board which supports adding adapters.

It is very possible to run FreeBSD ARM with long uptime.
This is a self build board based on Atmel AT91RM9200:
uname -[51]beaver.cicely.de# uname -a
FreeBSD beaver.cicely.de 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Nov 22 07:52:33 CET 2009     ticso at beaver.cicely.de:/mnt2/arm-2009-04-17/head/sys/arm/compile/BEAVER  arm
[52]beaver.cicely.de# uptime
11:57PM  up 1370 days,  2:07, 1 user, load averages: 0.33, 0.14, 0.04

A more modern design with a Wandboard Quad using the Freescale iMX6:
[304]wb1# uname -a
FreeBSD wb1.cicely.de 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271289M: Tue Sep  9 00:26:36 CEST 2014     ticso at cicely1.cicely.de:/root/crochet-freebsd/work/obj/arm.armv6/home/builder/arm-build/head/sys/IMX6  arm
[305]wb1# cat /
[305]wb1# uptime
 8:55PM  up 13 days, 10:16, 1 user, load averages: 0.00, 0.00, 0.00

About disk and network adapters - hard to tell, because most ARM boards
are SOC without slots to add anything and most people don't use cards.
USB usually works fine - with all the pros and cons of USB.
Usually the most popular adapters should work if the board has a supported
Slot system.
The iMX6 for example has single port PCI express and single port SATA.
I never tried the SATA and most baords don't have a PCIe slot.
I do own a Fairy board carrier for the Wandboard modules, which has a
mini PCIe slot, but I don't own a card.
But in any case - a different SOC and the iMX6 answers are useless.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

From erichsfreebsdlist at alogt.com  Wed Sep 24 23:41:34 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Thu, 25 Sep 2014 07:41:26 +0800
Subject: Does FreeBSD 10 supports ARM well?
In-Reply-To: <4516fc986aa.321cd7ce@mail.schwarzes.net>
References: <CABSuJbMMFz0PmBWzv8WdnuddQieVDE5qN5n_jSdsCRE=ozog7g@mail.gmail.com>
 <20140924170841.1c78b8eb@X220.alogt.com>
 <4516fc986aa.321cd7ce@mail.schwarzes.net>
Message-ID: <20140925074126.378d5f25@X220.alogt.com>

Hi,

On Wed, 24 Sep 2014 21:46:34 +0200 (CEST)
Andreas Schwarz <freebsd.asc at strcmp.org> wrote:

> On 24.09.14, Erich Dollansky wrote:
> 
> Hi,
> 
> > it very much depends on the ARM platform. I run 11 on a Raspberry
> > B+. The port support is very much limited. Others run 10 and/or 11
> > on some other platforms.
> 
> Working with the ports (tree) is fine so far, there is a lack
> regarding the precompiled packages.
> 
could you compile xterm?

Erich

From freebsd.asc at strcmp.org  Thu Sep 25 00:25:17 2014
From: freebsd.asc at strcmp.org (Andreas Schwarz)
Date: Thu, 25 Sep 2014 02:25:10 +0200 (CEST)
Subject: Does FreeBSD 10 supports ARM well?
In-Reply-To: <20140925074126.378d5f25@X220.alogt.com>
References: <CABSuJbMMFz0PmBWzv8WdnuddQieVDE5qN5n_jSdsCRE=ozog7g@mail.gmail.com>
 <20140924170841.1c78b8eb@X220.alogt.com>
 <4516fc986aa.321cd7ce@mail.schwarzes.net>
 <20140925074126.378d5f25@X220.alogt.com>
Message-ID: <45173dfc20a.f7f8301@mail.schwarzes.net>

On 25.09.14, Erich Dollansky wrote:

Hi Erich,

>> > it very much depends on the ARM platform. I run 11 on a Raspberry
>> > B+. The port support is very much limited. Others run 10 and/or 11
>> > on some other platforms.
>> 
>> Working with the ports (tree) is fine so far, there is a lack
>> regarding the precompiled packages.
>> 
> could you compile xterm?

Don't know. I'm not using the X environment with my RPIs. Maybe there are still problems
at some places, but my personal experience is good, no problems anymore. In previous 
times I was forced to keep gcc to build some of the ports.

Regards,
Andreas


From erichsfreebsdlist at alogt.com  Thu Sep 25 05:02:50 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Thu, 25 Sep 2014 13:02:43 +0800
Subject: Does FreeBSD 10 supports ARM well?
In-Reply-To: <45173dfc20a.f7f8301@mail.schwarzes.net>
References: <CABSuJbMMFz0PmBWzv8WdnuddQieVDE5qN5n_jSdsCRE=ozog7g@mail.gmail.com>
 <20140924170841.1c78b8eb@X220.alogt.com>
 <4516fc986aa.321cd7ce@mail.schwarzes.net>
 <20140925074126.378d5f25@X220.alogt.com>
 <45173dfc20a.f7f8301@mail.schwarzes.net>
Message-ID: <20140925130243.0f250448@X220.alogt.com>

Hi,

On Thu, 25 Sep 2014 02:25:10 +0200 (CEST)
Andreas Schwarz <freebsd.asc at strcmp.org> wrote:

> On 25.09.14, Erich Dollansky wrote:
> 
> Hi Erich,
> 
> >> > it very much depends on the ARM platform. I run 11 on a Raspberry
> >> > B+. The port support is very much limited. Others run 10 and/or
> >> > 11 on some other platforms.
> >> 
> >> Working with the ports (tree) is fine so far, there is a lack
> >> regarding the precompiled packages.
> >> 
> > could you compile xterm?
> 
> Don't know. I'm not using the X environment with my RPIs. Maybe there
> are still problems at some places, but my personal experience is
> good, no problems anymore. In previous times I was forced to keep gcc
> to build some of the ports.
> 
you seem to be lucky then.

Erich

From mattia.rossi.mailinglists at gmail.com  Fri Sep 26 12:19:13 2014
From: mattia.rossi.mailinglists at gmail.com (Mattia Rossi)
Date: Fri, 26 Sep 2014 14:19:08 +0200
Subject: Random Kernel Panic on Dreamplug (FS related)
Message-ID: <542559BC.7090100@gmail.com>

This might be part of the weird FFS issues the Dreamplug has and no-one 
knows why they're happening.

The panic occurred while running nsd-control reload (which should simply 
re-read a config file from disk). I was previously editing files without 
issues.

Result is the following:

vm_fault(0xc10a0000, d0238000, 2, 0) -> 2
Fatal kernel mode data abort: 'Permission Fault (P)'
trapframe: 0xde019898
FSR=0000000f, FAR=d0238120, spsr=20000013
r0 =d0238120, r1 =00000e60, r2 =00000000, r3 =00000000
r4 =00000120, r5 =00000000, r6 =c3f3f6c0, r7 =00001000
r8 =c443e880, r9 =00000000, r10=c3d69000, r11=de019a20
r12=d0238120, ssp=de0198e8, slr=c0d53828, pc =c0de521c

[ thread pid 21116 tid 100073 ]
Stopped at      memset+0x48:    undge   0xa0cc20f8
db>
db> bt
Tracing pid 21116 tid 100073 td 0xc3e97000
db_trace_self() at db_trace_self
          pc = 0xc0dd5418  lr = 0xc094f8a8 (db_hex2dec+0x490)
          sp = 0xde0195a0  fp = 0xde0195b8
         r10 = 0xc0f5e8c8
db_hex2dec() at db_hex2dec+0x490
          pc = 0xc094f8a8  lr = 0xc094f260 (db_command_loop+0x300)
          sp = 0xde0195c0  fp = 0xde019660
          r4 = 0x00000000  r5 = 0x00000000
          r6 = 0x00000000
db_command_loop() at db_command_loop+0x300
          pc = 0xc094f260  lr = 0xc094efb0 (db_command_loop+0x50)
          sp = 0xde019668  fp = 0xde019678
          r4 = 0xc0e2dfe4  r5 = 0xc0e4402e
          r6 = 0xc0f5e8b4  r7 = 0xc0ef62b8
          r8 = 0xc0f52754  r9 = 0xc0f52750
         r10 = 0xc3e97000
db_command_loop() at db_command_loop+0x50
          pc = 0xc094efb0  lr = 0xc09519ec (X_db_symbol_values+0x250)
          sp = 0xde019680  fp = 0xde0197a0
          r4 = 0x00000000  r5 = 0xc0f5e8c0
          r6 = 0xc0f52778
X_db_symbol_values() at X_db_symbol_values+0x250
          pc = 0xc09519ec  lr = 0xc0b37b08 (kdb_trap+0xc4)
          sp = 0xde0197a8  fp = 0xde0197c8
          r4 = 0x00000000  r5 = 0x0000000f
          r6 = 0xc0f52778  r7 = 0xc0ef62b8
kdb_trap() at kdb_trap+0xc4
          pc = 0xc0b37b08  lr = 0xc0de7c60 (data_abort_handler+0x7f8)
          sp = 0xde0197d0  fp = 0xde0197e8
          r4 = 0xde019898  r5 = 0x0000000f
          r6 = 0x600000d3  r7 = 0xd0238120
          r8 = 0x00000000  r9 = 0xc0f648d4
         r10 = 0xc3e97000
data_abort_handler() at data_abort_handler+0x7f8
          pc = 0xc0de7c60  lr = 0xc0de7a28 (data_abort_handler+0x5c0)
          sp = 0xde0197f0  fp = 0xde019890
          r4 = 0xc10a0000  r5 = 0x00000013
          r6 = 0xde019eb0  r7 = 0x00000002
data_abort_handler() at data_abort_handler+0x5c0
          pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
          sp = 0xde019898  fp = 0xde019a20
          r4 = 0xffffffff  r5 = 0xffff1004
          r6 = 0xc3f3f6c0  r7 = 0x00001000
          r8 = 0xc443e880  r9 = 0x00000000
         r10 = 0xc3d69000
exception_exit() at exception_exit
          pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
          sp = 0xde0198e8  fp = 0xde019a20
          r0 = 0xd0238120  r1 = 0x00000e60
          r2 = 0x00000000  r3 = 0x00000000
          r4 = 0x00000120  r5 = 0x00000000
          r6 = 0xc3f3f6c0  r7 = 0x00001000
          r8 = 0xc443e880  r9 = 0x00000000
         r10 = 0xc3d69000 r12 = 0xd0238120
memset() at memset+0x48
          pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
          sp = 0xde0198e8  fp = 0xde019a20
Unwind failure (no registers changed)

The sad thing is, that with fsck broken for the dreamplug, I have to 
re-format the disk, reinstall everything and recreate the config files 
which I didn't manage to copy to a safe place beforehand :-(

Before I do that I'll leave the system in debugging mode for a few days, 
in case someone can help and needs some more information.

Cheers,

Mat

From andrew at fubar.geek.nz  Fri Sep 26 17:38:05 2014
From: andrew at fubar.geek.nz (Andrew Turner)
Date: Fri, 26 Sep 2014 18:37:45 +0100
Subject: ARMv6 ports status
In-Reply-To: <1411367875.4191.13.camel@bruno>
References: <1411367875.4191.13.camel@bruno>
Message-ID: <20140926183745.45214cb3@bender.lan>

I've been looking at some of the issues Sean found.

On Sun, 21 Sep 2014 23:37:55 -0700
Sean Bruno <sbruno at ignoranthack.me> wrote:
... 
> Big blockers at the moment:
>    no working gcc port

There is a patch to be tested for this at [1].

>    boost-libs

A fix for this has now been committed.

>    mysql

I have an idea on why this is failing, but would need to look into it
more.

>    postgresql

Are you able to get a copy of config.log for this? There is a segfault
when it's looking at thread related functions.

>    tex-luatex

This needs an update to libc to add missing Run-time ABI functions. I'll
have a look at it.

Andrew

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193947

From weiss at uni-mainz.de  Fri Sep 26 19:59:22 2014
From: weiss at uni-mainz.de (=?iso-8859-1?Q?Wei=DF=2C__Dr=2E_J=FCrgen?=)
Date: Fri, 26 Sep 2014 19:59:16 +0000
Subject: Jetson TK1 board support
In-Reply-To: <fd18f77d7e6d4de4b1a26aece9e3956b@e15be-02.zdv.Uni-Mainz.DE>
References: <CAASDrVkKEPUeoQqfo0_O9XpCB7Tdqgjs_VgjM9UeqWMVKt5+TQ@mail.gmail.com>
 <D041D0CA.4C994%john@thehowies.com>
 <CAASDrVkY3uSZUPV7r0LrzfxPhLsMvvLN5=eg9zd7pgKEisVifw@mail.gmail.com>
 <1411307019.66615.158.camel@revolution.hippie.lan>
 <fd18f77d7e6d4de4b1a26aece9e3956b@e15be-02.zdv.Uni-Mainz.DE>
Message-ID: <4467b9ec5ab64d25b6fde5ed9615bcf4@e15be-02.zdv.Uni-Mainz.DE>

Hi,

I have collected the patches to run FreeBSD on Jetson TK1
in the following archive:

http://www.staff.uni-mainz.de/weiss/jetson-tk1.tgz

Part of it is not pretty, but the system is able to
do a buildworld with -j6 and src and obj over nfs
without problems. I think it is at least a starting
point for further work.

Regards

Juergen 

Juergen Weiss      |Universitaet Mainz, Zentrum fuer Datenverarbeitung,
weiss at uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407

> -----Original Message-----
> From: owner-freebsd-arm at freebsd.org [mailto:owner-freebsd-arm at freebsd.org] On Behalf Of
> Wei?, Dr. J?rgen
> Sent: Sunday, September 21, 2014 4:30 PM
> To: 'Ian Lepore'; Lundberg, Johannes
> Cc: freebsd-arm at freebsd.org
> Subject: RE: Jetson TK1 board support
> 
> Hi,
> 
> I have a rather rough port of FreeBSD current on arm to Jetson TK1. I
> used Stephen Warren's tegra u-boot sources, which initialize and configure
> USB and PCIe.
> 
> So SMP, USB and the onboard PCIe Ethernet adapter work.
> 
> After Ian's changes to busdma_machdep-v6 (r269212) I had problems with
> cache coherency with the Ethernet adapter. Seems this is due to the aggressive
> L2 prefetcher of Cortex A15. Disabling L2 prefetch does help, as well as
> invalidating the cache a second time after the dma transfer. I'm not
> sure what the correct solution to this problem is. I wonder how
> other Cortex A15 platforms (exynos5) handle this.
> 
> I will probably be able to do some cleanups and put patches on the web
> within a week.
> 
> Regards
> 
> Juergen
> 
> Juergen Weiss      |Universitaet Mainz, Zentrum fuer Datenverarbeitung,
> weiss at uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407
> 
> > -----Original Message-----
> > From: owner-freebsd-arm at freebsd.org [mailto:owner-freebsd-arm at freebsd.org] On Behalf Of
> > Ian Lepore
> > Sent: Sunday, September 21, 2014 3:44 PM
> > To: Lundberg, Johannes
> > Cc: freebsd-arm at freebsd.org
> > Subject: Re: Jetson TK1 board support
> >
> > On Sun, 2014-09-21 at 16:45 +0900, Lundberg, Johannes wrote:
> > > Great!
> > >
> > > What I've done so far is
> > >
> > > - build and patch (enable API) u-boot-nvidia on freebsd (i think i got it
> > > from git://nv-tegra.nvidia.com/3rdparty/u-boot.git, the normal u-boot
> > > wouldn't work...)
> > > - flash u-boot-dtb-tegra.img onto the board's mmc using nvidia's flash tool
> > > on ubuntu
> > > - build an image using crochet and dd to sd card (so far I copied the
> > > beaglebone setup, just to get a ubldr and a kernel file)
> > >
> > >
> > > From u-boot I can see all devices. I load ubldr with
> > > fatload mmc 1:1 0x80200000 ubldr
> > > bootelf 0x80200000
> > >
> > > ubldr load fine but, from ubldr I can only see the mmc 0 and net devices.
> > > There's no sd card (mmc 1), and no ufs partition..
> > >
> > >
> > >
> > >
> > > --
> > > Johannes Lundberg
> > > BRILLIANTSERVICE CO., LTD.
> > >
> > > On Fri, Sep 19, 2014 at 8:25 PM, John Howie <john at thehowies.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > I am up for testing and supporting this board. I ordered and received
> > > > mine, but have not really had a chance to use it due to work to-date. The
> > > > good news is the next few months I will have bandwidth.
> > > >
> > > > Regards,
> > > >
> > > > John
> > > >
> > > >
> > > > On 9/19/14, 12:15 PM, "Lundberg, Johannes"
> > > > <johannes at brilliantservice.co.jp> wrote:
> > > >
> > > > >Hi
> > > > >
> > > > >I started working on adding the Jetson TK1 board to Crochet. Is there any
> > > > >work in progress on this?
> > > > >I guess there is quite a lot of work that has to been done to get full
> > > > >support for it in the kernel as well..
> > > > >
> > > > >Best regards
> > > > >--
> > > > >Johannes Lundberg
> > > > >
> >
> > You may have to change some u-boot options to support multiple mmc/sd
> > interfaces.  Look in the config header for CONFIG_SYS_MMC_MAX_DEVICE; if
> > it's not there you may need to add it.  For wandboard I also had to add
> > a freescale-specific one, CONFIG_SYS_FSL_USDHC_NUM, so there may be
> > something like that you need to find as well.
> >
> > -- Ian
> >
> >
> > _______________________________________________
> > freebsd-arm at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

From weiss at uni-mainz.de  Fri Sep 26 20:40:41 2014
From: weiss at uni-mainz.de (=?iso-8859-1?Q?Wei=DF=2C__Dr=2E_J=FCrgen?=)
Date: Fri, 26 Sep 2014 20:39:52 +0000
Subject: Jetson TK1 board support
In-Reply-To: <542271AE.6070807@andrew.cmu.edu>
References: <542271AE.6070807@andrew.cmu.edu>
Message-ID: <2c451765bffb43e8b9dab56927bb351a@e15be-02.zdv.Uni-Mainz.DE>

Hi,

sorry, I did not have any time during the week.

I just sent a mail to the list with a link to my changes.

Only serial, USB2 and PCIe/Ethernet hardware is working - so no
SATA.

The drivers rely on u-boot to initialize the hardware. While this
is ok for pinmux, other initializations should be done by the
drivers.

The interrupt handling for PCIe is rather ad hoc. The interrupt
routing should honor the FDT description.

The Tegra platform has a GIC with extensions for interrupt
routing. I just made a copy of the GIC code end extended it
in a few cases. There should probably be a mechanism to do
this without duplicating code.

I changed some non tegra files to get FreeBSD running on the
hardware. There should be better solutions, which can be merged
back to the FreeBSD source tree. For example the problem
with cache coherency due to aggressive L2 prefetch awaits
a real solution.

There is no code to change the cpu clock yet.

There is no support for SDHCI or EMMC.

So I would consider this a first step, which allows to do
native development on the platform. 

Besides that, the kernel seems to be quite stable - at least with
the compiles I did.

Regards

Juergen

Juergen Weiss      |Universitaet Mainz, Zentrum fuer Datenverarbeitung,
weiss at uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407


> -----Original Message-----
> From: owner-freebsd-arm at freebsd.org [mailto:owner-freebsd-arm at freebsd.org] On Behalf Of
> David Rayson
> Sent: Wednesday, September 24, 2014 9:25 AM
> To: freebsd-arm at freebsd.org
> Subject: Re: Jetson TK1 board support
> 
> Hi,
> 
> What other work would be useful to get this port working well?  I might
> be interested in working on improving it, but first I want to make sure
> I have a clear sense of what's been done so far (and how stable/not it
> is) and what still remains to be done.
> 
> --David
> 
> > Hi,
> >
> > I have a rather rough port of FreeBSD current on arm to Jetson TK1. I
> > used Stephen Warren's tegra u-boot sources, which initialize and configure
> > USB and PCIe.
> >
> > So SMP, USB and the onboard PCIe Ethernet adapter work.
> >
> > After Ian's changes to busdma_machdep-v6 (r269212) I had problems with
> > cache coherency with the Ethernet adapter. Seems this is due to the aggressive
> > L2 prefetcher of Cortex A15. Disabling L2 prefetch does help, as well as
> > invalidating the cache a second time after the dma transfer. I'm not
> > sure what the correct solution to this problem is. I wonder how
> > other Cortex A15 platforms (exynos5) handle this.
> >
> > I will probably be able to do some cleanups and put patches on the web
> > within a week.
> >
> > Regards
> >
> > Juergen
> >
> > Juergen Weiss      |Universitaet Mainz, Zentrum fuer Datenverarbeitung,
> > weiss at uni-mainz.de  <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>  |55099
> Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407
> >
> > >/  -----Original Message-----
> > />/  From:owner-freebsd-arm at freebsd.org
> <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>  [mailto:owner-freebsd-arm at
> freebsd.org  <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>] On Behalf Of
> > />/  Ian Lepore
> > />/  Sent: Sunday, September 21, 2014 3:44 PM
> > />/  To: Lundberg, Johannes
> > />/  Cc:freebsd-arm at freebsd.org  <http://lists.freebsd.org/mailman/listinfo/freebsd-
> arm>
> > />/  Subject: Re: Jetson TK1 board support
> > />/
> > />/  On Sun, 2014-09-21 at 16:45 +0900, Lundberg, Johannes wrote:
> > />/  > Great!
> > />/  >
> > />/  > What I've done so far is
> > />/  >
> > />/  > - build and patch (enable API) u-boot-nvidia on freebsd (i think i got it
> > />/  > fromgit://nv-tegra.nvidia.com/3rdparty/u-boot.git,  the normal u-boot
> > />/  > wouldn't work...)
> > />/  > - flash u-boot-dtb-tegra.img onto the board's mmc using nvidia's flash tool
> > />/  > on ubuntu
> > />/  > - build an image using crochet and dd to sd card (so far I copied the
> > />/  > beaglebone setup, just to get a ubldr and a kernel file)
> > />/  >
> > />/  >
> > />/  > From u-boot I can see all devices. I load ubldr with
> > />/  > fatload mmc 1:1 0x80200000 ubldr
> > />/  > bootelf 0x80200000
> > />/  >
> > />/  > ubldr load fine but, from ubldr I can only see the mmc 0 and net devices.
> > />/  > There's no sd card (mmc 1), and no ufs partition..
> > />/  >
> > />/  >
> > />/  >
> > />/  >
> > />/  > --
> > />/  > Johannes Lundberg
> > />/  > BRILLIANTSERVICE CO., LTD.
> > />/  >
> > />/  > On Fri, Sep 19, 2014 at 8:25 PM, John Howie <john at thehowies.com
> <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>> wrote:
> > />/  >
> > />/  > > Hi all,
> > />/  > >
> > />/  > > I am up for testing and supporting this board. I ordered and received
> > />/  > > mine, but have not really had a chance to use it due to work to-date. The
> > />/  > > good news is the next few months I will have bandwidth.
> > />/  > >
> > />/  > > Regards,
> > />/  > >
> > />/  > > John
> > />/  > >
> > />/  > >
> > />/  > > On 9/19/14, 12:15 PM, "Lundberg, Johannes"
> > />/  > > <johannes at brilliantservice.co.jp
> <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>> wrote:
> > />/  > >
> > />/  > > >Hi
> > />/  > > >
> > />/  > > >I started working on adding the Jetson TK1 board to Crochet. Is there any
> > />/  > > >work in progress on this?
> > />/  > > >I guess there is quite a lot of work that has to been done to get full
> > />/  > > >support for it in the kernel as well..
> > />/  > > >
> > />/  > > >Best regards
> > />/  > > >--
> > />/  > > >Johannes Lundberg
> > />/  > > >
> > />/
> > />/  You may have to change some u-boot options to support multiple mmc/sd
> > />/  interfaces.  Look in the config header for CONFIG_SYS_MMC_MAX_DEVICE; if
> > />/  it's not there you may need to add it.  For wandboard I also had to add
> > />/  a freescale-specific one, CONFIG_SYS_FSL_USDHC_NUM, so there may be
> > />/  something like that you need to find as well.
> > />/
> > />/  -- Ian
> > />/
> > />/
> > />/  _______________________________________________
> > />/  freebsd-arm at freebsd.org  <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>
> mailing list
> > />/  http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > />/  To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org
> <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>"/
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

From russ.haley at gmail.com  Sat Sep 27 05:38:41 2014
From: russ.haley at gmail.com (Russell Haley)
Date: Fri, 26 Sep 2014 22:38:40 -0700
Subject: Digi CCWMX53
Message-ID: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>

Hello,

I am trying to build for a DIgi CCWMX53 and was actually able to get a
kernel to build (holy cow I did it!!!) but I have failed to get it to boot.
I'll outline my steps below but I am also seeking answers for the following
questions:

1) Can anyone give me the correct u-boot enviroment variables or reference
to the u-boot process to boot the completed freebsd kernel. Specifically on
a CCWMX53 if possible, but I have linux references to port from. Where
would I look for an example?

2) Do I need to create a cross compiler? Reference 1 says yes, reference
two says no. Help!

Ref.1 Build  a cross compiler
https://wiki.freebsd.org/FreeBSD/arm/ArndaleBoard

Ref 2. No cross compiler/ make toolchain
https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD


Okay this is my process. It is performed in a 9.1-RELEASE jail within a
PC-BSD 10 VM with 4 GB ram and 4 cores.

svn checkout https://svn0.us-west.FreeBSD.org/base/head /usr/src

cd /usr/src

make TARGET=arm TARGET_ARCH=arm -j10 buildworld

make TARGET=arm TARGET_ARCH=arm KERNCONF=DIGI-CCWMX53 buildkernel

# never got to this due to documented error in head release that I had.
make TARGET=arm TARGET_ARCH=arm installworld

Copy to sd card

#To Wipe Disk
sudo dd if=/dev/zero of=/dev/da1 bs=512 count=1 && sync && sync


#u-boot image From CCWMX53 Starter Kit
sudo dd if=u-boot-ccwmx53js.bin of=/dev/da1 bs=512 && sync && sync

# lost the path from the build output that I got the kernel.bin file from.
I have since deleted that jail
sudo dd if=kernel.bin of=/dev/da1 bs=512 seek=2048 && sync && sync


Many thanks and this has been an awesome ride. A shout out to Ray whos
Raysblog got me started and Rui Paulo for starting the CCWMX53 port. My
ultimate goal is to also learn about Mer and create a BSD licensed phone OS
(PhoneBSD anyone?). I have a OnePlus I'm working to port to Sailfish right
now too.

Thanks,

Dinsdale

From imp at bsdimp.com  Sat Sep 27 05:53:11 2014
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 26 Sep 2014 22:47:34 -0700
Subject: Digi CCWMX53
In-Reply-To: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
Message-ID: <58369FDF-3D31-4FDB-9063-CA69E4E7E918@bsdimp.com>

You might try armv6 for TARGET_ARCH.

Warner

On Sep 26, 2014, at 10:38 PM, Russell Haley <russ.haley at gmail.com> wrote:

> Hello,
> 
> I am trying to build for a DIgi CCWMX53 and was actually able to get a
> kernel to build (holy cow I did it!!!) but I have failed to get it to boot.
> I'll outline my steps below but I am also seeking answers for the following
> questions:
> 
> 1) Can anyone give me the correct u-boot enviroment variables or reference
> to the u-boot process to boot the completed freebsd kernel. Specifically on
> a CCWMX53 if possible, but I have linux references to port from. Where
> would I look for an example?
> 
> 2) Do I need to create a cross compiler? Reference 1 says yes, reference
> two says no. Help!
> 
> Ref.1 Build  a cross compiler
> https://wiki.freebsd.org/FreeBSD/arm/ArndaleBoard
> 
> Ref 2. No cross compiler/ make toolchain
> https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD
> 
> 
> Okay this is my process. It is performed in a 9.1-RELEASE jail within a
> PC-BSD 10 VM with 4 GB ram and 4 cores.
> 
> svn checkout https://svn0.us-west.FreeBSD.org/base/head /usr/src
> 
> cd /usr/src
> 
> make TARGET=arm TARGET_ARCH=arm -j10 buildworld
> 
> make TARGET=arm TARGET_ARCH=arm KERNCONF=DIGI-CCWMX53 buildkernel
> 
> # never got to this due to documented error in head release that I had.
> make TARGET=arm TARGET_ARCH=arm installworld
> 
> Copy to sd card
> 
> #To Wipe Disk
> sudo dd if=/dev/zero of=/dev/da1 bs=512 count=1 && sync && sync
> 
> 
> #u-boot image From CCWMX53 Starter Kit
> sudo dd if=u-boot-ccwmx53js.bin of=/dev/da1 bs=512 && sync && sync
> 
> # lost the path from the build output that I got the kernel.bin file from.
> I have since deleted that jail
> sudo dd if=kernel.bin of=/dev/da1 bs=512 seek=2048 && sync && sync
> 
> 
> Many thanks and this has been an awesome ride. A shout out to Ray whos
> Raysblog got me started and Rui Paulo for starting the CCWMX53 port. My
> ultimate goal is to also learn about Mer and create a BSD licensed phone OS
> (PhoneBSD anyone?). I have a OnePlus I'm working to port to Sailfish right
> now too.
> 
> Thanks,
> 
> Dinsdale
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140926/84bef918/attachment.sig>

From rpaulo at me.com  Sat Sep 27 05:57:22 2014
From: rpaulo at me.com (Rui Paulo)
Date: Fri, 26 Sep 2014 22:56:48 -0700
Subject: Digi CCWMX53
In-Reply-To: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
Message-ID: <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>

Hi,

> On Sep 26, 2014, at 22:38, Russell Haley <russ.haley at gmail.com> wrote:
> 
> Hello,
> 
> I am trying to build for a DIgi CCWMX53 and was actually able to get a
> kernel to build (holy cow I did it!!!) but I have failed to get it to boot.
> I'll outline my steps below but I am also seeking answers for the following
> questions:
> 
> 1) Can anyone give me the correct u-boot enviroment variables or reference
> to the u-boot process to boot the completed freebsd kernel. Specifically on
> a CCWMX53 if possible, but I have linux references to port from. Where
> would I look for an example?

This is my setup:

https://wiki.freebsd.org/Digi-CCWMX53

I boot from the network because we don't support the MTD flash layout yet.  We can put a kernel in flash, but the kernel won't be able to read the MTD partition layout and we can't boot rootfs from there.  You can use a USB stick.

If you want to build U-Boot from source on FreeBSD, here's my fork: https://github.com/rpaulo/uboot-ccwmx53-digi

> 2) Do I need to create a cross compiler? Reference 1 says yes, reference
> two says no. Help!

You always need it when building on x86.

> Okay this is my process. It is performed in a 9.1-RELEASE jail within a
> PC-BSD 10 VM with 4 GB ram and 4 cores.
> 
> svn checkout https://svn0.us-west.FreeBSD.org/base/head /usr/src
> 
> cd /usr/src
> 
> make TARGET=arm TARGET_ARCH=arm -j10 buildworld
> 
> make TARGET=arm TARGET_ARCH=arm KERNCONF=DIGI-CCWMX53 buildkernel

Like Warner said, you need armv6.

--
Rui Paulo




From russ.haley at gmail.com  Sat Sep 27 06:19:15 2014
From: russ.haley at gmail.com (Russell Haley)
Date: Fri, 26 Sep 2014 23:19:14 -0700
Subject: Digi CCWMX53
In-Reply-To: <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
Message-ID: <CABx9NuQH36gyh1cT06fN7eJLZhrByzWpJH-RN8kb7hJi2ad9xw@mail.gmail.com>

Fantastic,

Thanks so much Warner and Rui.

Rui I've been pouring over your page trying to glean as much as I could
from it. I'm working with someone else and he tried booting from the
addresses on your page but since I wasn't building with the cross compiler
the kernel was never going to boot. He was wondering why the offset for the
go command when booting from the network (setenv bootcmd 'dhcp; tftpboot
0x70800000 kernel.ccwmx53; go 0x70800100')?

I can't wait to try this out!

Thanks Guys!
Russ

On Fri, Sep 26, 2014 at 10:56 PM, Rui Paulo <rpaulo at me.com> wrote:

> Hi,
>
> > On Sep 26, 2014, at 22:38, Russell Haley <russ.haley at gmail.com> wrote:
> >
> > Hello,
> >
> > I am trying to build for a DIgi CCWMX53 and was actually able to get a
> > kernel to build (holy cow I did it!!!) but I have failed to get it to
> boot.
> > I'll outline my steps below but I am also seeking answers for the
> following
> > questions:
> >
> > 1) Can anyone give me the correct u-boot enviroment variables or
> reference
> > to the u-boot process to boot the completed freebsd kernel. Specifically
> on
> > a CCWMX53 if possible, but I have linux references to port from. Where
> > would I look for an example?
>
> This is my setup:
>
> https://wiki.freebsd.org/Digi-CCWMX53
>
> I boot from the network because we don't support the MTD flash layout
> yet.  We can put a kernel in flash, but the kernel won't be able to read
> the MTD partition layout and we can't boot rootfs from there.  You can use
> a USB stick.
>
> If you want to build U-Boot from source on FreeBSD, here's my fork:
> https://github.com/rpaulo/uboot-ccwmx53-digi
>
> > 2) Do I need to create a cross compiler? Reference 1 says yes, reference
> > two says no. Help!
>
> You always need it when building on x86.
>
> > Okay this is my process. It is performed in a 9.1-RELEASE jail within a
> > PC-BSD 10 VM with 4 GB ram and 4 cores.
> >
> > svn checkout https://svn0.us-west.FreeBSD.org/base/head /usr/src
> >
> > cd /usr/src
> >
> > make TARGET=arm TARGET_ARCH=arm -j10 buildworld
> >
> > make TARGET=arm TARGET_ARCH=arm KERNCONF=DIGI-CCWMX53 buildkernel
>
> Like Warner said, you need armv6.
>
> --
> Rui Paulo
>
>
>
>

From ronald-lists at klop.ws  Sat Sep 27 08:57:38 2014
From: ronald-lists at klop.ws (Ronald Klop)
Date: Sat, 27 Sep 2014 10:57:21 +0200
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <542559BC.7090100@gmail.com>
References: <542559BC.7090100@gmail.com>
Message-ID: <op.xmt8hvspkndu52@pinky.home>

On Fri, 26 Sep 2014 14:19:08 +0200, Mattia Rossi  
<mattia.rossi.mailinglists at gmail.com> wrote:

> This might be part of the weird FFS issues the Dreamplug has and no-one  
> knows why they're happening.

I don't know if it is related, but my Sheevaplug also has issues with ffs  
while running 11-CURRENT. The fs gets corrupted or something. Which is not  
fixed by fsck. Every run of fsck finds more unlinked files and removes  
them. Also files which are stable on the fs since installation like /lib/*.
This ffs corruption + panic mostly happened while installing ports on the  
first day of operation.

But, the day before yesterday I compiled with gcc again instead of clang  
and it seems to run stable for 2 days now.

Unfortunately I don't have the backtraces of the crashes anymore.

NB: running 11-CURRENT from usb-stick with ports mounted via nfs.

Ronald.


> The panic occurred while running nsd-control reload (which should simply  
> re-read a config file from disk). I was previously editing files without  
> issues.
>
> Result is the following:
>
> vm_fault(0xc10a0000, d0238000, 2, 0) -> 2
> Fatal kernel mode data abort: 'Permission Fault (P)'
> trapframe: 0xde019898
> FSR=0000000f, FAR=d0238120, spsr=20000013
> r0 =d0238120, r1 =00000e60, r2 =00000000, r3 =00000000
> r4 =00000120, r5 =00000000, r6 =c3f3f6c0, r7 =00001000
> r8 =c443e880, r9 =00000000, r10=c3d69000, r11=de019a20
> r12=d0238120, ssp=de0198e8, slr=c0d53828, pc =c0de521c
>
> [ thread pid 21116 tid 100073 ]
> Stopped at      memset+0x48:    undge   0xa0cc20f8
> db>
> db> bt
> Tracing pid 21116 tid 100073 td 0xc3e97000
> db_trace_self() at db_trace_self
>           pc = 0xc0dd5418  lr = 0xc094f8a8 (db_hex2dec+0x490)
>           sp = 0xde0195a0  fp = 0xde0195b8
>          r10 = 0xc0f5e8c8
> db_hex2dec() at db_hex2dec+0x490
>           pc = 0xc094f8a8  lr = 0xc094f260 (db_command_loop+0x300)
>           sp = 0xde0195c0  fp = 0xde019660
>           r4 = 0x00000000  r5 = 0x00000000
>           r6 = 0x00000000
> db_command_loop() at db_command_loop+0x300
>           pc = 0xc094f260  lr = 0xc094efb0 (db_command_loop+0x50)
>           sp = 0xde019668  fp = 0xde019678
>           r4 = 0xc0e2dfe4  r5 = 0xc0e4402e
>           r6 = 0xc0f5e8b4  r7 = 0xc0ef62b8
>           r8 = 0xc0f52754  r9 = 0xc0f52750
>          r10 = 0xc3e97000
> db_command_loop() at db_command_loop+0x50
>           pc = 0xc094efb0  lr = 0xc09519ec (X_db_symbol_values+0x250)
>           sp = 0xde019680  fp = 0xde0197a0
>           r4 = 0x00000000  r5 = 0xc0f5e8c0
>           r6 = 0xc0f52778
> X_db_symbol_values() at X_db_symbol_values+0x250
>           pc = 0xc09519ec  lr = 0xc0b37b08 (kdb_trap+0xc4)
>           sp = 0xde0197a8  fp = 0xde0197c8
>           r4 = 0x00000000  r5 = 0x0000000f
>           r6 = 0xc0f52778  r7 = 0xc0ef62b8
> kdb_trap() at kdb_trap+0xc4
>           pc = 0xc0b37b08  lr = 0xc0de7c60 (data_abort_handler+0x7f8)
>           sp = 0xde0197d0  fp = 0xde0197e8
>           r4 = 0xde019898  r5 = 0x0000000f
>           r6 = 0x600000d3  r7 = 0xd0238120
>           r8 = 0x00000000  r9 = 0xc0f648d4
>          r10 = 0xc3e97000
> data_abort_handler() at data_abort_handler+0x7f8
>           pc = 0xc0de7c60  lr = 0xc0de7a28 (data_abort_handler+0x5c0)
>           sp = 0xde0197f0  fp = 0xde019890
>           r4 = 0xc10a0000  r5 = 0x00000013
>           r6 = 0xde019eb0  r7 = 0x00000002
> data_abort_handler() at data_abort_handler+0x5c0
>           pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
>           sp = 0xde019898  fp = 0xde019a20
>           r4 = 0xffffffff  r5 = 0xffff1004
>           r6 = 0xc3f3f6c0  r7 = 0x00001000
>           r8 = 0xc443e880  r9 = 0x00000000
>          r10 = 0xc3d69000
> exception_exit() at exception_exit
>           pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>           sp = 0xde0198e8  fp = 0xde019a20
>           r0 = 0xd0238120  r1 = 0x00000e60
>           r2 = 0x00000000  r3 = 0x00000000
>           r4 = 0x00000120  r5 = 0x00000000
>           r6 = 0xc3f3f6c0  r7 = 0x00001000
>           r8 = 0xc443e880  r9 = 0x00000000
>          r10 = 0xc3d69000 r12 = 0xd0238120
> memset() at memset+0x48
>           pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>           sp = 0xde0198e8  fp = 0xde019a20
> Unwind failure (no registers changed)
>
> The sad thing is, that with fsck broken for the dreamplug, I have to  
> re-format the disk, reinstall everything and recreate the config files  
> which I didn't manage to copy to a safe place beforehand :-(
>
> Before I do that I'll leave the system in debugging mode for a few days,  
> in case someone can help and needs some more information.
>
> Cheers,
>
> Mat
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

From bugzilla-noreply at freebsd.org  Sat Sep 27 09:26:09 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 27 Sep 2014 09:26:09 +0000
Subject: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in
 raspberry pi
In-Reply-To: <bug-175605-7@https.bugs.freebsd.org/bugzilla/>
References: <bug-175605-7@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-175605-7-xjYmtGdeMY@https.bugs.freebsd.org/bugzilla/>

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=175605

Baptiste Daroussin <bapt at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|In Discussion               |Issue Resolved
         Resolution|---                         |Overcome By Events

-- 
You are receiving this mail because:
You are the assignee for the bug.

From rpaulo at me.com  Sat Sep 27 16:30:55 2014
From: rpaulo at me.com (Rui Paulo)
Date: Sat, 27 Sep 2014 09:30:39 -0700
Subject: Digi CCWMX53
In-Reply-To: <CABx9NuQH36gyh1cT06fN7eJLZhrByzWpJH-RN8kb7hJi2ad9xw@mail.gmail.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
 <CABx9NuQH36gyh1cT06fN7eJLZhrByzWpJH-RN8kb7hJi2ad9xw@mail.gmail.com>
Message-ID: <42B4958F-21B2-4ABB-82C9-3F0B328EFED0@me.com>

On Sep 26, 2014, at 23:19, Russell Haley <russ.haley at gmail.com> wrote:
> 
> Fantastic,
> 
> Thanks so much Warner and Rui.
> 
> Rui I've been pouring over your page trying to glean as much as I could
> from it. I'm working with someone else and he tried booting from the
> addresses on your page but since I wasn't building with the cross compiler
> the kernel was never going to boot. He was wondering why the offset for the
> go command when booting from the network (setenv bootcmd 'dhcp; tftpboot
> 0x70800000 kernel.ccwmx53; go 0x70800100')?

The offset is the entry point of the ELF file.  I think we could use U-Boot's bootelf, but I forgot if it works.

--
Rui Paulo




From tim at kientzle.com  Sat Sep 27 19:14:17 2014
From: tim at kientzle.com (Tim Kientzle)
Date: Sat, 27 Sep 2014 11:53:35 -0700
Subject: Digi CCWMX53
In-Reply-To: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
Message-ID: <A4CEAFC3-446E-4D14-8F3B-1CDC92C65829@kientzle.com>


On Sep 26, 2014, at 10:38 PM, Russell Haley <russ.haley at gmail.com> wrote:

> 1) Can anyone give me the correct u-boot enviroment variables or reference
> to the u-boot process to boot the completed freebsd kernel. Specifically on
> a CCWMX53 if possible, but I have linux references to port from. Where
> would I look for an example?

There are two general approaches being used:

1) Have U-Boot load and boot the kernel directly.  This can sometimes be done with an unmodified Linux U-Boot.

2) Have U-Boot load FreeBSDs scriptable 'ubldr' and have that load the kernel.  This provides more flexibility in the boot process but usually requires rebuilding U-Boot.  In particular, you'll need to:
   * Add CONFIG_CMD_ELF option to U-Boot so it can load `ubldr' which is an ELF executable
   * Add CONFIG_CMD_API option to U-Boot so `ubldr' can access U-Boot's drivers for hardware access (`ubldr' itself has to be compiled for each board to adjust the load address but is otherwise completely generic).
   * Adjust the U-Boot startup scripts to set FDT environment variables and load ubldr.  You can look at the U-Boot patches for various boards supported by Crochet to see how this has been done elsewhere:
   github.com/kientlze/crochet-freebsd


> 2) Do I need to create a cross compiler? Reference 1 says yes, reference
> two says no. Help!

In most cases, the FreeBSD build system will build a cross-compiler for it's own use, so you generally don't need to install a cross compiler to cross-build FreeBSD proper.  However, U-Boot is not part of FreeBSD so you may need to install a separate cross-compiler to build that.

> 
> Ref.1 Build  a cross compiler
> https://wiki.freebsd.org/FreeBSD/arm/ArndaleBoard

This is using a cross-compiler from ports to build U-Boot.  It uses the FreeBSD build machinery to cross-build the FreeBSD kernel and world.  (When you specify TARGET_ARCH, FreeBSD's 'buildworld' target will build and use a suitable cross-compiler.  Also, 'buildkernel' will reuse the cross-compiler built by 'buildworld', so you do not need 'kernel-toolchain' as long as you 'buildworld' first.)

> 
> Ref 2. No cross compiler/ make toolchain
> https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD

This example only talks about building *world*, and the 'buildworld' target builds the necessary cross-tools transparently.  In particular, since it doesn't talk about building out-of-tree boot loaders such as U-Boot, it does not need to talk about building/installing an explicit cross-compiler.

For cross-compilers, you have three options:
 * Ports.
 * After a successful buildworld, you can 'make TARGET=xyz ... buildenv'  to get a shell with suitable path settings to reuse the cross-tools from the buildworld stage.  Use 'buildenvvar' to just get the environment for use in scripts.
 * FreeBSD source has an 'xdev' target that builds and installs a set of cross-tools.  In particular, it can install cross-versions of the same GCC or clang used by the rest of FreeBSD.  This facility has changed a lot recently, so ask if you need the current command line.

Hope this clarifies things,

Tim


From tim at kientzle.com  Sat Sep 27 19:22:43 2014
From: tim at kientzle.com (Tim Kientzle)
Date: Sat, 27 Sep 2014 11:57:28 -0700
Subject: Digi CCWMX53
In-Reply-To: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
Message-ID: <0E9D6D91-7D63-434E-B8FB-8A099FB1AAF3@kientzle.com>


On Sep 26, 2014, at 10:38 PM, Russell Haley <russ.haley at gmail.com> wrote:

> Okay this is my process. It is performed in a 9.1-RELEASE jail within a
> PC-BSD 10 VM with 4 GB ram and 4 cores.
> 
> svn checkout https://svn0.us-west.FreeBSD.org/base/head /usr/src
> 
> cd /usr/src
> 
> make TARGET=arm TARGET_ARCH=arm -j10 buildworld

TARGET_ARCH should be armv6 here

> 
> make TARGET=arm TARGET_ARCH=arm KERNCONF=DIGI-CCWMX53 buildkernel

TARGET_ARCH should be armv6 here

> 
> # never got to this due to documented error in head release that I had.
> make TARGET=arm TARGET_ARCH=arm installworld

You will definitely want to set DESTDIR! ;-)

> 
> Copy to sd card
> 
> #To Wipe Disk
> sudo dd if=/dev/zero of=/dev/da1 bs=512 count=1 && sync && sync
> 
> 
> #u-boot image From CCWMX53 Starter Kit
> sudo dd if=u-boot-ccwmx53js.bin of=/dev/da1 bs=512 && sync && sync
> 
> # lost the path from the build output that I got the kernel.bin file from.
> I have since deleted that jail
> sudo dd if=kernel.bin of=/dev/da1 bs=512 seek=2048 && sync && sync


You will also need to build a suitable filesystem image from the directory where you installed world and copy that onto the media.

Tim


From russ.haley at gmail.com  Sat Sep 27 20:19:24 2014
From: russ.haley at gmail.com (Russell Haley)
Date: Sat, 27 Sep 2014 13:19:22 -0700
Subject: Digi CCWMX53
In-Reply-To: <A4CEAFC3-446E-4D14-8F3B-1CDC92C65829@kientzle.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <A4CEAFC3-446E-4D14-8F3B-1CDC92C65829@kientzle.com>
Message-ID: <CABx9NuTRwBHLYJb1NP3=X6TuLcbZ_KsUBsdNVq3GX2ffRs1_hA@mail.gmail.com>

Tim,

Thanks, that's clarified a large number of my hanging questions.

I thought I had read that clang didn't support cross compiling arm for
freebsd in 10. Is this true?

I should have some more shortly!

Russ


On Sat, Sep 27, 2014 at 11:53 AM, Tim Kientzle <tim at kientzle.com> wrote:

>
> On Sep 26, 2014, at 10:38 PM, Russell Haley <russ.haley at gmail.com> wrote:
>
> > 1) Can anyone give me the correct u-boot enviroment variables or
> reference
> > to the u-boot process to boot the completed freebsd kernel. Specifically
> on
> > a CCWMX53 if possible, but I have linux references to port from. Where
> > would I look for an example?
>
> There are two general approaches being used:
>
> 1) Have U-Boot load and boot the kernel directly.  This can sometimes be
> done with an unmodified Linux U-Boot.
>
> 2) Have U-Boot load FreeBSDs scriptable 'ubldr' and have that load the
> kernel.  This provides more flexibility in the boot process but usually
> requires rebuilding U-Boot.  In particular, you'll need to:
>    * Add CONFIG_CMD_ELF option to U-Boot so it can load `ubldr' which is
> an ELF executable
>    * Add CONFIG_CMD_API option to U-Boot so `ubldr' can access U-Boot's
> drivers for hardware access (`ubldr' itself has to be compiled for each
> board to adjust the load address but is otherwise completely generic).
>    * Adjust the U-Boot startup scripts to set FDT environment variables
> and load ubldr.  You can look at the U-Boot patches for various boards
> supported by Crochet to see how this has been done elsewhere:
>    github.com/kientlze/crochet-freebsd
>
>
> > 2) Do I need to create a cross compiler? Reference 1 says yes, reference
> > two says no. Help!
>
> In most cases, the FreeBSD build system will build a cross-compiler for
> it's own use, so you generally don't need to install a cross compiler to
> cross-build FreeBSD proper.  However, U-Boot is not part of FreeBSD so you
> may need to install a separate cross-compiler to build that.
>
> >
> > Ref.1 Build  a cross compiler
> > https://wiki.freebsd.org/FreeBSD/arm/ArndaleBoard
>
> This is using a cross-compiler from ports to build U-Boot.  It uses the
> FreeBSD build machinery to cross-build the FreeBSD kernel and world.  (When
> you specify TARGET_ARCH, FreeBSD's 'buildworld' target will build and use a
> suitable cross-compiler.  Also, 'buildkernel' will reuse the cross-compiler
> built by 'buildworld', so you do not need 'kernel-toolchain' as long as you
> 'buildworld' first.)
>
> >
> > Ref 2. No cross compiler/ make toolchain
> > https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD
>
> This example only talks about building *world*, and the 'buildworld'
> target builds the necessary cross-tools transparently.  In particular,
> since it doesn't talk about building out-of-tree boot loaders such as
> U-Boot, it does not need to talk about building/installing an explicit
> cross-compiler.
>
> For cross-compilers, you have three options:
>  * Ports.
>  * After a successful buildworld, you can 'make TARGET=xyz ... buildenv'
> to get a shell with suitable path settings to reuse the cross-tools from
> the buildworld stage.  Use 'buildenvvar' to just get the environment for
> use in scripts.
>  * FreeBSD source has an 'xdev' target that builds and installs a set of
> cross-tools.  In particular, it can install cross-versions of the same GCC
> or clang used by the rest of FreeBSD.  This facility has changed a lot
> recently, so ask if you need the current command line.
>
> Hope this clarifies things,
>
> Tim
>
>

From russ.haley at gmail.com  Sat Sep 27 20:31:21 2014
From: russ.haley at gmail.com (Russell Haley)
Date: Sat, 27 Sep 2014 13:31:19 -0700
Subject: Digi CCWMX53
In-Reply-To: <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
Message-ID: <CABx9NuTU=E7ceQ=5=Qk+=e9jwLjnJZf2Lr70d7XbwAYRD5nd7Q@mail.gmail.com>

Rui,

So no MTD means the NAND on the SOM is out, but can I boot the kernel and
load rootfs from the microSD, like in this example:

   -

    ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000
kernel.bin; go 0x40f00000" ARNDALE5250 # saveenv ARNDALE5250 # boot


from https://wiki.freebsd.org/FreeBSD/arm/ArndaleBoard



On Fri, Sep 26, 2014 at 10:56 PM, Rui Paulo <rpaulo at me.com> wrote:

> Hi,
>
> > On Sep 26, 2014, at 22:38, Russell Haley <russ.haley at gmail.com> wrote:
> >
> > Hello,
> >
> > I am trying to build for a DIgi CCWMX53 and was actually able to get a
> > kernel to build (holy cow I did it!!!) but I have failed to get it to
> boot.
> > I'll outline my steps below but I am also seeking answers for the
> following
> > questions:
> >
> > 1) Can anyone give me the correct u-boot enviroment variables or
> reference
> > to the u-boot process to boot the completed freebsd kernel. Specifically
> on
> > a CCWMX53 if possible, but I have linux references to port from. Where
> > would I look for an example?
>
> This is my setup:
>
> https://wiki.freebsd.org/Digi-CCWMX53
>
> I boot from the network because we don't support the MTD flash layout
> yet.  We can put a kernel in flash, but the kernel won't be able to read
> the MTD partition layout and we can't boot rootfs from there.  You can use
> a USB stick.
>
> If you want to build U-Boot from source on FreeBSD, here's my fork:
> https://github.com/rpaulo/uboot-ccwmx53-digi
>
> > 2) Do I need to create a cross compiler? Reference 1 says yes, reference
> > two says no. Help!
>
> You always need it when building on x86.
>
> > Okay this is my process. It is performed in a 9.1-RELEASE jail within a
> > PC-BSD 10 VM with 4 GB ram and 4 cores.
> >
> > svn checkout https://svn0.us-west.FreeBSD.org/base/head /usr/src
> >
> > cd /usr/src
> >
> > make TARGET=arm TARGET_ARCH=arm -j10 buildworld
> >
> > make TARGET=arm TARGET_ARCH=arm KERNCONF=DIGI-CCWMX53 buildkernel
>
> Like Warner said, you need armv6.
>
> --
> Rui Paulo
>
>
>
>

From russ.haley at gmail.com  Sat Sep 27 20:43:56 2014
From: russ.haley at gmail.com (Russell Haley)
Date: Sat, 27 Sep 2014 13:43:55 -0700
Subject: Digi CCWMX53
In-Reply-To: <CABx9NuTRwBHLYJb1NP3=X6TuLcbZ_KsUBsdNVq3GX2ffRs1_hA@mail.gmail.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <A4CEAFC3-446E-4D14-8F3B-1CDC92C65829@kientzle.com>
 <CABx9NuTRwBHLYJb1NP3=X6TuLcbZ_KsUBsdNVq3GX2ffRs1_hA@mail.gmail.com>
Message-ID: <CABx9NuQGTpw_aNB+e2NO6_SPkF0JqiJeucRRGrhvfY5uT9iGzA@mail.gmail.com>

Tim,

I'm trying to build from head because the Digi configuration only seems to
exist there. Unfortunately the last couple of checkouts I've done haven't
built. Can you recommend a  good working revision or should I ask this on
the current mailing list?

On Sat, Sep 27, 2014 at 1:19 PM, Russell Haley <russ.haley at gmail.com> wrote:

> Tim,
>
> Thanks, that's clarified a large number of my hanging questions.
>
> I thought I had read that clang didn't support cross compiling arm for
> freebsd in 10. Is this true?
>
> I should have some more shortly!
>
> Russ
>
>
> On Sat, Sep 27, 2014 at 11:53 AM, Tim Kientzle <tim at kientzle.com> wrote:
>
>>
>> On Sep 26, 2014, at 10:38 PM, Russell Haley <russ.haley at gmail.com> wrote:
>>
>> > 1) Can anyone give me the correct u-boot enviroment variables or
>> reference
>> > to the u-boot process to boot the completed freebsd kernel.
>> Specifically on
>> > a CCWMX53 if possible, but I have linux references to port from. Where
>> > would I look for an example?
>>
>> There are two general approaches being used:
>>
>> 1) Have U-Boot load and boot the kernel directly.  This can sometimes be
>> done with an unmodified Linux U-Boot.
>>
>> 2) Have U-Boot load FreeBSDs scriptable 'ubldr' and have that load the
>> kernel.  This provides more flexibility in the boot process but usually
>> requires rebuilding U-Boot.  In particular, you'll need to:
>>    * Add CONFIG_CMD_ELF option to U-Boot so it can load `ubldr' which is
>> an ELF executable
>>    * Add CONFIG_CMD_API option to U-Boot so `ubldr' can access U-Boot's
>> drivers for hardware access (`ubldr' itself has to be compiled for each
>> board to adjust the load address but is otherwise completely generic).
>>    * Adjust the U-Boot startup scripts to set FDT environment variables
>> and load ubldr.  You can look at the U-Boot patches for various boards
>> supported by Crochet to see how this has been done elsewhere:
>>    github.com/kientlze/crochet-freebsd
>>
>>
>> > 2) Do I need to create a cross compiler? Reference 1 says yes, reference
>> > two says no. Help!
>>
>> In most cases, the FreeBSD build system will build a cross-compiler for
>> it's own use, so you generally don't need to install a cross compiler to
>> cross-build FreeBSD proper.  However, U-Boot is not part of FreeBSD so you
>> may need to install a separate cross-compiler to build that.
>>
>> >
>> > Ref.1 Build  a cross compiler
>> > https://wiki.freebsd.org/FreeBSD/arm/ArndaleBoard
>>
>> This is using a cross-compiler from ports to build U-Boot.  It uses the
>> FreeBSD build machinery to cross-build the FreeBSD kernel and world.  (When
>> you specify TARGET_ARCH, FreeBSD's 'buildworld' target will build and use a
>> suitable cross-compiler.  Also, 'buildkernel' will reuse the cross-compiler
>> built by 'buildworld', so you do not need 'kernel-toolchain' as long as you
>> 'buildworld' first.)
>>
>> >
>> > Ref 2. No cross compiler/ make toolchain
>> > https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD
>>
>> This example only talks about building *world*, and the 'buildworld'
>> target builds the necessary cross-tools transparently.  In particular,
>> since it doesn't talk about building out-of-tree boot loaders such as
>> U-Boot, it does not need to talk about building/installing an explicit
>> cross-compiler.
>>
>> For cross-compilers, you have three options:
>>  * Ports.
>>  * After a successful buildworld, you can 'make TARGET=xyz ... buildenv'
>> to get a shell with suitable path settings to reuse the cross-tools from
>> the buildworld stage.  Use 'buildenvvar' to just get the environment for
>> use in scripts.
>>  * FreeBSD source has an 'xdev' target that builds and installs a set of
>> cross-tools.  In particular, it can install cross-versions of the same GCC
>> or clang used by the rest of FreeBSD.  This facility has changed a lot
>> recently, so ask if you need the current command line.
>>
>> Hope this clarifies things,
>>
>> Tim
>>
>>
>

From rpaulo at me.com  Sat Sep 27 21:35:17 2014
From: rpaulo at me.com (Rui Paulo)
Date: Sat, 27 Sep 2014 14:35:12 -0700
Subject: Digi CCWMX53
In-Reply-To: <CABx9NuTU=E7ceQ=5=Qk+=e9jwLjnJZf2Lr70d7XbwAYRD5nd7Q@mail.gmail.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
 <CABx9NuTU=E7ceQ=5=Qk+=e9jwLjnJZf2Lr70d7XbwAYRD5nd7Q@mail.gmail.com>
Message-ID: <E12E12A8-32B9-4B26-B6C4-65DF9F43C396@me.com>

On Sep 27, 2014, at 13:31, Russell Haley <russ.haley at gmail.com> wrote:
> 
> Rui, 
> 
> So no MTD means the NAND on the SOM is out, but can I boot the kernel and load rootfs from the microSD, like in this example:
> 	?
>  ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.bin; go 0x40f00000"
> 
>  ARNDALE5250 # saveenv
> 
>  ARNDALE5250 # boot

You can't use the Arndale config since the load addresses are different.  You should be able to load a kernel from the network.  Can you do that?

--
Rui Paulo




From bugzilla-noreply at freebsd.org  Sat Sep 27 23:44:32 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 27 Sep 2014 23:44:32 +0000
Subject: [Bug 193981] New: panic: vtbuf_fill_locked begin.tp_row 0 must be <
 screen height 0 on Raspberry PI
Message-ID: <bug-193981-7@https.bugs.freebsd.org/bugzilla/>

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193981

            Bug ID: 193981
           Summary: panic: vtbuf_fill_locked begin.tp_row 0 must be <
                    screen height 0 on Raspberry PI
           Product: Base System
           Version: 10.0-STABLE
          Hardware: arm
                OS: Any
            Status: Needs Triage
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm at FreeBSD.org
          Reporter: danilo at FreeBSD.org
                CC: dumbbell at FreeBSD.org

I'm getting this panic on Raspberry. I'm running 10-stable r272221.
It's booting fine until I updated. Probably the problem was introduced after
r271973.

DRAM: 480MB
Number of U-Boot devices: 1
U-Boot env: loaderdev not set, will probe all devices.
Found U-Boot device: disk
  Probing all disk devices...
  Checking unit=0 slice=<auto> partition=<auto>... good.
Loading /boot/defaults/loader.conf 
/boot/kernel/kernel data=0x4ca5e4+0xada1c syms=[0x4+0x886d0+0x4+0x528af]

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...               
Using DTB provided by U-Boot at address 0x0x100.
Kernel entry at 0x100100...
Kernel args: (null)
panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0
Uptime: 1s

-- 
You are receiving this mail because:
You are the assignee for the bug.

From russ.haley at gmail.com  Sun Sep 28 04:49:36 2014
From: russ.haley at gmail.com (Russell Haley)
Date: Sat, 27 Sep 2014 21:49:34 -0700
Subject: Digi CCWMX53
In-Reply-To: <E12E12A8-32B9-4B26-B6C4-65DF9F43C396@me.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
 <CABx9NuTU=E7ceQ=5=Qk+=e9jwLjnJZf2Lr70d7XbwAYRD5nd7Q@mail.gmail.com>
 <E12E12A8-32B9-4B26-B6C4-65DF9F43C396@me.com>
Message-ID: <CABx9NuT31dVubDCCt7M5DGhoNqu0a9saxuB1fb9naq42Z8mi+A@mail.gmail.com>

I will attempt to load the kernel from tftp as soon as I can. I will need
to figure out how to get ethernet to the unit.

I know nothing about u-boot so forgive my ignorance but I was hoping to
modify the Arndale configuration to work such as:

# mmc read 1 0x70800000 0x800 0x1800;
#go 0x70800000;

and then point the rootfs to /dev/da1s1

On another note, do you know where I could find out more about the missing
MTD support?

BTW, I thought your wireless mesh stuff was pretty cool. Ah, so many cool
projects, so little time...

Thanks,

Russ

On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo <rpaulo at me.com> wrote:

> On Sep 27, 2014, at 13:31, Russell Haley <russ.haley at gmail.com> wrote:
> >
> > Rui,
> >
> > So no MTD means the NAND on the SOM is out, but can I boot the kernel
> and load rootfs from the microSD, like in this example:
> >       ?
> >  ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.bin; go
> 0x40f00000"
> >
> >  ARNDALE5250 # saveenv
> >
> >  ARNDALE5250 # boot
>
> You can't use the Arndale config since the load addresses are different.
> You should be able to load a kernel from the network.  Can you do that?
>
> --
> Rui Paulo
>
>
>
>

From imp at bsdimp.com  Sun Sep 28 07:12:43 2014
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 28 Sep 2014 00:12:32 -0700
Subject: Digi CCWMX53
In-Reply-To: <CABx9NuT31dVubDCCt7M5DGhoNqu0a9saxuB1fb9naq42Z8mi+A@mail.gmail.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
 <CABx9NuTU=E7ceQ=5=Qk+=e9jwLjnJZf2Lr70d7XbwAYRD5nd7Q@mail.gmail.com>
 <E12E12A8-32B9-4B26-B6C4-65DF9F43C396@me.com>
 <CABx9NuT31dVubDCCt7M5DGhoNqu0a9saxuB1fb9naq42Z8mi+A@mail.gmail.com>
Message-ID: <A73CCB0A-2ED9-4505-BACD-264F768D2D72@bsdimp.com>


On Sep 27, 2014, at 9:49 PM, Russell Haley <russ.haley at gmail.com> wrote:

> I will attempt to load the kernel from tftp as soon as I can. I will need
> to figure out how to get ethernet to the unit.
> 
> I know nothing about u-boot so forgive my ignorance but I was hoping to
> modify the Arndale configuration to work such as:
> 
> # mmc read 1 0x70800000 0x800 0x1800;
> #go 0x70800000;
> 
> and then point the rootfs to /dev/da1s1
> 
> On another note, do you know where I could find out more about the missing
> MTD support?

A spec for the NAND controller is needed to make that work?  Is one about?

Warner


> BTW, I thought your wireless mesh stuff was pretty cool. Ah, so many cool
> projects, so little time...
> 
> Thanks,
> 
> Russ
> 
> On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo <rpaulo at me.com> wrote:
> 
>> On Sep 27, 2014, at 13:31, Russell Haley <russ.haley at gmail.com> wrote:
>>> 
>>> Rui,
>>> 
>>> So no MTD means the NAND on the SOM is out, but can I boot the kernel
>> and load rootfs from the microSD, like in this example:
>>>      ?
>>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.bin; go
>> 0x40f00000"
>>> 
>>> ARNDALE5250 # saveenv
>>> 
>>> ARNDALE5250 # boot
>> 
>> You can't use the Arndale config since the load addresses are different.
>> You should be able to load a kernel from the network.  Can you do that?
>> 
>> --
>> Rui Paulo
>> 
>> 
>> 
>> 
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140928/593f119b/attachment.sig>

From russ.haley at gmail.com  Sun Sep 28 07:25:54 2014
From: russ.haley at gmail.com (russ.haley at gmail.com)
Date: Sun, 28 Sep 2014 00:25:52 -0700
Subject: Digi CCWMX53
In-Reply-To: <A73CCB0A-2ED9-4505-BACD-264F768D2D72@bsdimp.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
 <CABx9NuTU=E7ceQ=5=Qk+=e9jwLjnJZf2Lr70d7XbwAYRD5nd7Q@mail.gmail.com>
 <E12E12A8-32B9-4B26-B6C4-65DF9F43C396@me.com>
 <CABx9NuT31dVubDCCt7M5DGhoNqu0a9saxuB1fb9naq42Z8mi+A@mail.gmail.com>
 <A73CCB0A-2ED9-4505-BACD-264F768D2D72@bsdimp.com>
Message-ID: <20140928072552.6008977.32039.589@gmail.com>

I'll check at work on Tuesday when I'm in.?

Thanks,
Russ

Sent from my BlackBerry 10 smartphone.
? Original Message ?
From: Warner Losh
Sent: Sunday, September 28, 2014 12:12 AM
To: Russell Haley
Cc: Rui Paulo; freebsd-arm at freebsd.org
Subject: Re: Digi CCWMX53


On Sep 27, 2014, at 9:49 PM, Russell Haley <russ.haley at gmail.com> wrote:

> I will attempt to load the kernel from tftp as soon as I can. I will need
> to figure out how to get ethernet to the unit.
> 
> I know nothing about u-boot so forgive my ignorance but I was hoping to
> modify the Arndale configuration to work such as:
> 
> # mmc read 1 0x70800000 0x800 0x1800;
> #go 0x70800000;
> 
> and then point the rootfs to /dev/da1s1
> 
> On another note, do you know where I could find out more about the missing
> MTD support?

A spec for the NAND controller is needed to make that work? Is one about?

Warner


> BTW, I thought your wireless mesh stuff was pretty cool. Ah, so many cool
> projects, so little time...
> 
> Thanks,
> 
> Russ
> 
> On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo <rpaulo at me.com> wrote:
> 
>> On Sep 27, 2014, at 13:31, Russell Haley <russ.haley at gmail.com> wrote:
>>> 
>>> Rui,
>>> 
>>> So no MTD means the NAND on the SOM is out, but can I boot the kernel
>> and load rootfs from the microSD, like in this example:
>>> ?
>>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.bin; go
>> 0x40f00000"
>>> 
>>> ARNDALE5250 # saveenv
>>> 
>>> ARNDALE5250 # boot
>> 
>> You can't use the Arndale config since the load addresses are different.
>> You should be able to load a kernel from the network. Can you do that?
>> 
>> --
>> Rui Paulo
>> 
>> 
>> 
>> 
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"


From mattia.rossi.mate at gmail.com  Sun Sep 28 09:55:41 2014
From: mattia.rossi.mate at gmail.com (Mattia Rossi)
Date: Sun, 28 Sep 2014 11:55:37 +0200
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <op.xmt8hvspkndu52@pinky.home>
References: <542559BC.7090100@gmail.com> <op.xmt8hvspkndu52@pinky.home>
Message-ID: <5427DB19.4000304@gmail.com>

On 27/09/14 10:57, Ronald Klop wrote:
> On Fri, 26 Sep 2014 14:19:08 +0200, Mattia Rossi 
> <mattia.rossi.mailinglists at gmail.com> wrote:
>
>> This might be part of the weird FFS issues the Dreamplug has and 
>> no-one knows why they're happening.
>
> I don't know if it is related, but my Sheevaplug also has issues with 
> ffs while running 11-CURRENT. The fs gets corrupted or something. 
> Which is not fixed by fsck. Every run of fsck finds more unlinked 
> files and removes them. Also files which are stable on the fs since 
> installation like /lib/*.
I've had a discussion with Ian Lepore about this, and he actually found 
out that fsck is broken.
> This ffs corruption + panic mostly happened while installing ports on 
> the first day of operation.
>
> But, the day before yesterday I compiled with gcc again instead of 
> clang and it seems to run stable for 2 days now.
This is interesting though.. How do I switch to gcc as compiler for 
world? I'd like to test that, and to see if it's really a clang problem.
>
> Unfortunately I don't have the backtraces of the crashes anymore.
>
> NB: running 11-CURRENT from usb-stick with ports mounted via nfs.
Well, it's pretty much the same I have, only that the dreamplug has an 
internal sd card which is attached via usb. I have ports on nfs as well.
>
> Ronald.
>
>
>> The panic occurred while running nsd-control reload (which should 
>> simply re-read a config file from disk). I was previously editing 
>> files without issues.
>>
>> Result is the following:
>>
>> vm_fault(0xc10a0000, d0238000, 2, 0) -> 2
>> Fatal kernel mode data abort: 'Permission Fault (P)'
>> trapframe: 0xde019898
>> FSR=0000000f, FAR=d0238120, spsr=20000013
>> r0 =d0238120, r1 =00000e60, r2 =00000000, r3 =00000000
>> r4 =00000120, r5 =00000000, r6 =c3f3f6c0, r7 =00001000
>> r8 =c443e880, r9 =00000000, r10=c3d69000, r11=de019a20
>> r12=d0238120, ssp=de0198e8, slr=c0d53828, pc =c0de521c
>>
>> [ thread pid 21116 tid 100073 ]
>> Stopped at      memset+0x48:    undge   0xa0cc20f8
>> db>
>> db> bt
>> Tracing pid 21116 tid 100073 td 0xc3e97000
>> db_trace_self() at db_trace_self
>>           pc = 0xc0dd5418  lr = 0xc094f8a8 (db_hex2dec+0x490)
>>           sp = 0xde0195a0  fp = 0xde0195b8
>>          r10 = 0xc0f5e8c8
>> db_hex2dec() at db_hex2dec+0x490
>>           pc = 0xc094f8a8  lr = 0xc094f260 (db_command_loop+0x300)
>>           sp = 0xde0195c0  fp = 0xde019660
>>           r4 = 0x00000000  r5 = 0x00000000
>>           r6 = 0x00000000
>> db_command_loop() at db_command_loop+0x300
>>           pc = 0xc094f260  lr = 0xc094efb0 (db_command_loop+0x50)
>>           sp = 0xde019668  fp = 0xde019678
>>           r4 = 0xc0e2dfe4  r5 = 0xc0e4402e
>>           r6 = 0xc0f5e8b4  r7 = 0xc0ef62b8
>>           r8 = 0xc0f52754  r9 = 0xc0f52750
>>          r10 = 0xc3e97000
>> db_command_loop() at db_command_loop+0x50
>>           pc = 0xc094efb0  lr = 0xc09519ec (X_db_symbol_values+0x250)
>>           sp = 0xde019680  fp = 0xde0197a0
>>           r4 = 0x00000000  r5 = 0xc0f5e8c0
>>           r6 = 0xc0f52778
>> X_db_symbol_values() at X_db_symbol_values+0x250
>>           pc = 0xc09519ec  lr = 0xc0b37b08 (kdb_trap+0xc4)
>>           sp = 0xde0197a8  fp = 0xde0197c8
>>           r4 = 0x00000000  r5 = 0x0000000f
>>           r6 = 0xc0f52778  r7 = 0xc0ef62b8
>> kdb_trap() at kdb_trap+0xc4
>>           pc = 0xc0b37b08  lr = 0xc0de7c60 (data_abort_handler+0x7f8)
>>           sp = 0xde0197d0  fp = 0xde0197e8
>>           r4 = 0xde019898  r5 = 0x0000000f
>>           r6 = 0x600000d3  r7 = 0xd0238120
>>           r8 = 0x00000000  r9 = 0xc0f648d4
>>          r10 = 0xc3e97000
>> data_abort_handler() at data_abort_handler+0x7f8
>>           pc = 0xc0de7c60  lr = 0xc0de7a28 (data_abort_handler+0x5c0)
>>           sp = 0xde0197f0  fp = 0xde019890
>>           r4 = 0xc10a0000  r5 = 0x00000013
>>           r6 = 0xde019eb0  r7 = 0x00000002
>> data_abort_handler() at data_abort_handler+0x5c0
>>           pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
>>           sp = 0xde019898  fp = 0xde019a20
>>           r4 = 0xffffffff  r5 = 0xffff1004
>>           r6 = 0xc3f3f6c0  r7 = 0x00001000
>>           r8 = 0xc443e880  r9 = 0x00000000
>>          r10 = 0xc3d69000
>> exception_exit() at exception_exit
>>           pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>>           sp = 0xde0198e8  fp = 0xde019a20
>>           r0 = 0xd0238120  r1 = 0x00000e60
>>           r2 = 0x00000000  r3 = 0x00000000
>>           r4 = 0x00000120  r5 = 0x00000000
>>           r6 = 0xc3f3f6c0  r7 = 0x00001000
>>           r8 = 0xc443e880  r9 = 0x00000000
>>          r10 = 0xc3d69000 r12 = 0xd0238120
>> memset() at memset+0x48
>>           pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>>           sp = 0xde0198e8  fp = 0xde019a20
>> Unwind failure (no registers changed)
>>
>> The sad thing is, that with fsck broken for the dreamplug, I have to 
>> re-format the disk, reinstall everything and recreate the config 
>> files which I didn't manage to copy to a safe place beforehand :-(
>>
>> Before I do that I'll leave the system in debugging mode for a few 
>> days, in case someone can help and needs some more information.
>>
>> Cheers,
>>
>> Mat
>> _______________________________________________
>> freebsd-arm at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"


From andrew at fubar.geek.nz  Sun Sep 28 11:18:33 2014
From: andrew at fubar.geek.nz (Andrew Turner)
Date: Sun, 28 Sep 2014 12:18:18 +0100
Subject: MK_ARM_EABI to retire in current
In-Reply-To: <C66667D9-2F5E-44E0-AF04-E9DFE70BAF5A@gmail.com>
References: <C66667D9-2F5E-44E0-AF04-E9DFE70BAF5A@gmail.com>
Message-ID: <20140928121818.741e7e7e@bender.lan>

On Mon, 19 May 2014 09:40:33 -0600
Warner Losh <imp at bsdimp.com> wrote:

> Greetings,
> 
> MK_ARM_EABI is going to die in current. It is the default for all
> platforms currently. I?m eliminating it as a build option. It must
> die because it invisibly (to uname) effects the ABI.
> 
> So, to that end, I see two options:
> 
> (1) Retire and remove oabi support.
> (2) Retain oabi support, but change its name to armo and armoeb.
> 
> The rough consensus of arm developers I?ve polled now, and in the
> past, is that we just let oabi support die now that EABI support is
> working for everybody.
> 
> Before I pull the trigger on this, however, I must ask if anybody has
> a problem with my doing option (1), and if so, what keeps you using
> oabi.
> 
> Comments?

As far as I know all the problems with ARM EABI on armeb mentioned
in this thread have been fixed. I think we should now retire the oabi
support and remove MK_ARM_EABI.

Andrew

From ronald-lists at klop.ws  Sun Sep 28 12:41:23 2014
From: ronald-lists at klop.ws (Ronald Klop)
Date: Sun, 28 Sep 2014 14:41:08 +0200
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <5427DB19.4000304@gmail.com>
References: <542559BC.7090100@gmail.com> <op.xmt8hvspkndu52@pinky.home>
 <5427DB19.4000304@gmail.com>
Message-ID: <op.xmwdiud6kndu52@82-171-231-144.ip.telfort.nl>

On Sun, 28 Sep 2014 11:55:37 +0200, Mattia Rossi  
<mattia.rossi.mate at gmail.com> wrote:

> On 27/09/14 10:57, Ronald Klop wrote:
>> On Fri, 26 Sep 2014 14:19:08 +0200, Mattia Rossi  
>> <mattia.rossi.mailinglists at gmail.com> wrote:
>>
>>> This might be part of the weird FFS issues the Dreamplug has and  
>>> no-one knows why they're happening.
>>
>> I don't know if it is related, but my Sheevaplug also has issues with  
>> ffs while running 11-CURRENT. The fs gets corrupted or something. Which  
>> is not fixed by fsck. Every run of fsck finds more unlinked files and  
>> removes them. Also files which are stable on the fs since installation  
>> like /lib/*.
> I've had a discussion with Ian Lepore about this, and he actually found  
> out that fsck is broken.
>> This ffs corruption + panic mostly happened while installing ports on  
>> the first day of operation.
>>
>> But, the day before yesterday I compiled with gcc again instead of  
>> clang and it seems to run stable for 2 days now.
> This is interesting though.. How do I switch to gcc as compiler for  
> world? I'd like to test that, and to see if it's really a clang problem.

I put this in the environment.

export WITH_GCC=yes
export WITH_GNUCXX=yes
export WITH_GCC_BOOTSTRAP=yes
export WITHOUT_CLANG=yes
export WITHOUT_CLANG_IS_CC=yes
export WITHOUT_CLANG_BOOTSTRAP=yes

Got that from this email:  
http://lists.freebsd.org/pipermail/freebsd-arm/2014-August/009001.html

Regards,
Ronald.



>>
>> Unfortunately I don't have the backtraces of the crashes anymore.
>>
>> NB: running 11-CURRENT from usb-stick with ports mounted via nfs.
> Well, it's pretty much the same I have, only that the dreamplug has an  
> internal sd card which is attached via usb. I have ports on nfs as well.
>>
>> Ronald.
>>
>>
>>> The panic occurred while running nsd-control reload (which should  
>>> simply re-read a config file from disk). I was previously editing  
>>> files without issues.
>>>
>>> Result is the following:
>>>
>>> vm_fault(0xc10a0000, d0238000, 2, 0) -> 2
>>> Fatal kernel mode data abort: 'Permission Fault (P)'
>>> trapframe: 0xde019898
>>> FSR=0000000f, FAR=d0238120, spsr=20000013
>>> r0 =d0238120, r1 =00000e60, r2 =00000000, r3 =00000000
>>> r4 =00000120, r5 =00000000, r6 =c3f3f6c0, r7 =00001000
>>> r8 =c443e880, r9 =00000000, r10=c3d69000, r11=de019a20
>>> r12=d0238120, ssp=de0198e8, slr=c0d53828, pc =c0de521c
>>>
>>> [ thread pid 21116 tid 100073 ]
>>> Stopped at      memset+0x48:    undge   0xa0cc20f8
>>> db>
>>> db> bt
>>> Tracing pid 21116 tid 100073 td 0xc3e97000
>>> db_trace_self() at db_trace_self
>>>           pc = 0xc0dd5418  lr = 0xc094f8a8 (db_hex2dec+0x490)
>>>           sp = 0xde0195a0  fp = 0xde0195b8
>>>          r10 = 0xc0f5e8c8
>>> db_hex2dec() at db_hex2dec+0x490
>>>           pc = 0xc094f8a8  lr = 0xc094f260 (db_command_loop+0x300)
>>>           sp = 0xde0195c0  fp = 0xde019660
>>>           r4 = 0x00000000  r5 = 0x00000000
>>>           r6 = 0x00000000
>>> db_command_loop() at db_command_loop+0x300
>>>           pc = 0xc094f260  lr = 0xc094efb0 (db_command_loop+0x50)
>>>           sp = 0xde019668  fp = 0xde019678
>>>           r4 = 0xc0e2dfe4  r5 = 0xc0e4402e
>>>           r6 = 0xc0f5e8b4  r7 = 0xc0ef62b8
>>>           r8 = 0xc0f52754  r9 = 0xc0f52750
>>>          r10 = 0xc3e97000
>>> db_command_loop() at db_command_loop+0x50
>>>           pc = 0xc094efb0  lr = 0xc09519ec (X_db_symbol_values+0x250)
>>>           sp = 0xde019680  fp = 0xde0197a0
>>>           r4 = 0x00000000  r5 = 0xc0f5e8c0
>>>           r6 = 0xc0f52778
>>> X_db_symbol_values() at X_db_symbol_values+0x250
>>>           pc = 0xc09519ec  lr = 0xc0b37b08 (kdb_trap+0xc4)
>>>           sp = 0xde0197a8  fp = 0xde0197c8
>>>           r4 = 0x00000000  r5 = 0x0000000f
>>>           r6 = 0xc0f52778  r7 = 0xc0ef62b8
>>> kdb_trap() at kdb_trap+0xc4
>>>           pc = 0xc0b37b08  lr = 0xc0de7c60 (data_abort_handler+0x7f8)
>>>           sp = 0xde0197d0  fp = 0xde0197e8
>>>           r4 = 0xde019898  r5 = 0x0000000f
>>>           r6 = 0x600000d3  r7 = 0xd0238120
>>>           r8 = 0x00000000  r9 = 0xc0f648d4
>>>          r10 = 0xc3e97000
>>> data_abort_handler() at data_abort_handler+0x7f8
>>>           pc = 0xc0de7c60  lr = 0xc0de7a28 (data_abort_handler+0x5c0)
>>>           sp = 0xde0197f0  fp = 0xde019890
>>>           r4 = 0xc10a0000  r5 = 0x00000013
>>>           r6 = 0xde019eb0  r7 = 0x00000002
>>> data_abort_handler() at data_abort_handler+0x5c0
>>>           pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
>>>           sp = 0xde019898  fp = 0xde019a20
>>>           r4 = 0xffffffff  r5 = 0xffff1004
>>>           r6 = 0xc3f3f6c0  r7 = 0x00001000
>>>           r8 = 0xc443e880  r9 = 0x00000000
>>>          r10 = 0xc3d69000
>>> exception_exit() at exception_exit
>>>           pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>>>           sp = 0xde0198e8  fp = 0xde019a20
>>>           r0 = 0xd0238120  r1 = 0x00000e60
>>>           r2 = 0x00000000  r3 = 0x00000000
>>>           r4 = 0x00000120  r5 = 0x00000000
>>>           r6 = 0xc3f3f6c0  r7 = 0x00001000
>>>           r8 = 0xc443e880  r9 = 0x00000000
>>>          r10 = 0xc3d69000 r12 = 0xd0238120
>>> memset() at memset+0x48
>>>           pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>>>           sp = 0xde0198e8  fp = 0xde019a20
>>> Unwind failure (no registers changed)
>>>
>>> The sad thing is, that with fsck broken for the dreamplug, I have to  
>>> re-format the disk, reinstall everything and recreate the config files  
>>> which I didn't manage to copy to a safe place beforehand :-(
>>>
>>> Before I do that I'll leave the system in debugging mode for a few  
>>> days, in case someone can help and needs some more information.
>>>
>>> Cheers,
>>>
>>> Mat
>>> _______________________________________________
>>> freebsd-arm at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>> _______________________________________________
>> freebsd-arm at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

From ian at FreeBSD.org  Sun Sep 28 15:21:34 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Sun, 28 Sep 2014 09:21:25 -0600
Subject: Digi CCWMX53
In-Reply-To: <42B4958F-21B2-4ABB-82C9-3F0B328EFED0@me.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
 <CABx9NuQH36gyh1cT06fN7eJLZhrByzWpJH-RN8kb7hJi2ad9xw@mail.gmail.com>
 <42B4958F-21B2-4ABB-82C9-3F0B328EFED0@me.com>
Message-ID: <1411917685.66615.309.camel@revolution.hippie.lan>

On Sat, 2014-09-27 at 09:30 -0700, Rui Paulo wrote:
> On Sep 26, 2014, at 23:19, Russell Haley <russ.haley at gmail.com> wrote:
> > 
> > Fantastic,
> > 
> > Thanks so much Warner and Rui.
> > 
> > Rui I've been pouring over your page trying to glean as much as I could
> > from it. I'm working with someone else and he tried booting from the
> > addresses on your page but since I wasn't building with the cross compiler
> > the kernel was never going to boot. He was wondering why the offset for the
> > go command when booting from the network (setenv bootcmd 'dhcp; tftpboot
> > 0x70800000 kernel.ccwmx53; go 0x70800100')?
> 
> The offset is the entry point of the ELF file.  I think we could use U-Boot's bootelf, but I forgot if it works.
> 
> --
> Rui Paulo

We can use bootelf on ubldr, but not on the kernel, because our kernel
linker script doesn't fill in the physical load address properly in the
elf header (it would try to load the virtual address).

So the two options for launching the kernel directly are:
  
   load kernel; go <load address + 100>
   load kernel.bin; go <load address>

The standard no-suffix kernel file is an elf binary with the wrong load
address in the header, and the header is 0x100 bytes, so the entry point
is immediately after that.  The kernel.bin file is exactly the same as
kernel, but with the elf header stripped off, so the entry point is at
an offset of zero.

An interesting thing about our kernel is that it can be loaded at any
1MB boundary in physical memory, not just the address it was linked at.
There's no way to represent that in an elf header.  This is true of both
kernel and kernel.bin.

-- Ian



From rpaulo at me.com  Sun Sep 28 16:34:53 2014
From: rpaulo at me.com (Rui Paulo)
Date: Sun, 28 Sep 2014 09:34:41 -0700
Subject: Digi CCWMX53
In-Reply-To: <A73CCB0A-2ED9-4505-BACD-264F768D2D72@bsdimp.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
 <CABx9NuTU=E7ceQ=5=Qk+=e9jwLjnJZf2Lr70d7XbwAYRD5nd7Q@mail.gmail.com>
 <E12E12A8-32B9-4B26-B6C4-65DF9F43C396@me.com>
 <CABx9NuT31dVubDCCt7M5DGhoNqu0a9saxuB1fb9naq42Z8mi+A@mail.gmail.com>
 <A73CCB0A-2ED9-4505-BACD-264F768D2D72@bsdimp.com>
Message-ID: <E3DF170B-03A2-46F8-B74A-7F4EEFB643AE@me.com>

On Sep 28, 2014, at 00:12, Warner Losh <imp at bsdimp.com> wrote:
> A spec for the NAND controller is needed to make that work?  Is one about?

We have access to U-Boot's source code, so that could also work.

--
Rui Paulo




From rpaulo at me.com  Sun Sep 28 16:36:47 2014
From: rpaulo at me.com (Rui Paulo)
Date: Sun, 28 Sep 2014 09:36:27 -0700
Subject: Digi CCWMX53
In-Reply-To: <1411917685.66615.309.camel@revolution.hippie.lan>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
 <CABx9NuQH36gyh1cT06fN7eJLZhrByzWpJH-RN8kb7hJi2ad9xw@mail.gmail.com>
 <42B4958F-21B2-4ABB-82C9-3F0B328EFED0@me.com>
 <1411917685.66615.309.camel@revolution.hippie.lan>
Message-ID: <44EB751E-E53F-46C8-809C-655002C57BC6@me.com>

On Sep 28, 2014, at 08:21, Ian Lepore <ian at FreeBSD.org> wrote:
> We can use bootelf on ubldr, but not on the kernel, because our kernel
> linker script doesn't fill in the physical load address properly in the
> elf header (it would try to load the virtual address).
> 
> So the two options for launching the kernel directly are:
> 
>   load kernel; go <load address + 100>
>   load kernel.bin; go <load address>
> 
> The standard no-suffix kernel file is an elf binary with the wrong load
> address in the header, and the header is 0x100 bytes, so the entry point
> is immediately after that.  The kernel.bin file is exactly the same as
> kernel, but with the elf header stripped off, so the entry point is at
> an offset of zero.
> 
> An interesting thing about our kernel is that it can be loaded at any
> 1MB boundary in physical memory, not just the address it was linked at.
> There's no way to represent that in an elf header.  This is true of both
> kernel and kernel.bin.

Ah, I think I made it work once when I set the KERNPHYS (or KERNVIRT?) to match the load address.

--
Rui Paulo




From imp at bsdimp.com  Sun Sep 28 17:19:19 2014
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 28 Sep 2014 10:19:09 -0700
Subject: MK_ARM_EABI to retire in current
In-Reply-To: <20140928121818.741e7e7e@bender.lan>
References: <C66667D9-2F5E-44E0-AF04-E9DFE70BAF5A@gmail.com>
 <20140928121818.741e7e7e@bender.lan>
Message-ID: <E594E133-F3A7-46EA-BCEF-B2B62B5FCE4C@bsdimp.com>


On Sep 28, 2014, at 4:18 AM, Andrew Turner <andrew at fubar.geek.nz> wrote:

> On Mon, 19 May 2014 09:40:33 -0600
> Warner Losh <imp at bsdimp.com> wrote:
> 
>> Greetings,
>> 
>> MK_ARM_EABI is going to die in current. It is the default for all
>> platforms currently. I?m eliminating it as a build option. It must
>> die because it invisibly (to uname) effects the ABI.
>> 
>> So, to that end, I see two options:
>> 
>> (1) Retire and remove oabi support.
>> (2) Retain oabi support, but change its name to armo and armoeb.
>> 
>> The rough consensus of arm developers I?ve polled now, and in the
>> past, is that we just let oabi support die now that EABI support is
>> working for everybody.
>> 
>> Before I pull the trigger on this, however, I must ask if anybody has
>> a problem with my doing option (1), and if so, what keeps you using
>> oabi.
>> 
>> Comments?
> 
> As far as I know all the problems with ARM EABI on armeb mentioned
> in this thread have been fixed. I think we should now retire the oabi
> support and remove MK_ARM_EABI.

I?m game. I think we should move forward on option #1. We?ve had no issues
in the 10.1 release related to this that I?m aware of. Should there be no further
objections, my plan is to move forward with this later this week.

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140928/47a1cb71/attachment.sig>

From imp at bsdimp.com  Sun Sep 28 17:29:58 2014
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 28 Sep 2014 10:29:47 -0700
Subject: Digi CCWMX53
In-Reply-To: <E3DF170B-03A2-46F8-B74A-7F4EEFB643AE@me.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
 <CABx9NuTU=E7ceQ=5=Qk+=e9jwLjnJZf2Lr70d7XbwAYRD5nd7Q@mail.gmail.com>
 <E12E12A8-32B9-4B26-B6C4-65DF9F43C396@me.com>
 <CABx9NuT31dVubDCCt7M5DGhoNqu0a9saxuB1fb9naq42Z8mi+A@mail.gmail.com>
 <A73CCB0A-2ED9-4505-BACD-264F768D2D72@bsdimp.com>
 <E3DF170B-03A2-46F8-B74A-7F4EEFB643AE@me.com>
Message-ID: <A887275C-04F8-4B52-9EA0-6E4EC6FE9703@bsdimp.com>


On Sep 28, 2014, at 9:34 AM, Rui Paulo <rpaulo at me.com> wrote:

> On Sep 28, 2014, at 00:12, Warner Losh <imp at bsdimp.com> wrote:
>> A spec for the NAND controller is needed to make that work?  Is one about?
> 
> We have access to U-Boot's source code, so that could also work.

Right. Access to Linux sources too. Without a spec, however, it is my experience
that this source code is helpful, but often incomplete.

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140928/f4d91817/attachment.sig>

From russ.haley at gmail.com  Sun Sep 28 20:12:47 2014
From: russ.haley at gmail.com (Russell Haley)
Date: Sun, 28 Sep 2014 13:12:46 -0700
Subject: Digi CCWMX53
In-Reply-To: <E12E12A8-32B9-4B26-B6C4-65DF9F43C396@me.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
 <CABx9NuTU=E7ceQ=5=Qk+=e9jwLjnJZf2Lr70d7XbwAYRD5nd7Q@mail.gmail.com>
 <E12E12A8-32B9-4B26-B6C4-65DF9F43C396@me.com>
Message-ID: <CABx9NuTkMcvX9gtLrEBO0cd7Kw+5mx4+1N9Z-02F9NGfueORjw@mail.gmail.com>

Rui,

I was able to get a linux compatible copy of uboot to load a file from the
network last night. I don't have a working BSD kernel right now and it
wouldn't boot any of the uimage kernels I tried to upload. I'll work on
getting a BSD kernel to build.

Russ

On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo <rpaulo at me.com> wrote:

> On Sep 27, 2014, at 13:31, Russell Haley <russ.haley at gmail.com> wrote:
> >
> > Rui,
> >
> > So no MTD means the NAND on the SOM is out, but can I boot the kernel
> and load rootfs from the microSD, like in this example:
> >       ?
> >  ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.bin; go
> 0x40f00000"
> >
> >  ARNDALE5250 # saveenv
> >
> >  ARNDALE5250 # boot
>
> You can't use the Arndale config since the load addresses are different.
> You should be able to load a kernel from the network.  Can you do that?
>
> --
> Rui Paulo
>
>
>
>

From erichsfreebsdlist at alogt.com  Mon Sep 29 00:03:56 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Mon, 29 Sep 2014 08:03:37 +0800
Subject: Documentation for using GPIO
Message-ID: <20140929080337.46bbb5a3@X220.alogt.com>

Hi,

is there some documentation available of how to use GPIO on a Raspberry
Pi B+ than man gpio, man gpioctl etc?

All the documentation I found was for Linux. Of course, I would like to
avoid Linux.

Erich

From gjb at FreeBSD.org  Mon Sep 29 01:12:49 2014
From: gjb at FreeBSD.org (Glen Barber)
Date: Sun, 28 Sep 2014 21:12:43 -0400
Subject: FreeBSD 10.1-BETA3 Now Available
In-Reply-To: <20140929090149.34aa1927@X220.alogt.com>
References: <20140928155118.GA75063@hub.FreeBSD.org>
 <20140929090149.34aa1927@X220.alogt.com>
Message-ID: <20140929011243.GF75063@hub.FreeBSD.org>

[Added freebsd-arm@ and BCC'd re@]

On Mon, Sep 29, 2014 at 09:01:49AM +0800, Erich Dollansky wrote:
> On Sun, 28 Sep 2014 11:51:18 -0400
> Glen Barber <gjb at FreeBSD.org> wrote:
> > The third BETA build of the 10.1-RELEASE release cycle is now
> > available on the FTP servers for the amd64, armv6, i386, ia64,
> > powerpc, powerpc64 and sparc64 architectures.
> > 
> is the Raspberry B+ supported or just the Raspberry B?
> 

I am unsure, and do not have access to a RaspberryPi B+ to test.  The
freebsd-arm@ list is the best place to find the answer to this question.

Glen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140928/e7ff8ab0/attachment.sig>

From erichsfreebsdlist at alogt.com  Mon Sep 29 01:28:48 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Mon, 29 Sep 2014 09:28:35 +0800
Subject: FreeBSD 10.1-BETA3 Now Available
In-Reply-To: <20140929011243.GF75063@hub.FreeBSD.org>
References: <20140928155118.GA75063@hub.FreeBSD.org>
 <20140929090149.34aa1927@X220.alogt.com>
 <20140929011243.GF75063@hub.FreeBSD.org>
Message-ID: <20140929092835.6313304a@X220.alogt.com>

Hi,

On Sun, 28 Sep 2014 21:12:43 -0400
Glen Barber <gjb at FreeBSD.org> wrote:

> [Added freebsd-arm@ and BCC'd re@]
> 
> On Mon, Sep 29, 2014 at 09:01:49AM +0800, Erich Dollansky wrote:
> > On Sun, 28 Sep 2014 11:51:18 -0400
> > Glen Barber <gjb at FreeBSD.org> wrote:
> > > The third BETA build of the 10.1-RELEASE release cycle is now
> > > available on the FTP servers for the amd64, armv6, i386, ia64,
> > > powerpc, powerpc64 and sparc64 architectures.
> > > 
> > is the Raspberry B+ supported or just the Raspberry B?
> > 
> 
> I am unsure, and do not have access to a RaspberryPi B+ to test.  The
> freebsd-arm@ list is the best place to find the answer to this
> question.
> 
I have one. I will give the build a try after the machine has finished
its current task. This can take days.

Erich

From gjb at FreeBSD.org  Mon Sep 29 02:36:21 2014
From: gjb at FreeBSD.org (Glen Barber)
Date: Sun, 28 Sep 2014 22:36:16 -0400
Subject: FreeBSD 10.1-BETA3 Now Available
In-Reply-To: <20140929092835.6313304a@X220.alogt.com>
References: <20140928155118.GA75063@hub.FreeBSD.org>
 <20140929090149.34aa1927@X220.alogt.com>
 <20140929011243.GF75063@hub.FreeBSD.org>
 <20140929092835.6313304a@X220.alogt.com>
Message-ID: <20140929023616.GG75063@hub.FreeBSD.org>

On Mon, Sep 29, 2014 at 09:28:35AM +0800, Erich Dollansky wrote:
> On Sun, 28 Sep 2014 21:12:43 -0400
> Glen Barber <gjb at FreeBSD.org> wrote:
> > > is the Raspberry B+ supported or just the Raspberry B?
> > 
> > I am unsure, and do not have access to a RaspberryPi B+ to test.  The
> > freebsd-arm@ list is the best place to find the answer to this
> > question.
> > 
> I have one. I will give the build a try after the machine has finished
> its current task. This can take days.
> 

Why not try the images already available here?

http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/

Glen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140928/8375c101/attachment.sig>

From erichsfreebsdlist at alogt.com  Mon Sep 29 03:33:09 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Mon, 29 Sep 2014 11:32:30 +0800
Subject: FreeBSD 10.1-BETA3 Now Available
In-Reply-To: <20140929023616.GG75063@hub.FreeBSD.org>
References: <20140928155118.GA75063@hub.FreeBSD.org>
 <20140929090149.34aa1927@X220.alogt.com>
 <20140929011243.GF75063@hub.FreeBSD.org>
 <20140929092835.6313304a@X220.alogt.com>
 <20140929023616.GG75063@hub.FreeBSD.org>
Message-ID: <20140929113230.144be5da@X220.alogt.com>

Hi,

On Sun, 28 Sep 2014 22:36:16 -0400
Glen Barber <gjb at FreeBSD.org> wrote:

> On Mon, Sep 29, 2014 at 09:28:35AM +0800, Erich Dollansky wrote:
> > On Sun, 28 Sep 2014 21:12:43 -0400
> > Glen Barber <gjb at FreeBSD.org> wrote:
> > > > is the Raspberry B+ supported or just the Raspberry B?
> > > 
> > > I am unsure, and do not have access to a RaspberryPi B+ to test.
> > > The freebsd-arm@ list is the best place to find the answer to this
> > > question.
> > > 
> > I have one. I will give the build a try after the machine has
> > finished its current task. This can take days.
> > 
> 
> Why not try the images already available here?
> 
> http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/

yes, why not. I downloaded it already and still start to test it later.

Is there somewhere a documentation of how this image was build?

Erich

From jmg at funkthat.com  Mon Sep 29 04:01:28 2014
From: jmg at funkthat.com (John-Mark Gurney)
Date: Sun, 28 Sep 2014 21:01:26 -0700
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <542559BC.7090100@gmail.com>
References: <542559BC.7090100@gmail.com>
Message-ID: <20140929040126.GG43300@funkthat.com>

Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
> This might be part of the weird FFS issues the Dreamplug has and no-one 
> knows why they're happening.

Are you running w/ FFS journaling?  If so, try turning it off, but
keeping softupdates on..

> data_abort_handler() at data_abort_handler+0x5c0
>          pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
>          sp = 0xde019898  fp = 0xde019a20
>          r4 = 0xffffffff  r5 = 0xffff1004
>          r6 = 0xc3f3f6c0  r7 = 0x00001000
>          r8 = 0xc443e880  r9 = 0x00000000
>         r10 = 0xc3d69000
> exception_exit() at exception_exit
>          pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>          sp = 0xde0198e8  fp = 0xde019a20
>          r0 = 0xd0238120  r1 = 0x00000e60
>          r2 = 0x00000000  r3 = 0x00000000
>          r4 = 0x00000120  r5 = 0x00000000
>          r6 = 0xc3f3f6c0  r7 = 0x00001000
>          r8 = 0xc443e880  r9 = 0x00000000
>         r10 = 0xc3d69000 r12 = 0xd0238120
> memset() at memset+0x48
>          pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>          sp = 0xde0198e8  fp = 0xde019a20
> Unwind failure (no registers changed)

No more beyond this?   If you could run addr2line on 0xc0d53828 so
that we know where in ffs_truncate it's failing, that'd be very
nice...

> The sad thing is, that with fsck broken for the dreamplug, I have to 
> re-format the disk, reinstall everything and recreate the config files 
> which I didn't manage to copy to a safe place beforehand :-(
> 
> Before I do that I'll leave the system in debugging mode for a few days, 
> in case someone can help and needs some more information.
> 
> Cheers,
> 
> Mat
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From jmg at funkthat.com  Mon Sep 29 04:05:34 2014
From: jmg at funkthat.com (John-Mark Gurney)
Date: Sun, 28 Sep 2014 21:05:30 -0700
Subject: MK_ARM_EABI to retire in current
In-Reply-To: <20140928121818.741e7e7e@bender.lan>
References: <C66667D9-2F5E-44E0-AF04-E9DFE70BAF5A@gmail.com>
 <20140928121818.741e7e7e@bender.lan>
Message-ID: <20140929040530.GH43300@funkthat.com>

Andrew Turner wrote this message on Sun, Sep 28, 2014 at 12:18 +0100:
> On Mon, 19 May 2014 09:40:33 -0600
> Warner Losh <imp at bsdimp.com> wrote:
> 
> > Greetings,
> > 
> > MK_ARM_EABI is going to die in current. It is the default for all
> > platforms currently. I?m eliminating it as a build option. It must
> > die because it invisibly (to uname) effects the ABI.
> > 
> > So, to that end, I see two options:
> > 
> > (1) Retire and remove oabi support.
> > (2) Retain oabi support, but change its name to armo and armoeb.
> > 
> > The rough consensus of arm developers I?ve polled now, and in the
> > past, is that we just let oabi support die now that EABI support is
> > working for everybody.
> > 
> > Before I pull the trigger on this, however, I must ask if anybody has
> > a problem with my doing option (1), and if so, what keeps you using
> > oabi.
> > 
> > Comments?
> 
> As far as I know all the problems with ARM EABI on armeb mentioned
> in this thread have been fixed. I think we should now retire the oabi
> support and remove MK_ARM_EABI.

Yeh, I don't know of any issues, though my AVILA board isn't 100% stable
as I did get this recently:
panic: Fatal abort
panic: mtx_lock() by idle thread 0xc0e66320 on sleep mutex eventhandler @ /usr/src.avila/sys/kern/subr_eventhandler.c:251

But, I don't think this is related to EABI...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From erichsfreebsdlist at alogt.com  Mon Sep 29 04:33:34 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Mon, 29 Sep 2014 12:33:27 +0800
Subject: FreeBSD 10.1-BETA3 Now Available
In-Reply-To: <20140929023616.GG75063@hub.FreeBSD.org>
References: <20140928155118.GA75063@hub.FreeBSD.org>
 <20140929090149.34aa1927@X220.alogt.com>
 <20140929011243.GF75063@hub.FreeBSD.org>
 <20140929092835.6313304a@X220.alogt.com>
 <20140929023616.GG75063@hub.FreeBSD.org>
Message-ID: <20140929123327.6ab0207c@X220.alogt.com>

Hi,

On Sun, 28 Sep 2014 22:36:16 -0400
Glen Barber <gjb at FreeBSD.org> wrote:

> On Mon, Sep 29, 2014 at 09:28:35AM +0800, Erich Dollansky wrote:
> > On Sun, 28 Sep 2014 21:12:43 -0400
> > Glen Barber <gjb at FreeBSD.org> wrote:
> > > > is the Raspberry B+ supported or just the Raspberry B?
> > > 
> > > I am unsure, and do not have access to a RaspberryPi B+ to test.
> > > The freebsd-arm@ list is the best place to find the answer to this
> > > question.
> > > 
> > I have one. I will give the build a try after the machine has
> > finished its current task. This can take days.
> > 
> 
> Why not try the images already available here?
> 
> http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/
> 
I have tried it now several times. All with the same result.

The machine seems to start as the partition is fully expanded. The USB
interface does not seem to be recognised.

As I do not have monitor cable here, I am not able to do further
testing.

I will try now to compile the CURRENT sources and see what will happen
there.

Erich

From shigeru at os-hackers.jp  Mon Sep 29 05:46:02 2014
From: shigeru at os-hackers.jp (YAMAMOTO Shigeru)
Date: Mon, 29 Sep 2014 14:27:12 +0900 (JST)
Subject: FreeBSD 10.1-BETA3 Now Available
In-Reply-To: <20140929123327.6ab0207c@X220.alogt.com>
References: <20140929092835.6313304a@X220.alogt.com>
 <20140929023616.GG75063@hub.FreeBSD.org>
 <20140929123327.6ab0207c@X220.alogt.com>
Message-ID: <20140929.142712.117419748410715004.shigeru@os-hackers.jp>


Hi,

>>>>> "Erich" == Erich Dollansky <erichsfreebsdlist at alogt.com> writes:
> On Sun, 28 Sep 2014 22:36:16 -0400
> Glen Barber <gjb at FreeBSD.org> wrote:
> > Why not try the images already available here?
> > 
> > http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/
> > 
> I have tried it now several times. All with the same result.
> 
> The machine seems to start as the partition is fully expanded. The USB
> interface does not seem to be recognised.

It seems me it is same problem,
http://lists.freebsd.org/pipermail/freebsd-arm/2014-July/008872.html

Please try to use newer firmware image in your SD image.

Thanks,
---
YAMAMOTO Shigeru <shigeru at os-hackers.jp>

From erichsfreebsdlist at alogt.com  Mon Sep 29 05:52:49 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Mon, 29 Sep 2014 13:52:32 +0800
Subject: FreeBSD 10.1-BETA3 Now Available
In-Reply-To: <20140929.142712.117419748410715004.shigeru@os-hackers.jp>
References: <20140929092835.6313304a@X220.alogt.com>
 <20140929023616.GG75063@hub.FreeBSD.org>
 <20140929123327.6ab0207c@X220.alogt.com>
 <20140929.142712.117419748410715004.shigeru@os-hackers.jp>
Message-ID: <20140929135232.07844765@X220.alogt.com>

Hi,

On Mon, 29 Sep 2014 14:27:12 +0900 (JST)
YAMAMOTO Shigeru <shigeru at os-hackers.jp> wrote:

> >>>>> "Erich" == Erich Dollansky <erichsfreebsdlist at alogt.com> writes:
> > On Sun, 28 Sep 2014 22:36:16 -0400
> > Glen Barber <gjb at FreeBSD.org> wrote:
> > > Why not try the images already available here?
> > > 
> > > http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/
> > > 
> > I have tried it now several times. All with the same result.
> > 
> > The machine seems to start as the partition is fully expanded. The
> > USB interface does not seem to be recognised.
> 
> It seems me it is same problem,
> http://lists.freebsd.org/pipermail/freebsd-arm/2014-July/008872.html
> 
> Please try to use newer firmware image in your SD image.
> 
it seems that this does not solve the problem. I have copied the
firmware from a media with a running system to the new image but it did
not boot properly either.

I am currently compiling 11 on the Raspberry itself. Let me see how far
I will come with it.

Erich

From erichsfreebsdlist at alogt.com  Mon Sep 29 05:54:26 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Mon, 29 Sep 2014 13:54:19 +0800
Subject: FreeBSD 10.1-BETA3 Now Available
In-Reply-To: <20140929.142712.117419748410715004.shigeru@os-hackers.jp>
References: <20140929092835.6313304a@X220.alogt.com>
 <20140929023616.GG75063@hub.FreeBSD.org>
 <20140929123327.6ab0207c@X220.alogt.com>
 <20140929.142712.117419748410715004.shigeru@os-hackers.jp>
Message-ID: <20140929135419.0eb10c46@X220.alogt.com>

Hi,

On Mon, 29 Sep 2014 14:27:12 +0900 (JST)
YAMAMOTO Shigeru <shigeru at os-hackers.jp> wrote:

> 
> It seems me it is same problem,
> http://lists.freebsd.org/pipermail/freebsd-arm/2014-July/008872.html
> 
> Please try to use newer firmware image in your SD image.
> 
I forgot to mention that the running Raspberry is using you image.

Erich

From mattia.rossi.mailinglists at gmail.com  Mon Sep 29 08:42:33 2014
From: mattia.rossi.mailinglists at gmail.com (Mattia Rossi)
Date: Mon, 29 Sep 2014 10:42:28 +0200
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <20140929040126.GG43300@funkthat.com>
References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com>
Message-ID: <54291B74.5010307@gmail.com>


Am 29.09.2014 06:01, schrieb John-Mark Gurney:
> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
>> This might be part of the weird FFS issues the Dreamplug has and no-one
>> knows why they're happening.
> Are you running w/ FFS journaling?  If so, try turning it off, but
> keeping softupdates on..
No journaling, no softupdates. I'll try enabling softupdates next time. 
don't know if it will panic though
>
>> data_abort_handler() at data_abort_handler+0x5c0
>>           pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
>>           sp = 0xde019898  fp = 0xde019a20
>>           r4 = 0xffffffff  r5 = 0xffff1004
>>           r6 = 0xc3f3f6c0  r7 = 0x00001000
>>           r8 = 0xc443e880  r9 = 0x00000000
>>          r10 = 0xc3d69000
>> exception_exit() at exception_exit
>>           pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>>           sp = 0xde0198e8  fp = 0xde019a20
>>           r0 = 0xd0238120  r1 = 0x00000e60
>>           r2 = 0x00000000  r3 = 0x00000000
>>           r4 = 0x00000120  r5 = 0x00000000
>>           r6 = 0xc3f3f6c0  r7 = 0x00001000
>>           r8 = 0xc443e880  r9 = 0x00000000
>>          r10 = 0xc3d69000 r12 = 0xd0238120
>> memset() at memset+0x48
>>           pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>>           sp = 0xde0198e8  fp = 0xde019a20
>> Unwind failure (no registers changed)
> No more beyond this?   If you could run addr2line on 0xc0d53828 so
> that we know where in ffs_truncate it's failing, that'd be very
> nice...
So I was trying to save the coredump in  order to reboot and run 
addr2line, but that failed:

Physical memory: 504 MB
Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f 20 
00 00 01 00
(da0:umass-sim0:0:0:0): CAM status: Resource Unavailable
(da0:umass-sim0:0:0:0): Error 5, Retries exhausted
Aborting dump due to I/O error.

** DUMP FAILED (ERROR 5) **

So I guess this error is related to the CAM errors I'm getting from time 
to time. I was hoping that those errors were related to the INVARIANTS 
option that slowed down the system and thus might have triggered CAM 
errors, but obviously the SD Card seems to be the real issue here.
So no crashdump for further analysis.

Interestingly the CAM errors didn't show up on the terminal as other 
times, the kernel just panicked straight away.

But I've got the addr2line output, even though I'm not sure it makes any 
difference:

addr2line -f -e /mnt/kernel.debug 0xc0d53828

ffs_truncate
/usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321

>> The sad thing is, that with fsck broken for the dreamplug, I have to
>> re-format the disk, reinstall everything and recreate the config files
>> which I didn't manage to copy to a safe place beforehand :-(
Didn't get around yet on checking whether the fsck issue persists if 
everything is compiled with gcc. Will take a bit, as I'm going to be on 
holidays for the next one and a half weeks. Fact is though, fsck is 
broken on the Dreamplug (ARMv5TE), at least when run on EVERY device 
that is attached via USB and if compiled with CLANG.
>>
>> Before I do that I'll leave the system in debugging mode for a few days,
>> in case someone can help and needs some more information.
Currently I've run fsck on all the disks/cards that had a working world 
for the dreamplug on it, so they're all gone. Can't do eny debugging 
atm. I'll let you know hoe the gcc build goes once I'm back from 
holidays though.

Cheers,

Mat


From ian at FreeBSD.org  Mon Sep 29 13:49:22 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Mon, 29 Sep 2014 07:49:11 -0600
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <20140929040126.GG43300@funkthat.com>
References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com>
Message-ID: <1411998551.66615.328.camel@revolution.hippie.lan>

On Sun, 2014-09-28 at 21:01 -0700, John-Mark Gurney wrote:
> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
> > This might be part of the weird FFS issues the Dreamplug has and no-one 
> > knows why they're happening.
> 
> Are you running w/ FFS journaling?  If so, try turning it off, but
> keeping softupdates on..
> 

It's not an SU+J problem, or even an SU problem.  fsck finds
non-existant errors on filesystems known to be clean, and if
write-enabled it will corrupt the good filesystem when attempting to
correct those "errors".  This is on armv4 only, not v6.  I tested with
and without softupdates on.  I tested with UFS1 and UFS2 filesystems.
You can even do a newfs followed immediately by an fsck on it and it
will corrupt the fs.

The one thing I haven't done is opened a PR for this.

> > data_abort_handler() at data_abort_handler+0x5c0
> >          pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
> >          sp = 0xde019898  fp = 0xde019a20
> >          r4 = 0xffffffff  r5 = 0xffff1004
> >          r6 = 0xc3f3f6c0  r7 = 0x00001000
> >          r8 = 0xc443e880  r9 = 0x00000000
> >         r10 = 0xc3d69000
> > exception_exit() at exception_exit
> >          pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
> >          sp = 0xde0198e8  fp = 0xde019a20
> >          r0 = 0xd0238120  r1 = 0x00000e60
> >          r2 = 0x00000000  r3 = 0x00000000
> >          r4 = 0x00000120  r5 = 0x00000000
> >          r6 = 0xc3f3f6c0  r7 = 0x00001000
> >          r8 = 0xc443e880  r9 = 0x00000000
> >         r10 = 0xc3d69000 r12 = 0xd0238120
> > memset() at memset+0x48
> >          pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
> >          sp = 0xde0198e8  fp = 0xde019a20
> > Unwind failure (no registers changed)
> 
> No more beyond this?   If you could run addr2line on 0xc0d53828 so
> that we know where in ffs_truncate it's failing, that'd be very
> nice...
> 

Some time in the past 4-6 weeks something has gone wrong with kernel
stack backtraces.  Sometimes you get a full useful traceback, and more
often it ends at the function that triggered the exception, always with
a "no registers changed" message.

-- Ian

> > The sad thing is, that with fsck broken for the dreamplug, I have to 
> > re-format the disk, reinstall everything and recreate the config files 
> > which I didn't manage to copy to a safe place beforehand :-(
> > 
> > Before I do that I'll leave the system in debugging mode for a few days, 
> > in case someone can help and needs some more information.
> > 
> > Cheers,
> > 
> > Mat



From udvzsolt at gmail.com  Mon Sep 29 14:06:15 2014
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Mon, 29 Sep 2014 16:06:13 +0200
Subject: Build RPI packages on a 64bit host
Message-ID: <CADtCJqr-b4ad1hXmE3R6W4G=epmaJvmGgjwKAKzVAyBiEGvjmw@mail.gmail.com>

Hi list!

I've trying [1] to build packages for Raspberry Pi (B). I've an
installed amd64 FreeBSD on my laptop.
"For 32-bit targets (i.e. armv6) use an 32-bit host (i.e. i386) or compat-32."
How can I use "compat-32"? Should I create a 32-bit chroot, and inside
this chroot should I create a build system for arm as written at [1]?

Thanks for helping.

Zsolt


[1] https://wiki.freebsd.org/QemuUserModeHowTo

From gjb at FreeBSD.org  Mon Sep 29 14:24:50 2014
From: gjb at FreeBSD.org (Glen Barber)
Date: Mon, 29 Sep 2014 10:24:45 -0400
Subject: FreeBSD 10.1-BETA3 Now Available
In-Reply-To: <20140929113230.144be5da@X220.alogt.com>
References: <20140928155118.GA75063@hub.FreeBSD.org>
 <20140929090149.34aa1927@X220.alogt.com>
 <20140929011243.GF75063@hub.FreeBSD.org>
 <20140929092835.6313304a@X220.alogt.com>
 <20140929023616.GG75063@hub.FreeBSD.org>
 <20140929113230.144be5da@X220.alogt.com>
Message-ID: <20140929142445.GQ75063@hub.FreeBSD.org>

On Mon, Sep 29, 2014 at 11:32:30AM +0800, Erich Dollansky wrote:
> On Sun, 28 Sep 2014 22:36:16 -0400
> Glen Barber <gjb at FreeBSD.org> wrote:
> > On Mon, Sep 29, 2014 at 09:28:35AM +0800, Erich Dollansky wrote:
> > Why not try the images already available here?
> > 
> > http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/
> 
> yes, why not. I downloaded it already and still start to test it later.
> 
> Is there somewhere a documentation of how this image was build?
> 

The arm images are currently built using Crochet.

The documentation is in the README.md file here:

    https://github.com/kientzle/crochet-freebsd

Glen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140929/0dd390f2/attachment.sig>

From bugzilla-noreply at freebsd.org  Mon Sep 29 16:28:28 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 29 Sep 2014 16:28:29 +0000
Subject: [Bug 193981] panic: vtbuf_fill_locked begin.tp_row 0 must be <
 screen height 0 on Raspberry PI
In-Reply-To: <bug-193981-7@https.bugs.freebsd.org/bugzilla/>
References: <bug-193981-7@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-193981-7-Z9Fb2YpvS5@https.bugs.freebsd.org/bugzilla/>

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193981

--- Comment #1 from Danilo Egea Gondolfo <danilo at FreeBSD.org> ---
Same problem on HEAD r272282.

-- 
You are receiving this mail because:
You are the assignee for the bug.

From lists.br at gmail.com  Mon Sep 29 19:27:28 2014
From: lists.br at gmail.com (Luiz Otavio O Souza)
Date: Mon, 29 Sep 2014 16:27:26 -0300
Subject: Documentation for using GPIO
In-Reply-To: <20140929080337.46bbb5a3@X220.alogt.com>
References: <20140929080337.46bbb5a3@X220.alogt.com>
Message-ID: <CAB=2f8xaB0UtwHRisU=86RU3U1mczaxKP=QC=HjgbHq0EL60Nw@mail.gmail.com>

On 28 September 2014 21:03, Erich Dollansky wrote:
> Hi,
>
> is there some documentation available of how to use GPIO on a Raspberry
> Pi B+ than man gpio, man gpioctl etc?
>
> All the documentation I found was for Linux. Of course, I would like to
> avoid Linux.

Hi Erich,

Unfortunately not, there is the Wiki page
(https://wiki.freebsd.org/FreeBSD/GPIO) but it doesn't add much.

But we can try to help you whenever possible, just post your questions
and we'll try to address them.

Regards,
Luiz

From erichsfreebsdlist at alogt.com  Tue Sep 30 00:16:40 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Tue, 30 Sep 2014 08:16:18 +0800
Subject: Documentation for using GPIO
In-Reply-To: <CAB=2f8xaB0UtwHRisU=86RU3U1mczaxKP=QC=HjgbHq0EL60Nw@mail.gmail.com>
References: <20140929080337.46bbb5a3@X220.alogt.com>
 <CAB=2f8xaB0UtwHRisU=86RU3U1mczaxKP=QC=HjgbHq0EL60Nw@mail.gmail.com>
Message-ID: <20140930081618.122a0c79@X220.alogt.com>

Hi Luiz,

On Mon, 29 Sep 2014 16:27:26 -0300
Luiz Otavio O Souza <lists.br at gmail.com> wrote:

> > is there some documentation available of how to use GPIO on a
> > Raspberry Pi B+ than man gpio, man gpioctl etc?
> >
> Unfortunately not, there is the Wiki page
> (https://wiki.freebsd.org/FreeBSD/GPIO) but it doesn't add much.
> 
I ave read this.

> But we can try to help you whenever possible, just post your questions
> and we'll try to address them.

I am currently working on a C program which should use GPIO to switch
relais and read the state of switches via GPIO. I would like to make
this program as simple as possible by creating first a layer which
provides then functions like set (Pin), reset (Pin)  and read (Pin)
only. Of course plus the things needed to open, close and configure the
interface.

The best I have found until now are the sources of gpioctl. I am
currently looking at the source.

Is this the best start?

Erich

From tom at khubla.com  Tue Sep 30 00:43:20 2014
From: tom at khubla.com (Tom Everett)
Date: Mon, 29 Sep 2014 18:37:53 -0600
Subject: Documentation for using GPIO
In-Reply-To: <20140930081618.122a0c79@X220.alogt.com>
References: <20140929080337.46bbb5a3@X220.alogt.com>
 <CAB=2f8xaB0UtwHRisU=86RU3U1mczaxKP=QC=HjgbHq0EL60Nw@mail.gmail.com>
 <20140930081618.122a0c79@X220.alogt.com>
Message-ID: <CAB3ij4BYHWVDAXPe+CUXrCb=Ar65oBjHDf0eBzzk5Z4W8Zvqpg@mail.gmail.com>

I published a simple example here.

https://github.com/teverett/gpioexample

On Mon, Sep 29, 2014 at 6:16 PM, Erich Dollansky <
erichsfreebsdlist at alogt.com> wrote:

> Hi Luiz,
>
> On Mon, 29 Sep 2014 16:27:26 -0300
> Luiz Otavio O Souza <lists.br at gmail.com> wrote:
>
> > > is there some documentation available of how to use GPIO on a
> > > Raspberry Pi B+ than man gpio, man gpioctl etc?
> > >
> > Unfortunately not, there is the Wiki page
> > (https://wiki.freebsd.org/FreeBSD/GPIO) but it doesn't add much.
> >
> I ave read this.
>
> > But we can try to help you whenever possible, just post your questions
> > and we'll try to address them.
>
> I am currently working on a C program which should use GPIO to switch
> relais and read the state of switches via GPIO. I would like to make
> this program as simple as possible by creating first a layer which
> provides then functions like set (Pin), reset (Pin)  and read (Pin)
> only. Of course plus the things needed to open, close and configure the
> interface.
>
> The best I have found until now are the sources of gpioctl. I am
> currently looking at the source.
>
> Is this the best start?
>
> Erich
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>



-- 
A better world shall emerge based on faith and understanding  - Douglas
MacArthur

From erichsfreebsdlist at alogt.com  Tue Sep 30 01:37:25 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Tue, 30 Sep 2014 09:37:13 +0800
Subject: Documentation for using GPIO
In-Reply-To: <CAB3ij4BYHWVDAXPe+CUXrCb=Ar65oBjHDf0eBzzk5Z4W8Zvqpg@mail.gmail.com>
References: <20140929080337.46bbb5a3@X220.alogt.com>
 <CAB=2f8xaB0UtwHRisU=86RU3U1mczaxKP=QC=HjgbHq0EL60Nw@mail.gmail.com>
 <20140930081618.122a0c79@X220.alogt.com>
 <CAB3ij4BYHWVDAXPe+CUXrCb=Ar65oBjHDf0eBzzk5Z4W8Zvqpg@mail.gmail.com>
Message-ID: <20140930093713.438c9016@X220.alogt.com>

Hi,

On Mon, 29 Sep 2014 18:37:53 -0600
Tom Everett <tom at khubla.com> wrote:

> I published a simple example here.
> 
> https://github.com/teverett/gpioexample
> 
thanks. I already have it on my machine.

Your own site has many other useful information too.

One general note. At least for me, it is very often very difficult when
things are very simple but the simplicity is not stated in
documentation.

Erich


> On Mon, Sep 29, 2014 at 6:16 PM, Erich Dollansky <
> erichsfreebsdlist at alogt.com> wrote:
> 
> > Hi Luiz,
> >
> > On Mon, 29 Sep 2014 16:27:26 -0300
> > Luiz Otavio O Souza <lists.br at gmail.com> wrote:
> >
> > > > is there some documentation available of how to use GPIO on a
> > > > Raspberry Pi B+ than man gpio, man gpioctl etc?
> > > >
> > > Unfortunately not, there is the Wiki page
> > > (https://wiki.freebsd.org/FreeBSD/GPIO) but it doesn't add much.
> > >
> > I ave read this.
> >
> > > But we can try to help you whenever possible, just post your
> > > questions and we'll try to address them.
> >
> > I am currently working on a C program which should use GPIO to
> > switch relais and read the state of switches via GPIO. I would like
> > to make this program as simple as possible by creating first a
> > layer which provides then functions like set (Pin), reset (Pin)
> > and read (Pin) only. Of course plus the things needed to open,
> > close and configure the interface.
> >
> > The best I have found until now are the sources of gpioctl. I am
> > currently looking at the source.
> >
> > Is this the best start?
> >
> > Erich
> > _______________________________________________
> > freebsd-arm at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > To unsubscribe, send any mail to
> > "freebsd-arm-unsubscribe at freebsd.org"
> >
> 
> 
> 


From bugzilla-noreply at freebsd.org  Tue Sep 30 01:48:49 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 30 Sep 2014 01:48:49 +0000
Subject: [Bug 193981] panic: vtbuf_fill_locked begin.tp_row 0 must be <
 screen height 0 on Raspberry PI
In-Reply-To: <bug-193981-7@https.bugs.freebsd.org/bugzilla/>
References: <bug-193981-7@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-193981-7-qphK6Cq8F4@https.bugs.freebsd.org/bugzilla/>

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193981

--- Comment #2 from Danilo Egea Gondolfo <danilo at FreeBSD.org> ---
I reverted just r271973 (on 10-stable) and the system boots again.

-- 
You are receiving this mail because:
You are the assignee for the bug.

From russ.haley at gmail.com  Tue Sep 30 03:14:26 2014
From: russ.haley at gmail.com (Russell Haley)
Date: Mon, 29 Sep 2014 20:14:24 -0700
Subject: Digi CCWMX53
In-Reply-To: <A4CEAFC3-446E-4D14-8F3B-1CDC92C65829@kientzle.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <A4CEAFC3-446E-4D14-8F3B-1CDC92C65829@kientzle.com>
Message-ID: <CABx9NuT__11qgvP7HBbZE1hykBh+G2P3YBOX75+nh=01z3US9g@mail.gmail.com>

Tim,

> FreeBSD source has an 'xdev' target that builds and installs a set of
cross-tools.  In particular, it can install cross-versions of the same GCC
or clang used by the rest of FreeBSD.

Where can I find more information on cross compiling on FreeBSD?

Thanks
Russ

On Sat, Sep 27, 2014 at 11:53 AM, Tim Kientzle <tim at kientzle.com> wrote:

>
> On Sep 26, 2014, at 10:38 PM, Russell Haley <russ.haley at gmail.com> wrote:
>
> > 1) Can anyone give me the correct u-boot enviroment variables or
> reference
> > to the u-boot process to boot the completed freebsd kernel. Specifically
> on
> > a CCWMX53 if possible, but I have linux references to port from. Where
> > would I look for an example?
>
> There are two general approaches being used:
>
> 1) Have U-Boot load and boot the kernel directly.  This can sometimes be
> done with an unmodified Linux U-Boot.
>
> 2) Have U-Boot load FreeBSDs scriptable 'ubldr' and have that load the
> kernel.  This provides more flexibility in the boot process but usually
> requires rebuilding U-Boot.  In particular, you'll need to:
>    * Add CONFIG_CMD_ELF option to U-Boot so it can load `ubldr' which is
> an ELF executable
>    * Add CONFIG_CMD_API option to U-Boot so `ubldr' can access U-Boot's
> drivers for hardware access (`ubldr' itself has to be compiled for each
> board to adjust the load address but is otherwise completely generic).
>    * Adjust the U-Boot startup scripts to set FDT environment variables
> and load ubldr.  You can look at the U-Boot patches for various boards
> supported by Crochet to see how this has been done elsewhere:
>    github.com/kientlze/crochet-freebsd
>
>
> > 2) Do I need to create a cross compiler? Reference 1 says yes, reference
> > two says no. Help!
>
> In most cases, the FreeBSD build system will build a cross-compiler for
> it's own use, so you generally don't need to install a cross compiler to
> cross-build FreeBSD proper.  However, U-Boot is not part of FreeBSD so you
> may need to install a separate cross-compiler to build that.
>
> >
> > Ref.1 Build  a cross compiler
> > https://wiki.freebsd.org/FreeBSD/arm/ArndaleBoard
>
> This is using a cross-compiler from ports to build U-Boot.  It uses the
> FreeBSD build machinery to cross-build the FreeBSD kernel and world.  (When
> you specify TARGET_ARCH, FreeBSD's 'buildworld' target will build and use a
> suitable cross-compiler.  Also, 'buildkernel' will reuse the cross-compiler
> built by 'buildworld', so you do not need 'kernel-toolchain' as long as you
> 'buildworld' first.)
>
> >
> > Ref 2. No cross compiler/ make toolchain
> > https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD
>
> This example only talks about building *world*, and the 'buildworld'
> target builds the necessary cross-tools transparently.  In particular,
> since it doesn't talk about building out-of-tree boot loaders such as
> U-Boot, it does not need to talk about building/installing an explicit
> cross-compiler.
>
> For cross-compilers, you have three options:
>  * Ports.
>  * After a successful buildworld, you can 'make TARGET=xyz ... buildenv'
> to get a shell with suitable path settings to reuse the cross-tools from
> the buildworld stage.  Use 'buildenvvar' to just get the environment for
> use in scripts.
>  * FreeBSD source has an 'xdev' target that builds and installs a set of
> cross-tools.  In particular, it can install cross-versions of the same GCC
> or clang used by the rest of FreeBSD.  This facility has changed a lot
> recently, so ask if you need the current command line.
>
> Hope this clarifies things,
>
> Tim
>
>

From lists.br at gmail.com  Tue Sep 30 04:41:40 2014
From: lists.br at gmail.com (Luiz Otavio O Souza)
Date: Tue, 30 Sep 2014 01:41:38 -0300
Subject: Documentation for using GPIO
In-Reply-To: <20140930081618.122a0c79@X220.alogt.com>
References: <20140929080337.46bbb5a3@X220.alogt.com>
 <CAB=2f8xaB0UtwHRisU=86RU3U1mczaxKP=QC=HjgbHq0EL60Nw@mail.gmail.com>
 <20140930081618.122a0c79@X220.alogt.com>
Message-ID: <CAB=2f8yxJtUe=NmKSdGMcGTXUPFaF_QySvKcj0D=-KHwAp=PMg@mail.gmail.com>

On 29 September 2014 21:16, Erich Dollansky wrote:
> Hi Luiz,
>
> On Mon, 29 Sep 2014 16:27:26 -0300
> Luiz Otavio O Souza wrote:
>
>> > is there some documentation available of how to use GPIO on a
>> > Raspberry Pi B+ than man gpio, man gpioctl etc?
>> >
>> Unfortunately not, there is the Wiki page
>> (https://wiki.freebsd.org/FreeBSD/GPIO) but it doesn't add much.
>>
> I ave read this.
>
>> But we can try to help you whenever possible, just post your questions
>> and we'll try to address them.
>
> I am currently working on a C program which should use GPIO to switch
> relais and read the state of switches via GPIO. I would like to make
> this program as simple as possible by creating first a layer which
> provides then functions like set (Pin), reset (Pin)  and read (Pin)
> only. Of course plus the things needed to open, close and configure the
> interface.
>
> The best I have found until now are the sources of gpioctl. I am
> currently looking at the source.
>
> Is this the best start?

You can use the excellent rpaulo's libgpio:

https://bitbucket.org/rpaulo/libgpio/src/1dfe793d0b0cd6caff2e196cf667a5c06bbade8d/libgpio.h?at=default

It provides all the GPIO low level functions in a clear and simple way.

Luiz

From erichsfreebsdlist at alogt.com  Tue Sep 30 05:02:37 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Tue, 30 Sep 2014 13:02:29 +0800
Subject: Documentation for using GPIO
In-Reply-To: <CAB=2f8yxJtUe=NmKSdGMcGTXUPFaF_QySvKcj0D=-KHwAp=PMg@mail.gmail.com>
References: <20140929080337.46bbb5a3@X220.alogt.com>
 <CAB=2f8xaB0UtwHRisU=86RU3U1mczaxKP=QC=HjgbHq0EL60Nw@mail.gmail.com>
 <20140930081618.122a0c79@X220.alogt.com>
 <CAB=2f8yxJtUe=NmKSdGMcGTXUPFaF_QySvKcj0D=-KHwAp=PMg@mail.gmail.com>
Message-ID: <20140930130229.610ef43e@X220.alogt.com>

Hi Luiz,

On Tue, 30 Sep 2014 01:41:38 -0300
Luiz Otavio O Souza <lists.br at gmail.com> wrote:

> On 29 September 2014 21:16, Erich Dollansky wrote:
> > On Mon, 29 Sep 2014 16:27:26 -0300
> > Luiz Otavio O Souza wrote:
> >
> >> > is there some documentation available of how to use GPIO on a
> >> > Raspberry Pi B+ than man gpio, man gpioctl etc?
> >> >
> >> Unfortunately not, there is the Wiki page
> >> (https://wiki.freebsd.org/FreeBSD/GPIO) but it doesn't add much.
> >>
> > I ave read this.
> >
> >> But we can try to help you whenever possible, just post your
> >> questions and we'll try to address them.
> >
> > I am currently working on a C program which should use GPIO to
> > switch relais and read the state of switches via GPIO. I would like
> > to make this program as simple as possible by creating first a
> > layer which provides then functions like set (Pin), reset (Pin)
> > and read (Pin) only. Of course plus the things needed to open,
> > close and configure the interface.
> >
> > The best I have found until now are the sources of gpioctl. I am
> > currently looking at the source.
> >
> > Is this the best start?
> 
> You can use the excellent rpaulo's libgpio:
> 
> https://bitbucket.org/rpaulo/libgpio/src/1dfe793d0b0cd6caff2e196cf667a5c06bbade8d/libgpio.h?at=default
> 
> It provides all the GPIO low level functions in a clear and simple
> way.

this looks good too.

Erich

From russ.haley at gmail.com  Tue Sep 30 05:15:15 2014
From: russ.haley at gmail.com (Russell Haley)
Date: Mon, 29 Sep 2014 22:15:14 -0700
Subject: Digi CCWMX53
In-Reply-To: <CABx9NuTkMcvX9gtLrEBO0cd7Kw+5mx4+1N9Z-02F9NGfueORjw@mail.gmail.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
 <CABx9NuTU=E7ceQ=5=Qk+=e9jwLjnJZf2Lr70d7XbwAYRD5nd7Q@mail.gmail.com>
 <E12E12A8-32B9-4B26-B6C4-65DF9F43C396@me.com>
 <CABx9NuTkMcvX9gtLrEBO0cd7Kw+5mx4+1N9Z-02F9NGfueORjw@mail.gmail.com>
Message-ID: <CABx9NuTx0aSyjm4vEQ3D7wzx6eqwmFmmWkEf=yLr9hxujxcD+w@mail.gmail.com>

Rui,

I've been able to build a kernel and upload it - again using a "Linux"
version of the CCWMX53 u-boot - but it didn't boot. I cloned your git repo
but I'm confuded (confused and befuddled or just a typo?) on how to cross
compile it. Do I set "devenvvar" (?) to somehow point into my latest
buildworld output and then just call make? Again I can only point to the
arndale board setup but even those instructions "feel" incomplete to my
novice brain. Any direction you could provide would be great. Here is my
latest boot output:


U-Boot 2009.08 - dub-1.6.4.1 - (Sep 25 2014 - 09:51:55) - GCC 4.4.6
for ConnectCore for i.MX53 on a JumpStart Kit Development Board
I2C:   ready
NAND:  512 MiB
MMC:   FSL_ESDHC: 0, FSL_ESDHC: 1
DRAM:   1 GB
In:    serial
Out:   serial
Err:   serial
Net:   FEC0 [PRIME]
Hit any key to stop autoboot:  0
FEC: enable RMII gasket
Using FEC0 device
TFTP from server 192.168.0.55; our IP address is 192.168.0.1
Filename 'kernel.bin'.
Load address: 0x70800000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ############
done
Bytes transferred = 4934472 (4b4b48 hex)
## Starting application at 0x70800100 ...


Thanks again!

Russ

On Sun, Sep 28, 2014 at 1:12 PM, Russell Haley <russ.haley at gmail.com> wrote:

> Rui,
>
> I was able to get a linux compatible copy of uboot to load a file from the
> network last night. I don't have a working BSD kernel right now and it
> wouldn't boot any of the uimage kernels I tried to upload. I'll work on
> getting a BSD kernel to build.
>
> Russ
>
> On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo <rpaulo at me.com> wrote:
>
>> On Sep 27, 2014, at 13:31, Russell Haley <russ.haley at gmail.com> wrote:
>> >
>> > Rui,
>> >
>> > So no MTD means the NAND on the SOM is out, but can I boot the kernel
>> and load rootfs from the microSD, like in this example:
>> >       ?
>> >  ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.bin;
>> go 0x40f00000"
>> >
>> >  ARNDALE5250 # saveenv
>> >
>> >  ARNDALE5250 # boot
>>
>> You can't use the Arndale config since the load addresses are different.
>> You should be able to load a kernel from the network.  Can you do that?
>>
>> --
>> Rui Paulo
>>
>>
>>
>>
>

From russ.haley at gmail.com  Tue Sep 30 06:32:48 2014
From: russ.haley at gmail.com (Russell Haley)
Date: Mon, 29 Sep 2014 23:32:46 -0700
Subject: Digi CCWMX53
In-Reply-To: <F30B6F69-D28D-4F42-8995-4373917C76EB@me.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
 <CABx9NuTU=E7ceQ=5=Qk+=e9jwLjnJZf2Lr70d7XbwAYRD5nd7Q@mail.gmail.com>
 <E12E12A8-32B9-4B26-B6C4-65DF9F43C396@me.com>
 <CABx9NuTkMcvX9gtLrEBO0cd7Kw+5mx4+1N9Z-02F9NGfueORjw@mail.gmail.com>
 <CABx9NuTx0aSyjm4vEQ3D7wzx6eqwmFmmWkEf=yLr9hxujxcD+w@mail.gmail.com>
 <F30B6F69-D28D-4F42-8995-4373917C76EB@me.com>
Message-ID: <CABx9NuQCgRj1hzZ+OBK_nEJmtVQKtsGp7qj00ZFkvwYCEHC-fQ@mail.gmail.com>

OH MY GOD IT BOOTED HOLY CRAP THANK YOU SO MUCH I THINK I JUST PEED MYSELF
THIS IS SO F'ING COOL!!!!!!

On Mon, Sep 29, 2014 at 11:03 PM, Rui Paulo <rpaulo at me.com> wrote:

> On Sep 29, 2014, at 22:15, Russell Haley <russ.haley at gmail.com> wrote:
> >
> > Rui,
> >
> > I've been able to build a kernel and upload it - again using a "Linux"
> > version of the CCWMX53 u-boot - but it didn't boot. I cloned your git
> repo
> > but I'm confuded (confused and befuddled or just a typo?) on how to cross
> > compile it. Do I set "devenvvar" (?) to somehow point into my latest
> > buildworld output and then just call make? Again I can only point to the
> > arndale board setup but even those instructions "feel" incomplete to my
> > novice brain.
>
> I've added instructions here:
>
> https://wiki.freebsd.org/Digi-CCWMX53
>
> NOTE: you don't need to install a new U-Boot to boot FreeBSD.
>
> > Any direction you could provide would be great. Here is my
> > latest boot output:
> >
> >
> > U-Boot 2009.08 - dub-1.6.4.1 - (Sep 25 2014 - 09:51:55) - GCC 4.4.6
> > for ConnectCore for i.MX53 on a JumpStart Kit Development Board
> > I2C:   ready
> > NAND:  512 MiB
> > MMC:   FSL_ESDHC: 0, FSL_ESDHC: 1
> > DRAM:   1 GB
> > In:    serial
> > Out:   serial
> > Err:   serial
> > Net:   FEC0 [PRIME]
> > Hit any key to stop autoboot:  0
> > FEC: enable RMII gasket
> > Using FEC0 device
> > TFTP from server 192.168.0.55; our IP address is 192.168.0.1
> > Filename 'kernel.bin'.
> > Load address: 0x70800000
> > Loading:
> #################################################################
> >         #################################################################
> >         #################################################################
> >         #################################################################
> >         #################################################################
> >         ############
> > done
> > Bytes transferred = 4934472 (4b4b48 hex)
> > ## Starting application at 0x70800100 ...
>
> Have you tried the regular kernel?  kernel.bin probably has the load
> address set to 0.
>
> --
> Rui Paulo
>
>
>
>

From rpaulo at me.com  Tue Sep 30 07:04:24 2014
From: rpaulo at me.com (Rui Paulo)
Date: Mon, 29 Sep 2014 23:03:33 -0700
Subject: Digi CCWMX53
In-Reply-To: <CABx9NuTx0aSyjm4vEQ3D7wzx6eqwmFmmWkEf=yLr9hxujxcD+w@mail.gmail.com>
References: <CABx9NuQr+dEb_yj3ypEe6Sb_qPY+qP74n0x1K5=_K6Zoio2vkw@mail.gmail.com>
 <C439A1ED-8AA0-4CA5-B375-D80E8BD4C624@me.com>
 <CABx9NuTU=E7ceQ=5=Qk+=e9jwLjnJZf2Lr70d7XbwAYRD5nd7Q@mail.gmail.com>
 <E12E12A8-32B9-4B26-B6C4-65DF9F43C396@me.com>
 <CABx9NuTkMcvX9gtLrEBO0cd7Kw+5mx4+1N9Z-02F9NGfueORjw@mail.gmail.com>
 <CABx9NuTx0aSyjm4vEQ3D7wzx6eqwmFmmWkEf=yLr9hxujxcD+w@mail.gmail.com>
Message-ID: <F30B6F69-D28D-4F42-8995-4373917C76EB@me.com>

On Sep 29, 2014, at 22:15, Russell Haley <russ.haley at gmail.com> wrote:
> 
> Rui,
> 
> I've been able to build a kernel and upload it - again using a "Linux"
> version of the CCWMX53 u-boot - but it didn't boot. I cloned your git repo
> but I'm confuded (confused and befuddled or just a typo?) on how to cross
> compile it. Do I set "devenvvar" (?) to somehow point into my latest
> buildworld output and then just call make? Again I can only point to the
> arndale board setup but even those instructions "feel" incomplete to my
> novice brain.

I've added instructions here:

https://wiki.freebsd.org/Digi-CCWMX53

NOTE: you don't need to install a new U-Boot to boot FreeBSD.

> Any direction you could provide would be great. Here is my
> latest boot output:
> 
> 
> U-Boot 2009.08 - dub-1.6.4.1 - (Sep 25 2014 - 09:51:55) - GCC 4.4.6
> for ConnectCore for i.MX53 on a JumpStart Kit Development Board
> I2C:   ready
> NAND:  512 MiB
> MMC:   FSL_ESDHC: 0, FSL_ESDHC: 1
> DRAM:   1 GB
> In:    serial
> Out:   serial
> Err:   serial
> Net:   FEC0 [PRIME]
> Hit any key to stop autoboot:  0
> FEC: enable RMII gasket
> Using FEC0 device
> TFTP from server 192.168.0.55; our IP address is 192.168.0.1
> Filename 'kernel.bin'.
> Load address: 0x70800000
> Loading: #################################################################
>         #################################################################
>         #################################################################
>         #################################################################
>         #################################################################
>         ############
> done
> Bytes transferred = 4934472 (4b4b48 hex)
> ## Starting application at 0x70800100 ...

Have you tried the regular kernel?  kernel.bin probably has the load address set to 0.  

--
Rui Paulo




From jmg at funkthat.com  Tue Sep 30 11:29:39 2014
From: jmg at funkthat.com (John-Mark Gurney)
Date: Tue, 30 Sep 2014 04:29:37 -0700
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <54291B74.5010307@gmail.com>
References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com>
 <54291B74.5010307@gmail.com>
Message-ID: <20140930112937.GU43300@funkthat.com>

Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200:
> 
> Am 29.09.2014 06:01, schrieb John-Mark Gurney:
> >Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
> >>This might be part of the weird FFS issues the Dreamplug has and no-one
> >>knows why they're happening.
> >Are you running w/ FFS journaling?  If so, try turning it off, but
> >keeping softupdates on..
> No journaling, no softupdates. I'll try enabling softupdates next time. 
> don't know if it will panic though
> >
> >>data_abort_handler() at data_abort_handler+0x5c0
> >>          pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
> >>          sp = 0xde019898  fp = 0xde019a20
> >>          r4 = 0xffffffff  r5 = 0xffff1004
> >>          r6 = 0xc3f3f6c0  r7 = 0x00001000
> >>          r8 = 0xc443e880  r9 = 0x00000000
> >>         r10 = 0xc3d69000
> >>exception_exit() at exception_exit
> >>          pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
> >>          sp = 0xde0198e8  fp = 0xde019a20
> >>          r0 = 0xd0238120  r1 = 0x00000e60
> >>          r2 = 0x00000000  r3 = 0x00000000
> >>          r4 = 0x00000120  r5 = 0x00000000
> >>          r6 = 0xc3f3f6c0  r7 = 0x00001000
> >>          r8 = 0xc443e880  r9 = 0x00000000
> >>         r10 = 0xc3d69000 r12 = 0xd0238120
> >>memset() at memset+0x48
> >>          pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
> >>          sp = 0xde0198e8  fp = 0xde019a20
> >>Unwind failure (no registers changed)
> >No more beyond this?   If you could run addr2line on 0xc0d53828 so
> >that we know where in ffs_truncate it's failing, that'd be very
> >nice...
> So I was trying to save the coredump in  order to reboot and run 
> addr2line, but that failed:
> 
> Physical memory: 504 MB
> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f 20 
> 00 00 01 00
> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable
> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted
> Aborting dump due to I/O error.
> 
> ** DUMP FAILED (ERROR 5) **
> 
> So I guess this error is related to the CAM errors I'm getting from time 
> to time. I was hoping that those errors were related to the INVARIANTS 
> option that slowed down the system and thus might have triggered CAM 
> errors, but obviously the SD Card seems to be the real issue here.
> So no crashdump for further analysis.

That's fine.. w/ the addr2line we have some lines to explore...

> Interestingly the CAM errors didn't show up on the terminal as other 
> times, the kernel just panicked straight away.

Hmm.. that is odd.. someone who knows the SD card layer should look
at this part...  It could be that the SD card driver doesn't handle
dumping (there is this global flag that gets set) properly and the driver
needs to behave differently when it's set...

> But I've got the addr2line output, even though I'm not sure it makes any 
> difference:
> 
> addr2line -f -e /mnt/kernel.debug 0xc0d53828
> 
> ffs_truncate
> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321

can you give me the contents of the line?  and a few lines of context
around it?   In HEAD's source, this is DOINGASYNC, and there is no call
to memset, nor a variable assignment that would result in memset being
called...

> >>The sad thing is, that with fsck broken for the dreamplug, I have to
> >>re-format the disk, reinstall everything and recreate the config files
> >>which I didn't manage to copy to a safe place beforehand :-(
> Didn't get around yet on checking whether the fsck issue persists if 
> everything is compiled with gcc. Will take a bit, as I'm going to be on 
> holidays for the next one and a half weeks. Fact is though, fsck is 
> broken on the Dreamplug (ARMv5TE), at least when run on EVERY device 
> that is attached via USB and if compiled with CLANG.
> >>
> >>Before I do that I'll leave the system in debugging mode for a few days,
> >>in case someone can help and needs some more information.
> Currently I've run fsck on all the disks/cards that had a working world 
> for the dreamplug on it, so they're all gone. Can't do eny debugging 
> atm. I'll let you know hoe the gcc build goes once I'm back from 
> holidays though.

Hmmm. this is also worth investigating as it could be that clang is
producing bad code somewhere...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From jmg at funkthat.com  Tue Sep 30 11:34:45 2014
From: jmg at funkthat.com (John-Mark Gurney)
Date: Tue, 30 Sep 2014 04:34:44 -0700
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <1411998551.66615.328.camel@revolution.hippie.lan>
References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com>
 <1411998551.66615.328.camel@revolution.hippie.lan>
Message-ID: <20140930113444.GV43300@funkthat.com>

Ian Lepore wrote this message on Mon, Sep 29, 2014 at 07:49 -0600:
> On Sun, 2014-09-28 at 21:01 -0700, John-Mark Gurney wrote:
> > Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
> > > This might be part of the weird FFS issues the Dreamplug has and no-one 
> > > knows why they're happening.
> > 
> > Are you running w/ FFS journaling?  If so, try turning it off, but
> > keeping softupdates on..
> > 
> 
> It's not an SU+J problem, or even an SU problem.  fsck finds
> non-existant errors on filesystems known to be clean, and if
> write-enabled it will corrupt the good filesystem when attempting to
> correct those "errors".  This is on armv4 only, not v6.  I tested with
> and without softupdates on.  I tested with UFS1 and UFS2 filesystems.
> You can even do a newfs followed immediately by an fsck on it and it
> will corrupt the fs.
> 
> The one thing I haven't done is opened a PR for this.

Hmm... I just tested this on my AVILA board, and I don't see this on
either UFS1 or UFS2...  Are you doing this via HD or md?  My testing was
via a 64MB md as I don't have a good way to attach external storage to
my board...

If you really are seeing immediate corruption to an SD card, then I'd
make sure that the card is getting the correct data written to it...

I'd suggest trying to run ZFS since it checksums everything it writes,
but not sure if it'd run, and if so, how well...

> > > data_abort_handler() at data_abort_handler+0x5c0
> > >          pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
> > >          sp = 0xde019898  fp = 0xde019a20
> > >          r4 = 0xffffffff  r5 = 0xffff1004
> > >          r6 = 0xc3f3f6c0  r7 = 0x00001000
> > >          r8 = 0xc443e880  r9 = 0x00000000
> > >         r10 = 0xc3d69000
> > > exception_exit() at exception_exit
> > >          pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
> > >          sp = 0xde0198e8  fp = 0xde019a20
> > >          r0 = 0xd0238120  r1 = 0x00000e60
> > >          r2 = 0x00000000  r3 = 0x00000000
> > >          r4 = 0x00000120  r5 = 0x00000000
> > >          r6 = 0xc3f3f6c0  r7 = 0x00001000
> > >          r8 = 0xc443e880  r9 = 0x00000000
> > >         r10 = 0xc3d69000 r12 = 0xd0238120
> > > memset() at memset+0x48
> > >          pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
> > >          sp = 0xde0198e8  fp = 0xde019a20
> > > Unwind failure (no registers changed)
> > 
> > No more beyond this?   If you could run addr2line on 0xc0d53828 so
> > that we know where in ffs_truncate it's failing, that'd be very
> > nice...
> > 
> 
> Some time in the past 4-6 weeks something has gone wrong with kernel
> stack backtraces.  Sometimes you get a full useful traceback, and more
> often it ends at the function that triggered the exception, always with
> a "no registers changed" message.
> 
> -- Ian
> 
> > > The sad thing is, that with fsck broken for the dreamplug, I have to 
> > > re-format the disk, reinstall everything and recreate the config files 
> > > which I didn't manage to copy to a safe place beforehand :-(
> > > 
> > > Before I do that I'll leave the system in debugging mode for a few days, 
> > > in case someone can help and needs some more information.
> > > 
> > > Cheers,
> > > 
> > > Mat
> 

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From mattia.rossi.mailinglists at gmail.com  Tue Sep 30 12:14:33 2014
From: mattia.rossi.mailinglists at gmail.com (Mattia Rossi)
Date: Tue, 30 Sep 2014 14:14:28 +0200
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <20140930112937.GU43300@funkthat.com>
References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com>
 <54291B74.5010307@gmail.com> <20140930112937.GU43300@funkthat.com>
Message-ID: <542A9EA4.70109@gmail.com>


Am 30.09.2014 13:29, schrieb John-Mark Gurney:
> Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200:
>> Am 29.09.2014 06:01, schrieb John-Mark Gurney:
>>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
>>>> This might be part of the weird FFS issues the Dreamplug has and no-one
>>>> knows why they're happening.
>>> Are you running w/ FFS journaling?  If so, try turning it off, but
>>> keeping softupdates on..
>> No journaling, no softupdates. I'll try enabling softupdates next time.
>> don't know if it will panic though
>>>> data_abort_handler() at data_abort_handler+0x5c0
>>>>           pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
>>>>           sp = 0xde019898  fp = 0xde019a20
>>>>           r4 = 0xffffffff  r5 = 0xffff1004
>>>>           r6 = 0xc3f3f6c0  r7 = 0x00001000
>>>>           r8 = 0xc443e880  r9 = 0x00000000
>>>>          r10 = 0xc3d69000
>>>> exception_exit() at exception_exit
>>>>           pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>>>>           sp = 0xde0198e8  fp = 0xde019a20
>>>>           r0 = 0xd0238120  r1 = 0x00000e60
>>>>           r2 = 0x00000000  r3 = 0x00000000
>>>>           r4 = 0x00000120  r5 = 0x00000000
>>>>           r6 = 0xc3f3f6c0  r7 = 0x00001000
>>>>           r8 = 0xc443e880  r9 = 0x00000000
>>>>          r10 = 0xc3d69000 r12 = 0xd0238120
>>>> memset() at memset+0x48
>>>>           pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>>>>           sp = 0xde0198e8  fp = 0xde019a20
>>>> Unwind failure (no registers changed)
>>> No more beyond this?   If you could run addr2line on 0xc0d53828 so
>>> that we know where in ffs_truncate it's failing, that'd be very
>>> nice...
>> So I was trying to save the coredump in  order to reboot and run
>> addr2line, but that failed:
>>
>> Physical memory: 504 MB
>> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f20
>> 00 00 01 00  <sip:2000000100>
>> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable
>> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted
>> Aborting dump due to I/O error.
>>
>> ** DUMP FAILED (ERROR 5) **
>>
>> So I guess this error is related to the CAM errors I'm getting from time
>> to time. I was hoping that those errors were related to the INVARIANTS
>> option that slowed down the system and thus might have triggered CAM
>> errors, but obviously the SD Card seems to be the real issue here.
>> So no crashdump for further analysis.
> That's fine.. w/ the addr2line we have some lines to explore...
>
>> Interestingly the CAM errors didn't show up on the terminal as other
>> times, the kernel just panicked straight away.
> Hmm.. that is odd.. someone who knows the SD card layer should look
> at this part...  It could be that the SD card driver doesn't handle
> dumping (there is this global flag that gets set) properly and the driver
> needs to behave differently when it's set...

I also need to grab a new SD card, just to make sure it's really not the 
card.

>
>> But I've got the addr2line output, even though I'm not sure it makes any
>> difference:
>>
>> addr2line -f -e /mnt/kernel.debug 0xc0d53828
>>
>> ffs_truncate
>> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321
> can you give me the contents of the line?  and a few lines of context
> around it?   In HEAD's source, this is DOINGASYNC, and there is no call
> to memset, nor a variable assignment that would result in memset being
> called...

Same here.. The file hasn't been changed in a while (Fri, 31 May 2013):

                 ip->i_size = length;
                 DIP_SET(ip, i_size, length);
                 if (bp->b_bufsize == fs->fs_bsize)
                         bp->b_flags |= B_CLUSTEROK;
                 if (flags & IO_SYNC)
                         bwrite(bp);
321:        else if (DOINGASYNC(vp))
                         bdwrite(bp);
                 else
                         bawrite(bp);
                 ip->i_flag |= IN_CHANGE | IN_UPDATE;
                 return (ffs_update(vp, !DOINGASYNC(vp)));

No idea what's going on.

>>>> The sad thing is, that with fsck broken for the dreamplug, I have to
>>>> re-format the disk, reinstall everything and recreate the config files
>>>> which I didn't manage to copy to a safe place beforehand :-(
>> Didn't get around yet on checking whether the fsck issue persists if
>> everything is compiled with gcc. Will take a bit, as I'm going to be on
>> holidays for the next one and a half weeks. Fact is though, fsck is
>> broken on the Dreamplug (ARMv5TE), at least when run on EVERY device
>> that is attached via USB and if compiled with CLANG.
>>>> Before I do that I'll leave the system in debugging mode for a few days,
>>>> in case someone can help and needs some more information.
>> Currently I've run fsck on all the disks/cards that had a working world
>> for the dreamplug on it, so they're all gone. Can't do eny debugging
>> atm. I'll let you know hoe the gcc build goes once I'm back from
>> holidays though.
> Hmmm. this is also worth investigating as it could be that clang is
> producing bad code somewhere...

I'm trying to get kernel and world compiled with gcc atm. It fails 
though, as somehow the armv7 code is currently broken... and the 
toolchain build is not happy.

In file included from 
/usr/devel/dreamplug/sys/arm/arm/cpufunc_asm_armv7.S:36:
./machine/sysreg.h:97:5: error: "__ARM_ARCH" is not defined

(followed by a few more of those)

My build command:

  make TARGET=arm TARGET_ARCH=arm DESTDIR=/usr/devel/dreamplug-dist 
KERNCONF=DREAMPLUG-1001 -DWITHOUT_SHAREDOCS -DWITHOUT_EXAMPLES 
-DWITHOUT_HTML -DWITHOUT_MAN -DWITHOUT_GAMES toolchain buildworld kernel 
installworld

From jmg at funkthat.com  Tue Sep 30 12:30:12 2014
From: jmg at funkthat.com (John-Mark Gurney)
Date: Tue, 30 Sep 2014 05:30:10 -0700
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <542A9EA4.70109@gmail.com>
References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com>
 <54291B74.5010307@gmail.com> <20140930112937.GU43300@funkthat.com>
 <542A9EA4.70109@gmail.com>
Message-ID: <20140930123010.GZ43300@funkthat.com>

Mattia Rossi wrote this message on Tue, Sep 30, 2014 at 14:14 +0200:
> 
> Am 30.09.2014 13:29, schrieb John-Mark Gurney:
> >Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200:
> >>Am 29.09.2014 06:01, schrieb John-Mark Gurney:
> >>>Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
> >>>>This might be part of the weird FFS issues the Dreamplug has and no-one
> >>>>knows why they're happening.
> >>>Are you running w/ FFS journaling?  If so, try turning it off, but
> >>>keeping softupdates on..
> >>No journaling, no softupdates. I'll try enabling softupdates next time.
> >>don't know if it will panic though
> >>>>data_abort_handler() at data_abort_handler+0x5c0
> >>>>          pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
> >>>>          sp = 0xde019898  fp = 0xde019a20
> >>>>          r4 = 0xffffffff  r5 = 0xffff1004
> >>>>          r6 = 0xc3f3f6c0  r7 = 0x00001000
> >>>>          r8 = 0xc443e880  r9 = 0x00000000
> >>>>         r10 = 0xc3d69000
> >>>>exception_exit() at exception_exit
> >>>>          pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
> >>>>          sp = 0xde0198e8  fp = 0xde019a20
> >>>>          r0 = 0xd0238120  r1 = 0x00000e60
> >>>>          r2 = 0x00000000  r3 = 0x00000000
> >>>>          r4 = 0x00000120  r5 = 0x00000000
> >>>>          r6 = 0xc3f3f6c0  r7 = 0x00001000
> >>>>          r8 = 0xc443e880  r9 = 0x00000000
> >>>>         r10 = 0xc3d69000 r12 = 0xd0238120
> >>>>memset() at memset+0x48
> >>>>          pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
> >>>>          sp = 0xde0198e8  fp = 0xde019a20
> >>>>Unwind failure (no registers changed)
> >>>No more beyond this?   If you could run addr2line on 0xc0d53828 so
> >>>that we know where in ffs_truncate it's failing, that'd be very
> >>>nice...
> >>So I was trying to save the coredump in  order to reboot and run
> >>addr2line, but that failed:
> >>
> >>Physical memory: 504 MB
> >>Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f20
> >>00 00 01 00  <sip:2000000100>
> >>(da0:umass-sim0:0:0:0): CAM status: Resource Unavailable
> >>(da0:umass-sim0:0:0:0): Error 5, Retries exhausted
> >>Aborting dump due to I/O error.
> >>
> >>** DUMP FAILED (ERROR 5) **
> >>
> >>So I guess this error is related to the CAM errors I'm getting from time
> >>to time. I was hoping that those errors were related to the INVARIANTS
> >>option that slowed down the system and thus might have triggered CAM
> >>errors, but obviously the SD Card seems to be the real issue here.
> >>So no crashdump for further analysis.
> >That's fine.. w/ the addr2line we have some lines to explore...
> >
> >>Interestingly the CAM errors didn't show up on the terminal as other
> >>times, the kernel just panicked straight away.
> >Hmm.. that is odd.. someone who knows the SD card layer should look
> >at this part...  It could be that the SD card driver doesn't handle
> >dumping (there is this global flag that gets set) properly and the driver
> >needs to behave differently when it's set...
> 
> I also need to grab a new SD card, just to make sure it's really not the 
> card.
> 
> >
> >>But I've got the addr2line output, even though I'm not sure it makes any
> >>difference:
> >>
> >>addr2line -f -e /mnt/kernel.debug 0xc0d53828
> >>
> >>ffs_truncate
> >>/usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321
> >can you give me the contents of the line?  and a few lines of context
> >around it?   In HEAD's source, this is DOINGASYNC, and there is no call
> >to memset, nor a variable assignment that would result in memset being
> >called...
> 
> Same here.. The file hasn't been changed in a while (Fri, 31 May 2013):
> 
>                 ip->i_size = length;
>                 DIP_SET(ip, i_size, length);
>                 if (bp->b_bufsize == fs->fs_bsize)
>                         bp->b_flags |= B_CLUSTEROK;
>                 if (flags & IO_SYNC)
>                         bwrite(bp);
> 321:        else if (DOINGASYNC(vp))
>                         bdwrite(bp);
>                 else
>                         bawrite(bp);
>                 ip->i_flag |= IN_CHANGE | IN_UPDATE;
>                 return (ffs_update(vp, !DOINGASYNC(vp)));
> 
> No idea what's going on.

ok, could you send me the output of objdump -dSl, but you only need
to include the part from XXXXX <ffs_truncate>: to the next XXX<func>:
line...  probably off list as it'll be quite long...

> >>>>The sad thing is, that with fsck broken for the dreamplug, I have to
> >>>>re-format the disk, reinstall everything and recreate the config files
> >>>>which I didn't manage to copy to a safe place beforehand :-(
> >>Didn't get around yet on checking whether the fsck issue persists if
> >>everything is compiled with gcc. Will take a bit, as I'm going to be on
> >>holidays for the next one and a half weeks. Fact is though, fsck is
> >>broken on the Dreamplug (ARMv5TE), at least when run on EVERY device
> >>that is attached via USB and if compiled with CLANG.
> >>>>Before I do that I'll leave the system in debugging mode for a few days,
> >>>>in case someone can help and needs some more information.
> >>Currently I've run fsck on all the disks/cards that had a working world
> >>for the dreamplug on it, so they're all gone. Can't do eny debugging
> >>atm. I'll let you know hoe the gcc build goes once I'm back from
> >>holidays though.
> >Hmmm. this is also worth investigating as it could be that clang is
> >producing bad code somewhere...
> 
> I'm trying to get kernel and world compiled with gcc atm. It fails 
> though, as somehow the armv7 code is currently broken... and the 
> toolchain build is not happy.
> 
> In file included from 
> /usr/devel/dreamplug/sys/arm/arm/cpufunc_asm_armv7.S:36:
> ./machine/sysreg.h:97:5: error: "__ARM_ARCH" is not defined
> 
> (followed by a few more of those)
> 
> My build command:
> 
>  make TARGET=arm TARGET_ARCH=arm DESTDIR=/usr/devel/dreamplug-dist 
> KERNCONF=DREAMPLUG-1001 -DWITHOUT_SHAREDOCS -DWITHOUT_EXAMPLES 
> -DWITHOUT_HTML -DWITHOUT_MAN -DWITHOUT_GAMES toolchain buildworld kernel 
> installworld

Not sure about this...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From ian at FreeBSD.org  Tue Sep 30 13:46:30 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Tue, 30 Sep 2014 07:46:26 -0600
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <20140930112937.GU43300@funkthat.com>
References: <542559BC.7090100@gmail.com>
 <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com>
 <20140930112937.GU43300@funkthat.com>
Message-ID: <1412084786.66615.356.camel@revolution.hippie.lan>

On Tue, 2014-09-30 at 04:29 -0700, John-Mark Gurney wrote:
> Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200:
> > 
> > Am 29.09.2014 06:01, schrieb John-Mark Gurney:
> > >Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
> > >>This might be part of the weird FFS issues the Dreamplug has and no-one
> > >>knows why they're happening.
> > >Are you running w/ FFS journaling?  If so, try turning it off, but
> > >keeping softupdates on..
> > No journaling, no softupdates. I'll try enabling softupdates next time. 
> > don't know if it will panic though
> > >
> > >>data_abort_handler() at data_abort_handler+0x5c0
> > >>          pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
> > >>          sp = 0xde019898  fp = 0xde019a20
> > >>          r4 = 0xffffffff  r5 = 0xffff1004
> > >>          r6 = 0xc3f3f6c0  r7 = 0x00001000
> > >>          r8 = 0xc443e880  r9 = 0x00000000
> > >>         r10 = 0xc3d69000
> > >>exception_exit() at exception_exit
> > >>          pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
> > >>          sp = 0xde0198e8  fp = 0xde019a20
> > >>          r0 = 0xd0238120  r1 = 0x00000e60
> > >>          r2 = 0x00000000  r3 = 0x00000000
> > >>          r4 = 0x00000120  r5 = 0x00000000
> > >>          r6 = 0xc3f3f6c0  r7 = 0x00001000
> > >>          r8 = 0xc443e880  r9 = 0x00000000
> > >>         r10 = 0xc3d69000 r12 = 0xd0238120
> > >>memset() at memset+0x48
> > >>          pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
> > >>          sp = 0xde0198e8  fp = 0xde019a20
> > >>Unwind failure (no registers changed)
> > >No more beyond this?   If you could run addr2line on 0xc0d53828 so
> > >that we know where in ffs_truncate it's failing, that'd be very
> > >nice...
> > So I was trying to save the coredump in  order to reboot and run 
> > addr2line, but that failed:
> > 
> > Physical memory: 504 MB
> > Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f 20 
> > 00 00 01 00
> > (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable
> > (da0:umass-sim0:0:0:0): Error 5, Retries exhausted
> > Aborting dump due to I/O error.
> > 
> > ** DUMP FAILED (ERROR 5) **
> > 
> > So I guess this error is related to the CAM errors I'm getting from time 
> > to time. I was hoping that those errors were related to the INVARIANTS 
> > option that slowed down the system and thus might have triggered CAM 
> > errors, but obviously the SD Card seems to be the real issue here.
> > So no crashdump for further analysis.
> 
> That's fine.. w/ the addr2line we have some lines to explore...
> 
> > Interestingly the CAM errors didn't show up on the terminal as other 
> > times, the kernel just panicked straight away.
> 
> Hmm.. that is odd.. someone who knows the SD card layer should look
> at this part...  It could be that the SD card driver doesn't handle
> dumping (there is this global flag that gets set) properly and the driver
> needs to behave differently when it's set...
> 

On this model of dreamplug, an sdcard is just a usb drive; internally
there is a usb<->sd adapter chip, the same one used in many usb
multi-format card reader/writers.  There's no part of the
sdhci/mmc/mmcsd driver stack involved.

> > But I've got the addr2line output, even though I'm not sure it makes any 
> > difference:
> > 
> > addr2line -f -e /mnt/kernel.debug 0xc0d53828
> > 
> > ffs_truncate
> > /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321
> 
> can you give me the contents of the line?  and a few lines of context
> around it?   In HEAD's source, this is DOINGASYNC, and there is no call
> to memset, nor a variable assignment that would result in memset being
> called...
> 
> > >>The sad thing is, that with fsck broken for the dreamplug, I have to
> > >>re-format the disk, reinstall everything and recreate the config files
> > >>which I didn't manage to copy to a safe place beforehand :-(
> > Didn't get around yet on checking whether the fsck issue persists if 
> > everything is compiled with gcc. Will take a bit, as I'm going to be on 
> > holidays for the next one and a half weeks. Fact is though, fsck is 
> > broken on the Dreamplug (ARMv5TE), at least when run on EVERY device 
> > that is attached via USB and if compiled with CLANG.
> > >>
> > >>Before I do that I'll leave the system in debugging mode for a few days,
> > >>in case someone can help and needs some more information.
> > Currently I've run fsck on all the disks/cards that had a working world 
> > for the dreamplug on it, so they're all gone. Can't do eny debugging 
> > atm. I'll let you know hoe the gcc build goes once I'm back from 
> > holidays though.
> 
> Hmmm. this is also worth investigating as it could be that clang is
> producing bad code somewhere...
> 

I tested with a gcc build of -current yesterday and got the same results
as with clang -- fsck on a freshly-formatted filesystem says it's
corrupted, even when the formatting was done on a non-armv4 system.

Also, this is not related to usb or sdcards per se.  You can get the
same results with a sata drive, or even md(4) (but interestingly, some
sizes of md disk have problems and some don't).

-- Ian



From mattia.rossi.mailinglists at gmail.com  Tue Sep 30 14:05:16 2014
From: mattia.rossi.mailinglists at gmail.com (Mattia Rossi)
Date: Tue, 30 Sep 2014 16:05:11 +0200
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <20140930123010.GZ43300@funkthat.com>
References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com>
 <54291B74.5010307@gmail.com> <20140930112937.GU43300@funkthat.com>
 <542A9EA4.70109@gmail.com> <20140930123010.GZ43300@funkthat.com>
Message-ID: <542AB897.3020309@gmail.com>


Am 30.09.2014 14:30, schrieb John-Mark Gurney:
> Mattia Rossi wrote this message on Tue, Sep 30, 2014 at 14:14 +0200:
>> Am 30.09.2014 13:29, schrieb John-Mark Gurney:
>>> Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200:
>>>> Am 29.09.2014 06:01, schrieb John-Mark Gurney:
>>>>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
>>>>>> This might be part of the weird FFS issues the Dreamplug has and no-one
>>>>>> knows why they're happening.
>>>>> Are you running w/ FFS journaling?  If so, try turning it off, but
>>>>> keeping softupdates on..
>>>> No journaling, no softupdates. I'll try enabling softupdates next time.
>>>> don't know if it will panic though
>>>>>> data_abort_handler() at data_abort_handler+0x5c0
>>>>>>           pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
>>>>>>           sp = 0xde019898  fp = 0xde019a20
>>>>>>           r4 = 0xffffffff  r5 = 0xffff1004
>>>>>>           r6 = 0xc3f3f6c0  r7 = 0x00001000
>>>>>>           r8 = 0xc443e880  r9 = 0x00000000
>>>>>>          r10 = 0xc3d69000
>>>>>> exception_exit() at exception_exit
>>>>>>           pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>>>>>>           sp = 0xde0198e8  fp = 0xde019a20
>>>>>>           r0 = 0xd0238120  r1 = 0x00000e60
>>>>>>           r2 = 0x00000000  r3 = 0x00000000
>>>>>>           r4 = 0x00000120  r5 = 0x00000000
>>>>>>           r6 = 0xc3f3f6c0  r7 = 0x00001000
>>>>>>           r8 = 0xc443e880  r9 = 0x00000000
>>>>>>          r10 = 0xc3d69000 r12 = 0xd0238120
>>>>>> memset() at memset+0x48
>>>>>>           pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>>>>>>           sp = 0xde0198e8  fp = 0xde019a20
>>>>>> Unwind failure (no registers changed)
>>>>> No more beyond this?   If you could run addr2line on 0xc0d53828 so
>>>>> that we know where in ffs_truncate it's failing, that'd be very
>>>>> nice...
>>>> So I was trying to save the coredump in  order to reboot and run
>>>> addr2line, but that failed:
>>>>
>>>> Physical memory: 504 MB
>>>> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f20
>>>> 00 00 01 00  <sip:2000000100>
>>>> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable
>>>> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted
>>>> Aborting dump due to I/O error.
>>>>
>>>> ** DUMP FAILED (ERROR 5) **
>>>>
>>>> So I guess this error is related to the CAM errors I'm getting from time
>>>> to time. I was hoping that those errors were related to the INVARIANTS
>>>> option that slowed down the system and thus might have triggered CAM
>>>> errors, but obviously the SD Card seems to be the real issue here.
>>>> So no crashdump for further analysis.
>>> That's fine.. w/ the addr2line we have some lines to explore...
>>>
>>>> Interestingly the CAM errors didn't show up on the terminal as other
>>>> times, the kernel just panicked straight away.
>>> Hmm.. that is odd.. someone who knows the SD card layer should look
>>> at this part...  It could be that the SD card driver doesn't handle
>>> dumping (there is this global flag that gets set) properly and the driver
>>> needs to behave differently when it's set...
>> I also need to grab a new SD card, just to make sure it's really not the
>> card.
>>
>>>> But I've got the addr2line output, even though I'm not sure it makes any
>>>> difference:
>>>>
>>>> addr2line -f -e /mnt/kernel.debug 0xc0d53828
>>>>
>>>> ffs_truncate
>>>> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321
>>> can you give me the contents of the line?  and a few lines of context
>>> around it?   In HEAD's source, this is DOINGASYNC, and there is no call
>>> to memset, nor a variable assignment that would result in memset being
>>> called...
>> Same here.. The file hasn't been changed in a while (Fri, 31 May 2013):
>>
>>                  ip->i_size = length;
>>                  DIP_SET(ip, i_size, length);
>>                  if (bp->b_bufsize == fs->fs_bsize)
>>                          bp->b_flags |= B_CLUSTEROK;
>>                  if (flags & IO_SYNC)
>>                          bwrite(bp);
>> 321:        else if (DOINGASYNC(vp))
>>                          bdwrite(bp);
>>                  else
>>                          bawrite(bp);
>>                  ip->i_flag |= IN_CHANGE | IN_UPDATE;
>>                  return (ffs_update(vp, !DOINGASYNC(vp)));
>>
>> No idea what's going on.
> ok, could you send me the output of objdump -dSl, but you only need
> to include the part from XXXXX <ffs_truncate>: to the next XXX<func>:
> line...  probably off list as it'll be quite long...
I'm sorry, but given that I just broke all my working worlds using fsck, 
I'm not going to be able to do that until I'm back from holidays.... 
currently working on the stuff remotely and after today's work day, I'm 
not going to be able to get my hands on the dreamplug.



From ian at FreeBSD.org  Tue Sep 30 14:05:19 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Tue, 30 Sep 2014 08:05:15 -0600
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <20140930113444.GV43300@funkthat.com>
References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com>
 <1411998551.66615.328.camel@revolution.hippie.lan>
 <20140930113444.GV43300@funkthat.com>
Message-ID: <1412085915.66615.360.camel@revolution.hippie.lan>

On Tue, 2014-09-30 at 04:34 -0700, John-Mark Gurney wrote:
> Ian Lepore wrote this message on Mon, Sep 29, 2014 at 07:49 -0600:
> > On Sun, 2014-09-28 at 21:01 -0700, John-Mark Gurney wrote:
> > > Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
> > > > This might be part of the weird FFS issues the Dreamplug has and no-one 
> > > > knows why they're happening.
> > > 
> > > Are you running w/ FFS journaling?  If so, try turning it off, but
> > > keeping softupdates on..
> > > 
> > 
> > It's not an SU+J problem, or even an SU problem.  fsck finds
> > non-existant errors on filesystems known to be clean, and if
> > write-enabled it will corrupt the good filesystem when attempting to
> > correct those "errors".  This is on armv4 only, not v6.  I tested with
> > and without softupdates on.  I tested with UFS1 and UFS2 filesystems.
> > You can even do a newfs followed immediately by an fsck on it and it
> > will corrupt the fs.
> > 
> > The one thing I haven't done is opened a PR for this.
> 
> Hmm... I just tested this on my AVILA board, and I don't see this on
> either UFS1 or UFS2...  Are you doing this via HD or md?  My testing was
> via a 64MB md as I don't have a good way to attach external storage to
> my board...
> 
> If you really are seeing immediate corruption to an SD card, then I'd
> make sure that the card is getting the correct data written to it...
> 

There isn't actually any corruption on the filesystem until fsck starts
trying to fix what it thinks is wrong.  That is, fsck -n will report
problems, you then move that drive to a non-armv4 system and fsck there
reports no problems.  If you let armv4 fsck "fix" problems then move the
drive to another system and re-check, the filesystem IS corrupted at
that point.

> I'd suggest trying to run ZFS since it checksums everything it writes,
> but not sure if it'd run, and if so, how well...
> 

afaik, nobody has ever tried zfs on any arm platform.  Maybe it just
works.  I'd love to hear from someone about it.  I don't have time
myself to learn to configure and administer it.

-- Ian



From andrew at fubar.geek.nz  Tue Sep 30 14:07:51 2014
From: andrew at fubar.geek.nz (Andrew Turner)
Date: Tue, 30 Sep 2014 15:07:43 +0100
Subject: MK_ARM_EABI to retire in current
In-Reply-To: <E594E133-F3A7-46EA-BCEF-B2B62B5FCE4C@bsdimp.com>
References: <C66667D9-2F5E-44E0-AF04-E9DFE70BAF5A@gmail.com>
 <20140928121818.741e7e7e@bender.lan>
 <E594E133-F3A7-46EA-BCEF-B2B62B5FCE4C@bsdimp.com>
Message-ID: <20140930150743.15999c12@bender.lan>

On Sun, 28 Sep 2014 10:19:09 -0700
Warner Losh <imp at bsdimp.com> wrote:

> 
> On Sep 28, 2014, at 4:18 AM, Andrew Turner <andrew at fubar.geek.nz>
> wrote:
> 
> > On Mon, 19 May 2014 09:40:33 -0600
> > Warner Losh <imp at bsdimp.com> wrote:
> > 
> >> Greetings,
> >> 
> >> MK_ARM_EABI is going to die in current. It is the default for all
> >> platforms currently. I?m eliminating it as a build option. It must
> >> die because it invisibly (to uname) effects the ABI.
> >> 
> >> So, to that end, I see two options:
> >> 
> >> (1) Retire and remove oabi support.
> >> (2) Retain oabi support, but change its name to armo and armoeb.
> >> 
> >> The rough consensus of arm developers I?ve polled now, and in the
> >> past, is that we just let oabi support die now that EABI support is
> >> working for everybody.
> >> 
> >> Before I pull the trigger on this, however, I must ask if anybody
> >> has a problem with my doing option (1), and if so, what keeps you
> >> using oabi.
> >> 
> >> Comments?
> > 
> > As far as I know all the problems with ARM EABI on armeb mentioned
> > in this thread have been fixed. I think we should now retire the
> > oabi support and remove MK_ARM_EABI.
> 
> I?m game. I think we should move forward on option #1. We?ve had no
> issues in the 10.1 release related to this that I?m aware of. Should
> there be no further objections, my plan is to move forward with this
> later this week.

I've created a change for review at [1].

Andrew

[1] https://reviews.freebsd.org/D876

From mattia.rossi.mailinglists at gmail.com  Tue Sep 30 14:15:47 2014
From: mattia.rossi.mailinglists at gmail.com (Mattia Rossi)
Date: Tue, 30 Sep 2014 16:15:43 +0200
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <1412085915.66615.360.camel@revolution.hippie.lan>
References: <542559BC.7090100@gmail.com>	
 <20140929040126.GG43300@funkthat.com>	
 <1411998551.66615.328.camel@revolution.hippie.lan>	
 <20140930113444.GV43300@funkthat.com>
 <1412085915.66615.360.camel@revolution.hippie.lan>
Message-ID: <542ABB0F.8080201@gmail.com>


Am 30.09.2014 16:05, schrieb Ian Lepore:
> On Tue, 2014-09-30 at 04:34 -0700, John-Mark Gurney wrote:
>> Ian Lepore wrote this message on Mon, Sep 29, 2014 at 07:49 -0600:
>>> On Sun, 2014-09-28 at 21:01 -0700, John-Mark Gurney wrote:
>>>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
>>>>> This might be part of the weird FFS issues the Dreamplug has and no-one
>>>>> knows why they're happening.
>>>> Are you running w/ FFS journaling?  If so, try turning it off, but
>>>> keeping softupdates on..
>>>>
>>> It's not an SU+J problem, or even an SU problem.  fsck finds
>>> non-existant errors on filesystems known to be clean, and if
>>> write-enabled it will corrupt the good filesystem when attempting to
>>> correct those "errors".  This is on armv4 only, not v6.  I tested with
>>> and without softupdates on.  I tested with UFS1 and UFS2 filesystems.
>>> You can even do a newfs followed immediately by an fsck on it and it
>>> will corrupt the fs.
>>>
>>> The one thing I haven't done is opened a PR for this.
>> Hmm... I just tested this on my AVILA board, and I don't see this on
>> either UFS1 or UFS2...  Are you doing this via HD or md?  My testing was
>> via a 64MB md as I don't have a good way to attach external storage to
>> my board...
>>
>> If you really are seeing immediate corruption to an SD card, then I'd
>> make sure that the card is getting the correct data written to it...
>>
> There isn't actually any corruption on the filesystem until fsck starts
> trying to fix what it thinks is wrong.  That is, fsck -n will report
> problems, you then move that drive to a non-armv4 system and fsck there
> reports no problems.  If you let armv4 fsck "fix" problems then move the
> drive to another system and re-check, the filesystem IS corrupted at
> that point.
>
>> I'd suggest trying to run ZFS since it checksums everything it writes,
>> but not sure if it'd run, and if so, how well...
>>
> afaik, nobody has ever tried zfs on any arm platform.  Maybe it just
> works.  I'd love to hear from someone about it.  I don't have time
> myself to learn to configure and administer it.

I think there are at least a few people that tried it 
(http://lists.freebsd.org/pipermail/freebsd-arm/2014-February/007455.html). 
I've tried it as well (on an external ESATA disk), but had some 
performance problems, which I think could be resolved if I would run a 
bootloader (which I don't). The other solution would be to apply the 
following patch, and tweak performance via sysctls on a running system: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594

Anyhow, first things first..



From ian at FreeBSD.org  Tue Sep 30 14:17:45 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Tue, 30 Sep 2014 08:17:41 -0600
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <542A9EA4.70109@gmail.com>
References: <542559BC.7090100@gmail.com>
 <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com>
 <20140930112937.GU43300@funkthat.com>  <542A9EA4.70109@gmail.com>
Message-ID: <1412086661.66615.361.camel@revolution.hippie.lan>

On Tue, 2014-09-30 at 14:14 +0200, Mattia Rossi wrote:
> Am 30.09.2014 13:29, schrieb John-Mark Gurney:
> > Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200:
> >> Am 29.09.2014 06:01, schrieb John-Mark Gurney:
> >>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
> >>>> This might be part of the weird FFS issues the Dreamplug has and no-one
> >>>> knows why they're happening.
> >>> Are you running w/ FFS journaling?  If so, try turning it off, but
> >>> keeping softupdates on..
> >> No journaling, no softupdates. I'll try enabling softupdates next time.
> >> don't know if it will panic though
> >>>> data_abort_handler() at data_abort_handler+0x5c0
> >>>>           pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
> >>>>           sp = 0xde019898  fp = 0xde019a20
> >>>>           r4 = 0xffffffff  r5 = 0xffff1004
> >>>>           r6 = 0xc3f3f6c0  r7 = 0x00001000
> >>>>           r8 = 0xc443e880  r9 = 0x00000000
> >>>>          r10 = 0xc3d69000
> >>>> exception_exit() at exception_exit
> >>>>           pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
> >>>>           sp = 0xde0198e8  fp = 0xde019a20
> >>>>           r0 = 0xd0238120  r1 = 0x00000e60
> >>>>           r2 = 0x00000000  r3 = 0x00000000
> >>>>           r4 = 0x00000120  r5 = 0x00000000
> >>>>           r6 = 0xc3f3f6c0  r7 = 0x00001000
> >>>>           r8 = 0xc443e880  r9 = 0x00000000
> >>>>          r10 = 0xc3d69000 r12 = 0xd0238120
> >>>> memset() at memset+0x48
> >>>>           pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
> >>>>           sp = 0xde0198e8  fp = 0xde019a20
> >>>> Unwind failure (no registers changed)
> >>> No more beyond this?   If you could run addr2line on 0xc0d53828 so
> >>> that we know where in ffs_truncate it's failing, that'd be very
> >>> nice...
> >> So I was trying to save the coredump in  order to reboot and run
> >> addr2line, but that failed:
> >>
> >> Physical memory: 504 MB
> >> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f20
> >> 00 00 01 00  <sip:2000000100>
> >> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable
> >> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted
> >> Aborting dump due to I/O error.
> >>
> >> ** DUMP FAILED (ERROR 5) **
> >>
> >> So I guess this error is related to the CAM errors I'm getting from time
> >> to time. I was hoping that those errors were related to the INVARIANTS
> >> option that slowed down the system and thus might have triggered CAM
> >> errors, but obviously the SD Card seems to be the real issue here.
> >> So no crashdump for further analysis.
> > That's fine.. w/ the addr2line we have some lines to explore...
> >
> >> Interestingly the CAM errors didn't show up on the terminal as other
> >> times, the kernel just panicked straight away.
> > Hmm.. that is odd.. someone who knows the SD card layer should look
> > at this part...  It could be that the SD card driver doesn't handle
> > dumping (there is this global flag that gets set) properly and the driver
> > needs to behave differently when it's set...
> 
> I also need to grab a new SD card, just to make sure it's really not the 
> card.
> 
> >
> >> But I've got the addr2line output, even though I'm not sure it makes any
> >> difference:
> >>
> >> addr2line -f -e /mnt/kernel.debug 0xc0d53828
> >>
> >> ffs_truncate
> >> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321
> > can you give me the contents of the line?  and a few lines of context
> > around it?   In HEAD's source, this is DOINGASYNC, and there is no call
> > to memset, nor a variable assignment that would result in memset being
> > called...
> 
> Same here.. The file hasn't been changed in a while (Fri, 31 May 2013):
> 
>                  ip->i_size = length;
>                  DIP_SET(ip, i_size, length);
>                  if (bp->b_bufsize == fs->fs_bsize)
>                          bp->b_flags |= B_CLUSTEROK;
>                  if (flags & IO_SYNC)
>                          bwrite(bp);
> 321:        else if (DOINGASYNC(vp))
>                          bdwrite(bp);
>                  else
>                          bawrite(bp);
>                  ip->i_flag |= IN_CHANGE | IN_UPDATE;
>                  return (ffs_update(vp, !DOINGASYNC(vp)));
> 
> No idea what's going on.
> 
> >>>> The sad thing is, that with fsck broken for the dreamplug, I have to
> >>>> re-format the disk, reinstall everything and recreate the config files
> >>>> which I didn't manage to copy to a safe place beforehand :-(
> >> Didn't get around yet on checking whether the fsck issue persists if
> >> everything is compiled with gcc. Will take a bit, as I'm going to be on
> >> holidays for the next one and a half weeks. Fact is though, fsck is
> >> broken on the Dreamplug (ARMv5TE), at least when run on EVERY device
> >> that is attached via USB and if compiled with CLANG.
> >>>> Before I do that I'll leave the system in debugging mode for a few days,
> >>>> in case someone can help and needs some more information.
> >> Currently I've run fsck on all the disks/cards that had a working world
> >> for the dreamplug on it, so they're all gone. Can't do eny debugging
> >> atm. I'll let you know hoe the gcc build goes once I'm back from
> >> holidays though.
> > Hmmm. this is also worth investigating as it could be that clang is
> > producing bad code somewhere...
> 
> I'm trying to get kernel and world compiled with gcc atm. It fails 
> though, as somehow the armv7 code is currently broken... and the 
> toolchain build is not happy.
> 
> In file included from 
> /usr/devel/dreamplug/sys/arm/arm/cpufunc_asm_armv7.S:36:
> ./machine/sysreg.h:97:5: error: "__ARM_ARCH" is not defined
> 
> (followed by a few more of those)
> 
> My build command:
> 
>   make TARGET=arm TARGET_ARCH=arm DESTDIR=/usr/devel/dreamplug-dist 
> KERNCONF=DREAMPLUG-1001 -DWITHOUT_SHAREDOCS -DWITHOUT_EXAMPLES 
> -DWITHOUT_HTML -DWITHOUT_MAN -DWITHOUT_GAMES toolchain buildworld kernel 
> installworld


The build was broken briefly yesterday, you must have grabbed it during
that window.

But... I did a gcc build and got the same results as with clang.

-- Ian



From ian at FreeBSD.org  Tue Sep 30 14:19:58 2014
From: ian at FreeBSD.org (Ian Lepore)
Date: Tue, 30 Sep 2014 08:19:55 -0600
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <542AB897.3020309@gmail.com>
References: <542559BC.7090100@gmail.com>
 <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com>
 <20140930112937.GU43300@funkthat.com> <542A9EA4.70109@gmail.com>
 <20140930123010.GZ43300@funkthat.com>  <542AB897.3020309@gmail.com>
Message-ID: <1412086795.66615.363.camel@revolution.hippie.lan>

On Tue, 2014-09-30 at 16:05 +0200, Mattia Rossi wrote:
> Am 30.09.2014 14:30, schrieb John-Mark Gurney:
> > Mattia Rossi wrote this message on Tue, Sep 30, 2014 at 14:14 +0200:
> >> Am 30.09.2014 13:29, schrieb John-Mark Gurney:
> >>> Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200:
> >>>> Am 29.09.2014 06:01, schrieb John-Mark Gurney:
> >>>>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
> >>>>>> This might be part of the weird FFS issues the Dreamplug has and no-one
> >>>>>> knows why they're happening.
> >>>>> Are you running w/ FFS journaling?  If so, try turning it off, but
> >>>>> keeping softupdates on..
> >>>> No journaling, no softupdates. I'll try enabling softupdates next time.
> >>>> don't know if it will panic though
> >>>>>> data_abort_handler() at data_abort_handler+0x5c0
> >>>>>>           pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
> >>>>>>           sp = 0xde019898  fp = 0xde019a20
> >>>>>>           r4 = 0xffffffff  r5 = 0xffff1004
> >>>>>>           r6 = 0xc3f3f6c0  r7 = 0x00001000
> >>>>>>           r8 = 0xc443e880  r9 = 0x00000000
> >>>>>>          r10 = 0xc3d69000
> >>>>>> exception_exit() at exception_exit
> >>>>>>           pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
> >>>>>>           sp = 0xde0198e8  fp = 0xde019a20
> >>>>>>           r0 = 0xd0238120  r1 = 0x00000e60
> >>>>>>           r2 = 0x00000000  r3 = 0x00000000
> >>>>>>           r4 = 0x00000120  r5 = 0x00000000
> >>>>>>           r6 = 0xc3f3f6c0  r7 = 0x00001000
> >>>>>>           r8 = 0xc443e880  r9 = 0x00000000
> >>>>>>          r10 = 0xc3d69000 r12 = 0xd0238120
> >>>>>> memset() at memset+0x48
> >>>>>>           pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
> >>>>>>           sp = 0xde0198e8  fp = 0xde019a20
> >>>>>> Unwind failure (no registers changed)
> >>>>> No more beyond this?   If you could run addr2line on 0xc0d53828 so
> >>>>> that we know where in ffs_truncate it's failing, that'd be very
> >>>>> nice...
> >>>> So I was trying to save the coredump in  order to reboot and run
> >>>> addr2line, but that failed:
> >>>>
> >>>> Physical memory: 504 MB
> >>>> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f20
> >>>> 00 00 01 00  <sip:2000000100>
> >>>> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable
> >>>> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted
> >>>> Aborting dump due to I/O error.
> >>>>
> >>>> ** DUMP FAILED (ERROR 5) **
> >>>>
> >>>> So I guess this error is related to the CAM errors I'm getting from time
> >>>> to time. I was hoping that those errors were related to the INVARIANTS
> >>>> option that slowed down the system and thus might have triggered CAM
> >>>> errors, but obviously the SD Card seems to be the real issue here.
> >>>> So no crashdump for further analysis.
> >>> That's fine.. w/ the addr2line we have some lines to explore...
> >>>
> >>>> Interestingly the CAM errors didn't show up on the terminal as other
> >>>> times, the kernel just panicked straight away.
> >>> Hmm.. that is odd.. someone who knows the SD card layer should look
> >>> at this part...  It could be that the SD card driver doesn't handle
> >>> dumping (there is this global flag that gets set) properly and the driver
> >>> needs to behave differently when it's set...
> >> I also need to grab a new SD card, just to make sure it's really not the
> >> card.
> >>
> >>>> But I've got the addr2line output, even though I'm not sure it makes any
> >>>> difference:
> >>>>
> >>>> addr2line -f -e /mnt/kernel.debug 0xc0d53828
> >>>>
> >>>> ffs_truncate
> >>>> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321
> >>> can you give me the contents of the line?  and a few lines of context
> >>> around it?   In HEAD's source, this is DOINGASYNC, and there is no call
> >>> to memset, nor a variable assignment that would result in memset being
> >>> called...
> >> Same here.. The file hasn't been changed in a while (Fri, 31 May 2013):
> >>
> >>                  ip->i_size = length;
> >>                  DIP_SET(ip, i_size, length);
> >>                  if (bp->b_bufsize == fs->fs_bsize)
> >>                          bp->b_flags |= B_CLUSTEROK;
> >>                  if (flags & IO_SYNC)
> >>                          bwrite(bp);
> >> 321:        else if (DOINGASYNC(vp))
> >>                          bdwrite(bp);
> >>                  else
> >>                          bawrite(bp);
> >>                  ip->i_flag |= IN_CHANGE | IN_UPDATE;
> >>                  return (ffs_update(vp, !DOINGASYNC(vp)));
> >>
> >> No idea what's going on.
> > ok, could you send me the output of objdump -dSl, but you only need
> > to include the part from XXXXX <ffs_truncate>: to the next XXX<func>:
> > line...  probably off list as it'll be quite long...
> I'm sorry, but given that I just broke all my working worlds using fsck, 
> I'm not going to be able to do that until I'm back from holidays.... 
> currently working on the stuff remotely and after today's work day, I'm 
> not going to be able to get my hands on the dreamplug.
> 
> 

BTW, for anyone playing with this problem, step one is to edit
your /etc/fstab and set the fsck pass number to 0 for all filesystems.
There's a risk of filesystem corruption after a crash, but it's smaller
than the 100% corruption rate of letting fsck run. :)

-- Ian



From mattia.rossi.mailinglists at gmail.com  Tue Sep 30 14:26:05 2014
From: mattia.rossi.mailinglists at gmail.com (Mattia Rossi)
Date: Tue, 30 Sep 2014 16:25:58 +0200
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <1412086661.66615.361.camel@revolution.hippie.lan>
References: <542559BC.7090100@gmail.com>	
 <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com>	
 <20140930112937.GU43300@funkthat.com> <542A9EA4.70109@gmail.com>
 <1412086661.66615.361.camel@revolution.hippie.lan>
Message-ID: <542ABD76.1050602@gmail.com>


Am 30.09.2014 16:17, schrieb Ian Lepore:
> On Tue, 2014-09-30 at 14:14 +0200, Mattia Rossi wrote:
>> Am 30.09.2014 13:29, schrieb John-Mark Gurney:
>>> Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200:
>>>> Am 29.09.2014 06:01, schrieb John-Mark Gurney:
>>>>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
>>>>>> This might be part of the weird FFS issues the Dreamplug has and no-one
>>>>>> knows why they're happening.
>>>>> Are you running w/ FFS journaling?  If so, try turning it off, but
>>>>> keeping softupdates on..
>>>> No journaling, no softupdates. I'll try enabling softupdates next time.
>>>> don't know if it will panic though
>>>>>> data_abort_handler() at data_abort_handler+0x5c0
>>>>>>            pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
>>>>>>            sp = 0xde019898  fp = 0xde019a20
>>>>>>            r4 = 0xffffffff  r5 = 0xffff1004
>>>>>>            r6 = 0xc3f3f6c0  r7 = 0x00001000
>>>>>>            r8 = 0xc443e880  r9 = 0x00000000
>>>>>>           r10 = 0xc3d69000
>>>>>> exception_exit() at exception_exit
>>>>>>            pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>>>>>>            sp = 0xde0198e8  fp = 0xde019a20
>>>>>>            r0 = 0xd0238120  r1 = 0x00000e60
>>>>>>            r2 = 0x00000000  r3 = 0x00000000
>>>>>>            r4 = 0x00000120  r5 = 0x00000000
>>>>>>            r6 = 0xc3f3f6c0  r7 = 0x00001000
>>>>>>            r8 = 0xc443e880  r9 = 0x00000000
>>>>>>           r10 = 0xc3d69000 r12 = 0xd0238120
>>>>>> memset() at memset+0x48
>>>>>>            pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>>>>>>            sp = 0xde0198e8  fp = 0xde019a20
>>>>>> Unwind failure (no registers changed)
>>>>> No more beyond this?   If you could run addr2line on 0xc0d53828 so
>>>>> that we know where in ffs_truncate it's failing, that'd be very
>>>>> nice...
>>>> So I was trying to save the coredump in  order to reboot and run
>>>> addr2line, but that failed:
>>>>
>>>> Physical memory: 504 MB
>>>> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f20
>>>> 00 00 01 00  <sip:2000000100>
>>>> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable
>>>> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted
>>>> Aborting dump due to I/O error.
>>>>
>>>> ** DUMP FAILED (ERROR 5) **
>>>>
>>>> So I guess this error is related to the CAM errors I'm getting from time
>>>> to time. I was hoping that those errors were related to the INVARIANTS
>>>> option that slowed down the system and thus might have triggered CAM
>>>> errors, but obviously the SD Card seems to be the real issue here.
>>>> So no crashdump for further analysis.
>>> That's fine.. w/ the addr2line we have some lines to explore...
>>>
>>>> Interestingly the CAM errors didn't show up on the terminal as other
>>>> times, the kernel just panicked straight away.
>>> Hmm.. that is odd.. someone who knows the SD card layer should look
>>> at this part...  It could be that the SD card driver doesn't handle
>>> dumping (there is this global flag that gets set) properly and the driver
>>> needs to behave differently when it's set...
>> I also need to grab a new SD card, just to make sure it's really not the
>> card.
>>
>>>> But I've got the addr2line output, even though I'm not sure it makes any
>>>> difference:
>>>>
>>>> addr2line -f -e /mnt/kernel.debug 0xc0d53828
>>>>
>>>> ffs_truncate
>>>> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321
>>> can you give me the contents of the line?  and a few lines of context
>>> around it?   In HEAD's source, this is DOINGASYNC, and there is no call
>>> to memset, nor a variable assignment that would result in memset being
>>> called...
>> Same here.. The file hasn't been changed in a while (Fri, 31 May 2013):
>>
>>                   ip->i_size = length;
>>                   DIP_SET(ip, i_size, length);
>>                   if (bp->b_bufsize == fs->fs_bsize)
>>                           bp->b_flags |= B_CLUSTEROK;
>>                   if (flags & IO_SYNC)
>>                           bwrite(bp);
>> 321:        else if (DOINGASYNC(vp))
>>                           bdwrite(bp);
>>                   else
>>                           bawrite(bp);
>>                   ip->i_flag |= IN_CHANGE | IN_UPDATE;
>>                   return (ffs_update(vp, !DOINGASYNC(vp)));
>>
>> No idea what's going on.
>>
>>>>>> The sad thing is, that with fsck broken for the dreamplug, I have to
>>>>>> re-format the disk, reinstall everything and recreate the config files
>>>>>> which I didn't manage to copy to a safe place beforehand :-(
>>>> Didn't get around yet on checking whether the fsck issue persists if
>>>> everything is compiled with gcc. Will take a bit, as I'm going to be on
>>>> holidays for the next one and a half weeks. Fact is though, fsck is
>>>> broken on the Dreamplug (ARMv5TE), at least when run on EVERY device
>>>> that is attached via USB and if compiled with CLANG.
>>>>>> Before I do that I'll leave the system in debugging mode for a few days,
>>>>>> in case someone can help and needs some more information.
>>>> Currently I've run fsck on all the disks/cards that had a working world
>>>> for the dreamplug on it, so they're all gone. Can't do eny debugging
>>>> atm. I'll let you know hoe the gcc build goes once I'm back from
>>>> holidays though.
>>> Hmmm. this is also worth investigating as it could be that clang is
>>> producing bad code somewhere...
>> I'm trying to get kernel and world compiled with gcc atm. It fails
>> though, as somehow the armv7 code is currently broken... and the
>> toolchain build is not happy.
>>
>> In file included from
>> /usr/devel/dreamplug/sys/arm/arm/cpufunc_asm_armv7.S:36:
>> ./machine/sysreg.h:97:5: error: "__ARM_ARCH" is not defined
>>
>> (followed by a few more of those)
>>
>> My build command:
>>
>>    make TARGET=arm TARGET_ARCH=arm DESTDIR=/usr/devel/dreamplug-dist
>> KERNCONF=DREAMPLUG-1001 -DWITHOUT_SHAREDOCS -DWITHOUT_EXAMPLES
>> -DWITHOUT_HTML -DWITHOUT_MAN -DWITHOUT_GAMES toolchain buildworld kernel
>> installworld
>
> The build was broken briefly yesterday, you must have grabbed it during
> that window.
>
> But... I did a gcc build and got the same results as with clang.
>
Thanks, I just read that, so I'm going to pass on this :-)


From mattia.rossi.mailinglists at gmail.com  Tue Sep 30 14:29:30 2014
From: mattia.rossi.mailinglists at gmail.com (Mattia Rossi)
Date: Tue, 30 Sep 2014 16:29:25 +0200
Subject: Random Kernel Panic on Dreamplug (FS related)
In-Reply-To: <1412086795.66615.363.camel@revolution.hippie.lan>
References: <542559BC.7090100@gmail.com>	
 <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com>	
 <20140930112937.GU43300@funkthat.com> <542A9EA4.70109@gmail.com>	
 <20140930123010.GZ43300@funkthat.com> <542AB897.3020309@gmail.com>
 <1412086795.66615.363.camel@revolution.hippie.lan>
Message-ID: <542ABE45.3020402@gmail.com>


Am 30.09.2014 16:19, schrieb Ian Lepore:
> On Tue, 2014-09-30 at 16:05 +0200, Mattia Rossi wrote:
>> Am 30.09.2014 14:30, schrieb John-Mark Gurney:
>>> Mattia Rossi wrote this message on Tue, Sep 30, 2014 at 14:14 +0200:
>>>> Am 30.09.2014 13:29, schrieb John-Mark Gurney:
>>>>> Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200:
>>>>>> Am 29.09.2014 06:01, schrieb John-Mark Gurney:
>>>>>>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200:
>>>>>>>> This might be part of the weird FFS issues the Dreamplug has and no-one
>>>>>>>> knows why they're happening.
>>>>>>> Are you running w/ FFS journaling?  If so, try turning it off, but
>>>>>>> keeping softupdates on..
>>>>>> No journaling, no softupdates. I'll try enabling softupdates next time.
>>>>>> don't know if it will panic though
>>>>>>>> data_abort_handler() at data_abort_handler+0x5c0
>>>>>>>>            pc = 0xc0de7a28  lr = 0xc0dd711c (exception_exit)
>>>>>>>>            sp = 0xde019898  fp = 0xde019a20
>>>>>>>>            r4 = 0xffffffff  r5 = 0xffff1004
>>>>>>>>            r6 = 0xc3f3f6c0  r7 = 0x00001000
>>>>>>>>            r8 = 0xc443e880  r9 = 0x00000000
>>>>>>>>           r10 = 0xc3d69000
>>>>>>>> exception_exit() at exception_exit
>>>>>>>>            pc = 0xc0dd711c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>>>>>>>>            sp = 0xde0198e8  fp = 0xde019a20
>>>>>>>>            r0 = 0xd0238120  r1 = 0x00000e60
>>>>>>>>            r2 = 0x00000000  r3 = 0x00000000
>>>>>>>>            r4 = 0x00000120  r5 = 0x00000000
>>>>>>>>            r6 = 0xc3f3f6c0  r7 = 0x00001000
>>>>>>>>            r8 = 0xc443e880  r9 = 0x00000000
>>>>>>>>           r10 = 0xc3d69000 r12 = 0xd0238120
>>>>>>>> memset() at memset+0x48
>>>>>>>>            pc = 0xc0de521c  lr = 0xc0d53828 (ffs_truncate+0xaa8)
>>>>>>>>            sp = 0xde0198e8  fp = 0xde019a20
>>>>>>>> Unwind failure (no registers changed)
>>>>>>> No more beyond this?   If you could run addr2line on 0xc0d53828 so
>>>>>>> that we know where in ffs_truncate it's failing, that'd be very
>>>>>>> nice...
>>>>>> So I was trying to save the coredump in  order to reboot and run
>>>>>> addr2line, but that failed:
>>>>>>
>>>>>> Physical memory: 504 MB
>>>>>> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f20
>>>>>> 00 00 01 00  <sip:2000000100>
>>>>>> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable
>>>>>> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted
>>>>>> Aborting dump due to I/O error.
>>>>>>
>>>>>> ** DUMP FAILED (ERROR 5) **
>>>>>>
>>>>>> So I guess this error is related to the CAM errors I'm getting from time
>>>>>> to time. I was hoping that those errors were related to the INVARIANTS
>>>>>> option that slowed down the system and thus might have triggered CAM
>>>>>> errors, but obviously the SD Card seems to be the real issue here.
>>>>>> So no crashdump for further analysis.
>>>>> That's fine.. w/ the addr2line we have some lines to explore...
>>>>>
>>>>>> Interestingly the CAM errors didn't show up on the terminal as other
>>>>>> times, the kernel just panicked straight away.
>>>>> Hmm.. that is odd.. someone who knows the SD card layer should look
>>>>> at this part...  It could be that the SD card driver doesn't handle
>>>>> dumping (there is this global flag that gets set) properly and the driver
>>>>> needs to behave differently when it's set...
>>>> I also need to grab a new SD card, just to make sure it's really not the
>>>> card.
>>>>
>>>>>> But I've got the addr2line output, even though I'm not sure it makes any
>>>>>> difference:
>>>>>>
>>>>>> addr2line -f -e /mnt/kernel.debug 0xc0d53828
>>>>>>
>>>>>> ffs_truncate
>>>>>> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321
>>>>> can you give me the contents of the line?  and a few lines of context
>>>>> around it?   In HEAD's source, this is DOINGASYNC, and there is no call
>>>>> to memset, nor a variable assignment that would result in memset being
>>>>> called...
>>>> Same here.. The file hasn't been changed in a while (Fri, 31 May 2013):
>>>>
>>>>                   ip->i_size = length;
>>>>                   DIP_SET(ip, i_size, length);
>>>>                   if (bp->b_bufsize == fs->fs_bsize)
>>>>                           bp->b_flags |= B_CLUSTEROK;
>>>>                   if (flags & IO_SYNC)
>>>>                           bwrite(bp);
>>>> 321:        else if (DOINGASYNC(vp))
>>>>                           bdwrite(bp);
>>>>                   else
>>>>                           bawrite(bp);
>>>>                   ip->i_flag |= IN_CHANGE | IN_UPDATE;
>>>>                   return (ffs_update(vp, !DOINGASYNC(vp)));
>>>>
>>>> No idea what's going on.
>>> ok, could you send me the output of objdump -dSl, but you only need
>>> to include the part from XXXXX <ffs_truncate>: to the next XXX<func>:
>>> line...  probably off list as it'll be quite long...
>> I'm sorry, but given that I just broke all my working worlds using fsck,
>> I'm not going to be able to do that until I'm back from holidays....
>> currently working on the stuff remotely and after today's work day, I'm
>> not going to be able to get my hands on the dreamplug.
>>
>>
> BTW, for anyone playing with this problem, step one is to edit
> your /etc/fstab and set the fsck pass number to 0 for all filesystems.
> There's a risk of filesystem corruption after a crash, but it's smaller
> than the 100% corruption rate of letting fsck run. :)
>
Of course! Great idea :-) Sometimes just can't think of the right tweak 
to save a lot of pain...

Anyhow, I just found out, that I was rebooting the dreamplug from the sd 
card instead of the usb stick the whole time, and the usb stick hasn't 
been damaged enough by fsck, so it actually booted :-) I'll send the 
objdump soon.

From shigeru at os-hackers.jp  Tue Sep 30 16:25:12 2014
From: shigeru at os-hackers.jp (YAMAMOTO Shigeru)
Date: Wed, 01 Oct 2014 01:05:28 +0900 (JST)
Subject: FreeBSD 10.1-BETA3 Now Available
In-Reply-To: <20140929.142712.117419748410715004.shigeru@os-hackers.jp>
References: <20140929023616.GG75063@hub.FreeBSD.org>
 <20140929123327.6ab0207c@X220.alogt.com>
 <20140929.142712.117419748410715004.shigeru@os-hackers.jp>
Message-ID: <20141001.010528.1222668648660002950.shigeru@os-hackers.jp>


Hi,

>>>>> "shigeru" == YAMAMOTO Shigeru <shigeru at os-hackers.jp> writes:
>>>>> "Erich" == Erich Dollansky <erichsfreebsdlist at alogt.com> writes:
>> On Sun, 28 Sep 2014 22:36:16 -0400 Glen Barber <gjb at FreeBSD.org> wrote:
>> Why not try the images already available here?
>> http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/
>> I have tried it now several times. All with the same result.

I get SD image, FreeBSD-10.1-BETA3-arm-armv6-RPI-B.img.bz2, from that URL.

When using original SD image, I can't boot because a kernel does not find
root file system.

I get a new firmware from https://github.com/raspberrypi/firmware/
 and I replace *.dat, *.elf in SD image.

 # git clone https://github.com/raspberrypi/firmware.git
 # mount_msdosfs /dev/da0s1 /mnt
 # cp ./firmware/boot/*.dat /mnt/.
 # cp ./firmware/boot/*.elf /mnt/.
 # umount /mnt

After replacing firmware image in SD image, I can boot RaspberryPi B+.

------------------------------------------------------------------------
root at raspberry-pi:~ # dmesg
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2014 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 10.1-BETA3 #0 r272167: Fri Sep 26 16:53:33 UTC 2014
    root at releng1.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
VT: init without driver.
CPU: ARM1176JZ-S rev 7 (ARM11J core)
 Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext
 WB enabled LABT branch prediction enabled
  16KB/32B 4-way instruction cache
  16KB/32B 4-way write-back-locking-C data cache
real memory  = 536866816 (511 MB)
avail memory = 482893824 (460 MB)
random: <Software, Yarrow> initialized
kbd0 at kbdmux0
ofwbus0: <Open Firmware Device Tree>
simplebus0: <Flattened device tree simple bus> mem 0x20000000-0x20ffffff on
ofwbus0
intc0: <BCM2835 Interrupt Controller> mem 0xb200-0xb3ff on simplebus0
systimer0: <BCM2835 System Timer> mem 0x3000-0x3fff irq 8,9,10,11 on
simplebus0
Event timer "BCM2835 Event Timer 3" frequency 1000000 Hz quality 1000
Timecounter "BCM2835 Timecounter" frequency 1000000 Hz quality 1000
bcmwd0: <BCM2708/2835 Watchdog> mem 0x10001c-0x100027 on simplebus0
gpio0: <BCM2708/2835 GPIO controller> mem 0x200000-0x2000af irq 57,59,58,60
on simplebus0
gpio0: read-only pins: 46,47,48,49,50,51,52,53.
gpio0: reserved pins: 48,49,50,51,52,53.
gpioc0: <GPIO controller> on gpio0
gpiobus0: <OFW GPIO bus> on gpio0
gpioled0: <GPIO led> at pin(s) 16 on gpiobus0
iichb0: <BCM2708/2835 BSC controller> mem 0x205000-0x20501f irq 61 on
simplebus0
iicbus0: <OFW I2C bus> on iichb0
iic0: <I2C generic I/O> on iicbus0
iichb1: <BCM2708/2835 BSC controller> mem 0x804000-0x80401f irq 61 on
simplebus0
iicbus1: <OFW I2C bus> on iichb1
iic1: <I2C generic I/O> on iicbus1
spi0: <BCM2708/2835 SPI controller> mem 0x204000-0x20401f irq 62 on
simplebus0
spibus0: <OFW SPI bus> on spi0
bcm_dma0: <BCM2835 DMA Controller> mem 0x7000-0x7fff,0xe05000-0xe05fff irq
24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0
mbox0: <BCM2835 VideoCore Mailbox> mem 0xb880-0xb8bf irq 1 on simplebus0
sdhci_bcm0: <Broadcom 2708 SDHCI controller> mem 0x300000-0x3000ff irq 70 on
simplebus0
mmc0: <MMC/SD bus> on sdhci_bcm0
uart0: <PrimeCell UART (PL011)> mem 0x201000-0x201fff irq 65 on simplebus0
uart0: console (115200,n,8,1)
dwcotg0: <DWC OTG 2.0 integrated USB controller> mem 0x980000-0x99ffff irq
17 on simplebus0
usbus0 on dwcotg0
fb0: <BCM2835 VT framebuffer driver> on ofwbus0
simplebus1: <Flattened device tree simple bus> on ofwbus0
simplebus1: could not get ranges
device_attach: simplebus1 attach returned 6
Timecounters tick every 10.000 msec
usbus0: 480Mbps High Speed USB v2.0
ugen0.1: <DWCOTG> at usbus0
uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
uhub0: 1 port with 1 removable, self powered
mmcsd0: 2GB <SD 00000 1.0 SN CBDADEB8 MFG 05/2014 by 27 SM> at mmc0
25.0MHz/1bit/65535-block
fb0: 656x416(0x0 at 0,0) 16bpp
fb0: pitch 1312, base 0x5e006000, screen_size 545792
fbd0 on fb0
VT: initialize with new VT driver "fb".
ugen0.2: <vendor 0x0424> at usbus0
uhub1: <vendor 0x0424 product 0x9514, class 9/0, rev 2.00/2.00, addr 2> on
usbus0
uhub1: MTT enabled
random: unblocking device.
Root mount waiting for: usbus0
uhub1: 5 ports with 4 removable, self powered
Root mount waiting for: usbus0
ugen0.3: <vendor 0x0424> at usbus0
smsc0: <vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3> on usbus0
Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]...
smsc0: chip 0xec00, rev. 0002
miibus0: <MII bus> on smsc0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
warning: no time-of-day clock registered, system time will not be set
accurately
ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0: <USB Ethernet> on smsc0
ue0: Ethernet address: b8:27:eb:50:ce:e0
GEOM_PART: mmcsd0s2 was automatically resized.
  Use `gpart commit mmcsd0s2` to save changes or `gpart undo mmcsd0s2` to
  revert them.
smsc0: chip 0xec00, rev. 0002
------------------------------------------------------------------------

Thanks,
---
YAMAMOTO Shigeru <shigeru at os-hackers.jp>

From erichsfreebsdlist at alogt.com  Tue Sep 30 23:50:30 2014
From: erichsfreebsdlist at alogt.com (Erich Dollansky)
Date: Wed, 1 Oct 2014 07:50:17 +0800
Subject: FreeBSD 10.1-BETA3 Now Available
In-Reply-To: <20141001.010528.1222668648660002950.shigeru@os-hackers.jp>
References: <20140929023616.GG75063@hub.FreeBSD.org>
 <20140929123327.6ab0207c@X220.alogt.com>
 <20140929.142712.117419748410715004.shigeru@os-hackers.jp>
 <20141001.010528.1222668648660002950.shigeru@os-hackers.jp>
Message-ID: <20141001075017.04a1b002@X220.alogt.com>

Hi,

On Wed, 01 Oct 2014 01:05:28 +0900 (JST)
YAMAMOTO Shigeru <shigeru at os-hackers.jp> wrote:

> >>>>> "shigeru" == YAMAMOTO Shigeru <shigeru at os-hackers.jp> writes:
> >>>>> "Erich" == Erich Dollansky <erichsfreebsdlist at alogt.com> writes:
> >> On Sun, 28 Sep 2014 22:36:16 -0400 Glen Barber <gjb at FreeBSD.org>
> >> wrote: Why not try the images already available here?
> >> http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/
> >> I have tried it now several times. All with the same result.
> 
> I get SD image, FreeBSD-10.1-BETA3-arm-armv6-RPI-B.img.bz2, from that
> URL.
> 
> When using original SD image, I can't boot because a kernel does not
> find root file system.
> 
I do not see any messages as I still do not have a monitor cable.

> I get a new firmware from https://github.com/raspberrypi/firmware/
>  and I replace *.dat, *.elf in SD image.
> 
It seems that I did something wrong then.

The Raspberry is currently compiling world. It should be finished with
it only tomorrow.

>  # git clone https://github.com/raspberrypi/firmware.git
>  # mount_msdosfs /dev/da0s1 /mnt
>  # cp ./firmware/boot/*.dat /mnt/.
>  # cp ./firmware/boot/*.elf /mnt/.
>  # umount /mnt
> 
I replaced all files.

Erich