Progress on Raspberry Pi

[Tim Kientzle]

On Sep 20, 2013, at 5:49 PM, George Mitchell <george+freebsd at m5p.com> wrote:

> My AdaFruit serial cable arrived, so now I can gather useful information
> when my RPi crashes…

Excellent!

> I built my image with crochet on an amd64 running r255361, and the image
> itself is based on that version.  (However, in sys/arm/arm I updated
> pmap-v6.c to 255612 and stdatomic.c to 255613.  I see they have been
> updated again within the last day; perhaps I should try again.)
> 
> /etc/src.conf:
> MALLOC_PRODUCTION=yes
> 
> /etc/make.conf:
> WITH_PKGNG=yes
> MALLOC_PRODUCTION=yes
> # added by use.perl 2013-08-20 10:11:49
> PERL_VERSION=5.14.4

By default, Crochet ignores the host /etc/src.conf
and /etc/make.conf on the assumption that what
is right for the host system is not necessarily correct
for the target system.

If you specifically want to use them, you can add

SRCCONF=/etc/src.conf
__MAKE_CONF=/etc/make.conf

to your configuration file.  Of course, you can also put
src.conf and make.conf files elsewhere for Crochet to use.

> I commented out the five syscons-related lines in sys/arm/conf/RPI-B so
> I could use the serial port.  My SDHC card is apparently on the hairy
> edge of working, so I definitely needed /boot/loader.conf to contain:
> hw.bcm2835.sdhci.hs=0.  Before I added that, I ended up with the dreaded
> error 19 and a manual mountroot prompt, at which point mountroot would
> accept a character from the serial input about 1/4 of the time.  Other
> serial input works without a problem.

<sigh>  Keyboard input to mount root seems to
be broken on a lot of FreeBSD systems.

> Before I remembered to comment out the /dev/ttyvN lines in /etc/tty,…

Should Crochet's RaspberryPi configuration disable those?

> 2. Now that I can do something when I get the prefetch abort or panic,
> what should I do at the "db>" prompt to help debug it?  It's happening
> about five or six times a day.

Type "bt" to get a backtrace.  That's the single most informative
thing.  Note:  The first few stack frames displayed are from inside
the debugger itself and aren't particularly interesting.  The important
frames are a little later where we see *why* we ended up in the
debugger.

Tim