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)

Klaus Küchemann maciphone2 at googlemail.com
Fri Feb 14 15:32:06 UTC 2020



> Am 14.02.2020 um 12:20 schrieb Mark Millard <marklmi at yahoo.com>:
> 
> 
> 
> For the root cause identification, you are welcome.
> 
> (I've not proposed a solution for FreeBSD to adopt.)
> 

But THE SKULL( ..just kidding,,) has( proposed a solution for FreeBSD) :-) … ….  :
> Am 14.02.2020 um 11:10 schrieb Emmanuel Vadot :
> 
> On Fri, 14 Feb 2020 10:54:40 +0100
> 
> I have hold off the upgrade to 2020.01 as rockchip u-boot needs a
> newer ATF and they didn't made a new release yet. My plan is to wait
> until 2020.04 is release and if at that time there is still no new ATF
> release just update the ports to use the latest git version.


It couldn’t be clearer:
NO breakage for Rockchip as long as there is no usptream - RELEASE.
The only thing possible Manu could think about is backporting,
but of course only from the upstream and NOT from any hacks outside there.
Backporting is much work and perhaps not the way he wants to go, so it is to be accepted 
to wait for 2020.04 .


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

The communication-path is to track the u-boot upstream first.
If manu wouldn't do that, he would get complaints
for shutting down my RockPro64 ;-)

Nevertheless, Mark, thanks again investigating to retrack the root cause of RPI4 breakage.
And all that u-boot stuff is absolutely no reason to stop support the RPI4(if possible),
Just hook up your RPi4-version which boots and continue patching that messy gadget.
But please in the (fbsd-) upstream ...

just my two cents 

Regards

Klaus



More information about the freebsd-arm mailing list