RPI4 u-boot news Re: Showstoppers for RPI3

[Klaus Küchemann]

Thank you Mark ! 

https://wiki.freebsd.org/arm/Raspberry%20Pi

Additionally I provide a new 2020.01 u-boot-version…
see bottom of the Wiki-page...
( wrote that quick&dirty in a little hurry and hope I quoted the sense of your patch correctly)
If you want you can compile your hacked u-boot-version-
I`ll upload it then…as long as there are no kernel fixes , everything helpful will be uploaded ;-)
I’m working on another Rock-board for which I will provide fill support 
The next 2 or 3 days.
Stay tuned with the Wiki…

Thanks again and I would be happy if you could provide your hacks in 1 file..
It’s a developers Wiki…
And everybody has the same problem :
> Resource constrained by other priorities is not surprising in my view.
True but no reason to give up on such a device while other BSD´s are reaching the ACPI-Ethernet-stage…
We have to come up with results.. ;-)

Regards
Klaus





> Am 26.02.2020 um 07:18 schrieb Mark Millard <marklmi at yahoo.com>:
> 
> 
> 
> On 2020-Feb-25, at 21:32, Klaus Küchemann via freebsd-arm <freebsd-arm at freebsd.org> wrote:
> 
>>> Am 26.02.2020 um 06:20 schrieb bob prohaska <fbsd at www.zefox.net>:
>>> 
>>> 
>>> Sounds like that fix is not yet on the horizon. 
>>> 
>>> Would explicit bug reports be helpful?
>> 
>> I’m reading here for coincidence at the moment and can’t believe that the issue isn’t fixed….
>> Write hundreds of bug-reports(although we know RPI4 isn’t supported and it’s 13-curr),
>> I’m Sorry for not working myself on that issues the last days/week(1000 other things to do),
>> But that’s the absolute joke of the century :-) that these issues last so long here on the mailing list 
>> And there’s no fix/response …
> 
> Resource constrained by other priorities is not surprising in my view.
> 
>> Mark Millard , if you have a patch, (if you want) please describe it in 1 or 2 sentences and I’ll upload your patch the Wiki(if you don’t have access there and can’t edit yourself)…
> 
> https://lists.freebsd.org/pipermail/freebsd-arm/2020-February/021258.html
> had the sysutils/u-boot-rpi4 based workaround (as seen in its build tree):
> 
> # diff ./board/raspberrypi/rpi/rpi.c.orig ./board/raspberrypi/rpi/rpi.c
> 485c485
> < 	efi_add_memory_map(0, 1, EFI_RESERVED_MEMORY_TYPE, 0);
> ---
>> 	efi_add_memory_map(0, 2, EFI_RESERVED_MEMORY_TYPE, 0);
> 
> It just changes EFI interfacing to indicate the first 2 pages as
> reserved instead of indicating just 1 page as reserved.
> 
> I did not convert it to a form appropriate for
> /usr/ports/sysutils/u-boot-rpi4/files/ . I simply changed
> the source after the fetch patch sequence but before
> building and later showed the diff. Better form for
> adapting to a normal files/* patch would be (up to whitespace
> details possibly not being fully preserved):
> 
> # cd /wrkdirs/usr/ports/sysutils/u-boot-rpi4/work/u-boot-2019.10/
> # diff -U3 board/raspberrypi/rpi/rpi.c.orig board/raspberrypi/rpi/rpi.c
> --- board/raspberrypi/rpi/rpi.c.orig	2020-02-13 11:12:33.057911000 -0800
> +++ board/raspberrypi/rpi/rpi.c	2020-02-13 16:09:15.381158000 -0800
> @@ -482,7 +482,7 @@
> 
> #ifdef CONFIG_EFI_LOADER
> 	/* Reserve the spin table */
> -	efi_add_memory_map(0, 1, EFI_RESERVED_MEMORY_TYPE, 0);
> +	efi_add_memory_map(0, 2, EFI_RESERVED_MEMORY_TYPE, 0);
> #endif
> 
> 	return 0;
> 
> 
> (The /wrkdirs style prefix is something I cause in my environments
> in order to match poudriere paths when it makes tar files that I
> sometimes expand. So that need not be duplicated/used.)
> 
> I have not looked at sysutils/u-boot-rpi3 . I'd expect something
> similar for it.
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>