u-boot-rpi* has the existing "make first page reserved" code (shown); this appears to be where any fix would go (it works without FreeBSD changes)

[Mark Millard]

On 2020-Feb-14, at 01:54, Klaus Küchemann <maciphone2 at googlemail.com> wrote:


>> Am 14.02.2020 um 02:16 schrieb Mark Millard <marklmi at yahoo.com>:
>> 
>> [The sysutils/u-boot-rpi* change is sufficient to
>> be a work around allowing existing FreeBSD versions
>> to be used (up to other separate problems).]
>> …
>> ..
>> 
>> (I make no claim to know the best direction for a
>> long term fix.)
>> 
>> 
>> ===
>> Mark Millard
>> marklmi at yahoo.com
>> ( dsl-only.net went
>> away in early 2018-Mar)
> 
> 
> Hi,
> 
> I really like that you investigate in solving the breakage, thank you!

For the root cause identification, you are welcome.

(I've not proposed a solution for FreeBSD to adopt.)

> But your workflow is somewhat in the downstream direction
> where it should be on the upstream.
>  sysutils/u-boot-rpi* Is somewhat outdated . U-boot is currently v2020. 01 ,
> so the direction should be to 1st upgrade sysutils/u-boot to v2020. 01.
> After that you „test" 2020.01 , then if necessary you hack it, send a patch 
> to fbsd-u-boot, and if that patch would be universal to u-boot , fbsd will send the 
> patch to u-boot itself( if not yet available there).
> Or vice versa fbsd will upgrade 2020.01 with a current patch from u-boot upstream .
> So the first place where you should look for is the u-boot upstream.
> The reason for that is that if we all hack our own versions we will completely 
> out of sync. 
> AFAIK ‚manu' ( e.g.  https://reviews.freebsd.org/D23592 ) is responsible 
> for syncing upstreams, I would recommend you to contact him to ask where and when he wants to go
> with u-boot and the DTBs and so on.
> I hope this helps a little to send your work to the right addresses…
> 
> If you do sync your work with the upstream you absolutely have the right to claim your "long term fix“ . ;-)

My goal was to:

A) Identify root cause, in this case incorrect/incomplete
   identification to the kernel of what pages the kernel
   should avoid touching.

B) Validate the identification (given the code involved is
   unfamiliar: u-boot, FreeBSD, even source for the DTB).

(B) just ends up being identifying workarounds and 
demonstrating that they work in the test context
that I have. Others reporting on other test contexts
helps with this.

I view (B) as part of (A).

I would never try to do (A/B) by not using a known-broken
combination of code. For example, I'd never introduce
other issues by switching to more recent u-boot version
just for (A/B).


Having a hand coded constant in u-boot indicating the size in pages
of armstub8*.bin looks fragile to me --and has already been proven
fragile for the original figure and hard to find when it does not
work. I'd not propose the technique as a long term solution, meaning
I do not expect or want FreeBSD to adopt the technique.

(Folks vastly more familiar with this stuff did not report on the
possibility when the breakage was noticed. I assume it was not
obvious to them.)

I also do not see a communication path for the size to be reported
to u-boot so that it could automatically adjust.

I would not expect or want FreeBSD to adopt my original, investigative
FreeBSD-based hack/workaround either: Just as fragile.


It is not obvious to me what a long term solution would be.

I've used a bunch of time on just (A/B). Having done (A/B), I'm not
expecting to spend much more time in the general subject area.


As for involving "manu", Kyle added him to the CC list so manu
has been notified of the status of things as things progressed.
But it is not obvious to me that manu would want to be involved.
The notifications are enough, possibly more than manu would
prefer.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)