raspberry pi: Problems with the dynamic work area

[Christian Mauderer]

Hello,

I noted a failure in my thoughts. The extra sections are no problem.
They would be in a different memory region.

I simplified the detection the memory and adopted the method used in the
imx BSP. I'll send a patch set to the list for review.

Best regards

Christian

On 22/12/2019 17:27, Christian Mauderer wrote:
> Hello,
> 
> the patch
> 
> 
> https://git.rtems.org/rtems/commit/?id=a4d7e4cee77d16b0e34ef543f0804e7eb2954137
> 
> introduced some problems. It tries to adapt the work area based on the
> size of the available memory. In theory this is a good idea but the
> implementation doesn't work. The line
> 
>       uint32_t mem = (spec.spec >> (4 + 4 + 8 + 4)) & 0xf;
> 
> always returns something > 8 on raspberries newer than the first pi 1
> boards. The highest bit in this field indicates that it is a new style
> revision code. See
> https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
> 
> So currently for all except for very old boards the code is skipped. On
> old boards (like my pi 1) it will be executed. But the memory sizes in
> the rpi_mem array are missing a few factors 1024 and therefore the
> calculated address is entirely wrong and leads to an exception.
> 
> I tried to fix it (see attached patch) but I run into multiple new problems:
> 
> - The MMU is configured based on the values from the linker command
> file. Therefore if the work area is set to something bigger, an access
> violation happens.
> 
> - In the linker command file there is a stack, a nocache section and a
> nocacheheap after the work section. Also all three are currently zero,
> it seems dangerous to ignore them in case they are non-zero in the future.
> 
> I could think of multiple possible solutions:
> 
> 1. Revert that patch entirely (and maybe some code it replaced) and just
> live with 256MB on the Pi.
> 
> 2. Basically 1 but make the size configurable with for example different
> linker scripts.
> 
> 3. Take a really detailed look at the problem and fix all problems
> listed above.
> 
> I started with three but I would now favor one or two because the more I
> look into the Pi hardware the less I like the processor and the
> hardware. It's a great platform for running Linux where you don't have
> to do anything. But the hardware and processor are both poorly
> documented and not well supported by debug tools so that it's not really
> a lot of fun to work with it on that level.
> 
> Best regards
> 
> Christian
>