A investigative hack that makes (for example) head -r356529 boot and operate normally an RPi4B (finally!): protect all armstub8-gic.bin's loaded content from replacement by the kernel
Ralf Wenk
iz-rpi03 at hs-karlsruhe.de
Thu Feb 13 15:05:46 UTC 2020
On 2020-02-13 at 15:26 +0100 Ralf Wenk wrote:
> On 2020-02-13 at 7:49 -0600 Kyle Evans wrote:
> > On Thu, Feb 13, 2020 at 7:43 AM Ralf Wenk <iz-rpi03 at hs-karlsruhe.de> wrote:
> > >
> > > On 2020-02-12 at 18:00 -0800 Mark Millard wrote via freebsd-arm:
> > > > [...]
> > > >
> > > > # svnlite diff /usr/src/sys/dev/fdt/fdt_common.c
> > > > Index: /usr/src/sys/dev/fdt/fdt_common.c
> > > > ===================================================================
> > > > --- /usr/src/sys/dev/fdt/fdt_common.c (revision 357529)
> > > > +++ /usr/src/sys/dev/fdt/fdt_common.c (working copy)
> > > > @@ -485,7 +485,18 @@
> > > >
> > > > tuples = res_len / tuple_size;
> > > > reservep = (pcell_t *)&reserve;
> > > > +#ifdef __aarch64__
> > > > + //HACK!!!
> > > > + // Reserve the first few pages, for example to
> > > > + // preserve armstub8-gic.bin or armstub.bin
> > > > + // content.
> > > > + mr[0].mr_start= 0;
> > > > + mr[0].mr_size= 2*4096;
> > > > + tuples++;
> > > > + for (i = 1; i < tuples; i++) {
> > > > +#else
> > > > for (i = 0; i < tuples; i++) {
> > > > +#endif
> > > >
> > > > rv = fdt_data_to_res(reservep, addr_cells, size_cells,
> > > > (u_long *)&mr[i].mr_start, (u_long *)&mr[i].mr_size);
> > > > @@ -512,6 +523,11 @@
> > > >
> > > > root = OF_finddevice("/reserved-memory");
> > > > if (root == -1) {
> > > > + // Fail over to checking for and handling memreserve,
> > > > + // such as for a RPi4B.
> > > > + if (0 == fdt_get_reserved_regions(reserved,mreserved))
> > > > + return (0);
> > > > +
> > > > return (ENXIO);
> > > > }
> > > >
> > >
> > > I can confirm that with your patch(es) my RPi3 does not freeze any more
> > > when loading mac_ntpd.ko. The patches are applied against r357853M.
An reboot is working again too.
> > Have you tested the RPi3 with just this second hunk of patch to
> > fallover to memreserve, or is the first hunk definitely required as
> > well?
>
> Good question. I tested both hunks together.
> Will try what happens when just applying the second and report back.
Here it is:
Without the first hunk the system freezes again when loading mac_ntpd.ko.
Also the CPU information during boot for CPUs 1 to 3 looks strange again.
mbox0: mbox response error
bcm2835_cpufreq0: can't set clock rate (id=8)
Release APs...APs not started
CPU 0: ARM Cortex-A53 r0p4 affinity: 0
Instruction Set Attributes 0 = <CRC32>
Instruction Set Attributes 1 = <>
Processor Features 0 = <AdvSIMD,FP,EL3 32,EL2 32,EL1 32,EL0 32>
Processor Features 1 = <>
Memory Model Features 0 = <TGran4,TGran64,SNSMem,BigEnd,16bit ASID,1TB
PA>
Memory Model Features 1 = <8bit VMID>
Memory Model Features 2 = <32bit CCIDX,48bit VA>
Debug Features 0 = <2 CTX BKPTs,4 Watchpoints,6
Breakpoints,PMUv3,Debugv8>
Debug Features 1 = <>
Auxiliary Features 0 = <>
Auxiliary Features 1 = <>
CPU 1: (null) (null) r0p0 affinity: 0
CPU 2: (null) (null) r0p0 affinity: 0
CPU 3: (null) (null) r0p0 affinity: 0
WARNING: WITNESS option enabled, expect reduced performance.
Ralf
More information about the freebsd-arm
mailing list