FreeBSD 10.0-STABLE on EdgeRouter Lite notes/issues

[Sean Hamilton]

On 28 August 2014 12:59, Stacey Son <sson at freebsd.org> wrote:
> Yeah, the ERL u-boot seems kind of simple.  You may have noticed that 'mkerlimage' puts /boot in a FAT partition.  Once the kernel is loaded you can do about any partitioning scheme you want.  IDK.   It would be nice if the ERL had a second USB or some onboard flash that could be used or something.

The ERL does have 4 MB NOR flash for u-boot, and I'm guessing most of
it is unused. You could surely put a kernel in there, if you could
make it fit. I produced a fairly minimal kernel configuration and its
.text is still >6MB, but the whole kernel xz's down to 1.8 MB, so
there's hope. I'm not sure if the flash can be written from FreeBSD,
though it can be written from u-boot.

I think it makes more sense to just dd the kernel directly to the USB
flash sans-filesystem, then use the "usb read" u-boot command to load
it. Then you don't need to worry about bricking your ERL.

>> I imagine this relates to the recent freebsd-mips posts about strip
>> corrupting static binaries.
>
> Yes, this is most likely the 'strip' bug.  See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191587 for the details.  The workaround is to not strip static libraries.

Building ports with INSTALL_TARGET=install (instead of the default
install-strip) seems to circumvent stripping for the most part.
Building e.g. python27 still doesn't work, possibly due to the strip
issue. I'll look into the strip bug if I can find time and nobody else
is on it.

Build performance on the ERL is tolerable, so long as you consider it
to be a non-interactive process. Some builds seem like they are
probably I/O bound, though I haven't actually measured. I'm still very
interested in suggestions as to if/how FreeBSD can be made to cache
and defer FS writes. I'm considering tmpfs and a rsync cronjob if it
can't be done in the kernel.

>> [ tcpdump problem ]
>
> You should file a bugzilla bug report especially if you have a packet trace that can be used to easily reproduce the problem.

The issue is trivial to reproduce. It doesn't seem to matter what the
payload is -- it reports huge packet lengths (possibly byte swapped)
and it quickly segfaults.