On 29/7/19 4:35 pm, Sebastian Huber wrote: > On 29/07/2019 08:24, Chris Johns wrote: >> On 29/7/19 4:16 pm, Sebastian Huber wrote: >>> On 29/07/2019 08:12, Chris Johns wrote: >>>> On 29/7/19 4:08 pm, Sebastian Huber wrote: >>>>> On 29/07/2019 08:04, Chris Johns wrote: >>>>>>> The new one is probably: >>>>>>> >>>>>>> 0x00200080 >>>>>>> >>>>>>> I am not sure about the 0x80 tail, it should be the same as it was >>>>>>> previously. >>>>>> Better but interrupts? >>>>>> >>>>>> The address 0x00200000 works with hello but ticker prints the "TEST >>>>>> VERSION" >>>>>> banner and then nothing more. >>>>> Then the vector table needs to be probably at 0x0. Not really a great >>>>> position >>>>> if you have a NULL pointer access. >>>>> >>>> Agreed. >>>> >>>> Can you set the vector base on this ARM? If you can is that missing from >>>> this >>>> BSP? >>> You can try this (v2 of the patch moves the vector base to 0, but it would >>> be >>> better to have a NULL pointer protection): >> This works (and v2 also works). > > Ok, you can decide. Do you want a better NULL pointer protection at the > expense > of some memory and an mkimage change?
Better protection is valuable. We need a mkimage change with both patches as the original value was 0x00008000 so it seems either way there is a small amount of user churn and pain. I have added mkimage support to the `rtems-boot-image` tool ... $ rtems-boot-image --board u-boot-beagleboneblack --convert-kernel hello.exe If I add u-boot-raspberrypi2 we can ask users to switch to that tool so the impact is limited to just one change. After that the tool can track the kernel's memory map. What if you post a v3 patch which is v1 + the vector base change and we can decide tomorrow? I will post something to users to see if there is any issue with the change. Thank you for doing this. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
