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 > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel