[PATCH 11 minor addeum] arm/raspberrypi: GPIO - using RTEMS interrupt lock during BSP
Pavel Pisa
pisa at cmp.felk.cvut.cz
Tue Sep 6 19:48:31 UTC 2016
Hello Sebastian,
On Tuesday 06 of September 2016 20:33:08 Sebastian Huber wrote:
> The interrupt locks are simple interrupt disable/enable or spin locks. So,
> they always work.
Allmost, on UP they are simple local IRQ disable.
But on SMP they are spinlock combined with IRQ disable.
But spinlock requires that corresponding memory location is initialized.
It is initialized to 0,0 as ticked lock or combination with some
debug/non-zero information depending on RTEMS_DEBUG, RTEMS_PROFILING etc.
The locks ends in BSS for zero case and I expect that it is source of
my problems.
I have experienced hard lock of RPi BSP on rpi_select_pin_function()
in SMP build when I use it in bsp_start_hook_0(), this is before
bsp_start_copy_sections(). I use that for hacking to enable JTAG
early in boot for BSP debugging
https://github.com/ppisa/rtems/blob/rtems-rpi-devel-160621/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c#L85
I am sure that deadlock has been in rpi_select_pin_function().
Removing JTAG setup helped. I am sure that skipping locks
would help. But you are right that I have not analyzed
where _System_state_Is_up( _System_state_Get() ) global variable
is placed. If it is in BSS then it is only matter of luck
that it does not match system up state when BSS is not
initialized yet.
So value of patch for real BSP use case is questionable.
My use case is corner or even more obscure and can be solved
by setup in u-boot or definition of the function variant without
locking.
Anyway, thanks for review. I expect that you are quite overloaded
after return from vacations but I would be really happy if you
can say your comments/ACK/NACK to the rest or RPi SMP series
in next days.
There is that problem with generic RTL, caches on ARM and
RPi BSP mostly unusable with actual firmaware on 4.11 branch.
I understand, that my proposal of backport of most of related
fixes from master to 4.11 is sensitive question. Again your
income/voting to debate (ideally with Joel, Chris and Gedare)
could help in steering 4.11 branch.
Best wishes,
Pavel
PS: Congratulation to "Rework thread priority management".
This is big/fundamental step forward for RTEMS.
More information about the devel
mailing list