Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Feb 2020 22:18:52 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com>
Cc:        bob prohaska <fbsd@www.zefox.net>, freebsd-arm@freebsd.org
Subject:   Re: Showstoppers for RPI3
Message-ID:  <8BDC8A26-FFE6-4AE0-8EB6-643840940CC0@yahoo.com>
In-Reply-To: <E866B6BE-7948-4412-82EF-999A2F8C0DF9@googlemail.com>
References:  <20200225175446.GA77976@www.zefox.net> <11951E01-EC13-4FBB-938A-AEB5700C4281@yahoo.com> <CACNAnaEiv5NZZz%2BxfETkhSZ-zbjZ3Ya6z7pyteheP4zj3EK1Gg@mail.gmail.com> <20200226052045.GA79939@www.zefox.net> <E866B6BE-7948-4412-82EF-999A2F8C0DF9@googlemail.com>

index | next in thread | previous in thread | raw e-mail



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)



home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8BDC8A26-FFE6-4AE0-8EB6-643840940CC0>