Difficulties updating RPi on 11-stable

[Peter Jeremy]

I've been trying to update my RPi model B from 11-stable r324674 to r328837
and ran into a number of gotcha's along the way.  Some I've resolved but I'm
still working on the final two.

1) Initially (somewhat prior to r328837), the new kernel would load and then
report:
Can't load file '/boot/kernel/kernel': input/output error
Searching the web didn't turn up any reports of this so I tried a from-
scratch kernel build, as well as updating (to r328837) in case I'd picked a
bad commit.  When that didn't work, I noticed that I was running 3-year
old firmware (January 2015) so I thought I'd try updating that...

2) After installing rpi-firmware-1.20171029, the GPU boot failed, displaying
the 4-pixel GPU spash screen and flashing the green LED 7 times (which means
kernel.img not found).  After some digging, I discovered that the expected
name of the third-stage bootloader had changed from uboot.img to u-boot.bin
(neither file is included in the firmware image).

After additionally installing u-boot.bin from u-boot-rpi-2017.09.00_1 I can
now boot either r324674 or r328837 but I would have saved a lot of wasted
time if the changed requirements had been documented.  There's nothing
mentioned in UPDATING.  I've gone through all the stable/11 arm commits in
the period in question and can't see any mention of a firmware
incompatibility.

I'm now left with 2 regressions that I haven't resolved:

3) 128MB of RAM has disappeared (losing ¼ of the available RAM is annoying).
With "gpu_mem=32", U-Boot loader reports "DRAM: 480MB" (which is unchanged
from before) but the dmesg output has changed from (r324674 kernel):
real memory  = 536866816 (511 MB)
avail memory = 482013184 (459 MB)
Physical memory chunk(s):
  0x00001000 - 0x1fffffff,   511 MB ( 131071 pages)
Excluded memory regions:
  0x00100000 - 0x00a44fff,     9 MB (   2373 pages) NoAlloc 
  0x1e000000 - 0x1fffffff,    32 MB (   8192 pages) NoAlloc NoDump
Static device mappings:
  0x20000000 - 0x20ffffff mapped at VA 0xfef00000

to (r328837 kernel):
real memory  = 503312384 (479 MB)
avail memory = 350699520 (334 MB)
Physical memory chunk(s):
  0x00001000 - 0x1dffffff,   479 MB ( 122879 pages)
Excluded memory regions:
  0x01200000 - 0x01b44fff,     9 MB (   2373 pages) NoAlloc 
  0x08000000 - 0x0fffffff,   128 MB (  32768 pages) NoAlloc NoDump
Static device mappings:
  0x20000000 - 0x20ffffff mapped at VA 0xfef00000

I think the problem here is that the kernel is the new line:
Preloaded dtb "/boot/dtb/bcm2835-rpi-b-rev2.dtb" at 0xc0806888.
This file compiled from sys/boot/fdt/dts/arm/rpi.dts which explicitly
reserves 128MB for the VideoCore.  The commit comment in r252439 (when the
memreserve was committed) was that the VideoCore binary patches it during
boot.  Whilst that may have been true in the past, it doesn't appear to be
true any longer (instead the memory reserved by the VideoCore is excluded
from the memory map passed to the CPU).  I suspect the correct fix is to
just remove the memreserve completely (though I haven't tried that yet).

4) The primary console is redirected to the UART instead of video.  Whilst
low-level output is directed to the video output, writes to /dev/console
don't go to the video, which is also annoying.  So far as the FreeBSD loader
is concerned, the only console device is "uboot".  I've tried building a new
boot.scr with stdout and stderr preferentially set to vidconsole to no avail.
Poking around in the kernel, ttyv0 is a potential console but has a priority
of CN_DEAD and it's not clear how to get the loader to tell the kernel to
preferentially use it.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20180211/75a74fe8/attachment.sig>