)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"49fbfde3c3509cbd9448fb40e49669f4fe6488f0","unresolved":true,"context_lines":[{"line_number":18,"context_line":"available falled back /dev/mem."},{"line_number":19,"context_line":"The pads were configured at a wrong memory address if gpiomem was mapped."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"For the limited time until /dev/mem access is completely dropped"},{"line_number":22,"context_line":"use \u0027bcm2835gpio peripheral_base\u0027 parameter to choose the memory"},{"line_number":23,"context_line":"access device."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Without peripheral_base (or peripheral_base 0) use /dev/gpiomem"},{"line_number":26,"context_line":"If a non-zero peripheral_base is configured, use /dev/mem"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"89686414_8fe64a48","line":23,"range":{"start_line":21,"start_character":0,"end_line":23,"end_character":14},"updated":"2023-01-24 10:23:06.000000000","message":"Antonio,\n\nif we switch to keeping /dev/mem available then I would prefer adding a specific config parameter for it instead of (ab)using side effect of \u0027bcm2835gpio peripheral_base\u0027.\n\nWould you agree with adding\n bcm2835gpio use_dev_mem [true|false]\n\n? Or alternatively get the device path - but we have to parse it anyway to find out if pads are accessible. Isn\u0027t a configurable dev path worse from the security point of view?\n\nIn both cases it would allow the bcm2835gpio config to configure peripheral base from DT parsing and let the user independently decide whether to use /dev/mem or gpiomem","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"9371e356ec6cae3a3be72dda246f116ccabaf406","unresolved":true,"context_lines":[{"line_number":18,"context_line":"available falled back /dev/mem."},{"line_number":19,"context_line":"The pads were configured at a wrong memory address if gpiomem was mapped."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"For the limited time until /dev/mem access is completely dropped"},{"line_number":22,"context_line":"use \u0027bcm2835gpio peripheral_base\u0027 parameter to choose the memory"},{"line_number":23,"context_line":"access device."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Without peripheral_base (or peripheral_base 0) use /dev/gpiomem"},{"line_number":26,"context_line":"If a non-zero peripheral_base is configured, use /dev/mem"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"d66b4b32_21cea317","line":23,"range":{"start_line":21,"start_character":0,"end_line":23,"end_character":14},"in_reply_to":"89686414_8fe64a48","updated":"2023-01-26 23:18:36.000000000","message":"I think it would be more user friendly to\n1) try /dev/gpiomem\nif it fails then\n2) LOG_WARNING(\"/dev/gpiomem not present, fallback to /dev/mem at offset 0x%x\", offset);\n3) try /dev/mem (it could fail too for permission settings or not present)\n\nIn the odd case a user want to force using /dev/mem (for test purpose?) he can change permission to /dev/gpiomem\n\nRegarding compatible, the rules in upstream kernel are strict about changing DT. Your Linux box must run flawless if you use an old DT (e.g. embedded in the bootloader) with a new kernel+distro.\nI don\u0027t know if RPi did something odd with its systems and compatible strings before all get upstream, but such change of compatible should not be present.\n\nI think that using the single config file with the switch on compatible string should be ok.\n\nI don\u0027t understand the need to look for \"/proc/device-tree/soc/ranges\"\nWe could rely on the folder name /proc/device-tree/soc/gpio@*, where the hex after gpio@ is the base address of the gpios.\nYou can even read the same value in big-endian binary inside /proc/device-tree/soc/gpio@*/reg but you need the name to read the same value (chicken and egg).\n\nThe other drivers:\n- ep93xx, am335xgpio and at91rm9200 have base address hardcoded;\n- imx_gpio has a default value, plus command \"imx_gpio_peripheral_base\".\n\nIt could be ok to get a default from the compatible or from /proc/device-tree/soc/gpio@* and adding a command to override it.","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"83411fe40cd7cc098c185a0df24203889da8b148","unresolved":false,"context_lines":[{"line_number":18,"context_line":"available falled back /dev/mem."},{"line_number":19,"context_line":"The pads were configured at a wrong memory address if gpiomem was mapped."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"For the limited time until /dev/mem access is completely dropped"},{"line_number":22,"context_line":"use \u0027bcm2835gpio peripheral_base\u0027 parameter to choose the memory"},{"line_number":23,"context_line":"access device."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Without peripheral_base (or peripheral_base 0) use /dev/gpiomem"},{"line_number":26,"context_line":"If a non-zero peripheral_base is configured, use /dev/mem"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"79ee2534_22b30660","line":23,"range":{"start_line":21,"start_character":0,"end_line":23,"end_character":14},"in_reply_to":"cfe9a3f9_9eb57a02","updated":"2023-05-13 20:29:24.000000000","message":"Done","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"2cfce2b53cd4d7dd18068564681ae22dfad89620","unresolved":true,"context_lines":[{"line_number":18,"context_line":"available falled back /dev/mem."},{"line_number":19,"context_line":"The pads were configured at a wrong memory address if gpiomem was mapped."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"For the limited time until /dev/mem access is completely dropped"},{"line_number":22,"context_line":"use \u0027bcm2835gpio peripheral_base\u0027 parameter to choose the memory"},{"line_number":23,"context_line":"access device."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Without peripheral_base (or peripheral_base 0) use /dev/gpiomem"},{"line_number":26,"context_line":"If a non-zero peripheral_base is configured, use /dev/mem"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"d8b92a36_96a52546","line":23,"range":{"start_line":21,"start_character":0,"end_line":23,"end_character":14},"in_reply_to":"d66b4b32_21cea317","updated":"2023-01-27 17:37:54.000000000","message":"The driver already checks for /dev/gpiomem and then /dev/mem.\nAlready has command \u0027peripheral_base\u0027 to pass the base address.\nGood.\nThe default base address is 0x20000000 (+ 0x00200000 for GPIO, +0x00100000 for pad strength).\n\nI downloaded the kernel from https://github.com/raspberrypi/linux.git\nThe driver gpiomem ignores the address passed to mmap() and uses the default in the devicetree (is this the reason it works in OpenOCD while /dev/mem seams not working?).\nThen I analyzed devicetree specific for RPi in branch rpi-5.15.y and found two groups:\n\narch/arm/boot/dts/bcm2708-rpi-b.dts\narch/arm/boot/dts/bcm2708-rpi-b-plus.dts\narch/arm/boot/dts/bcm2708-rpi-b-rev1.dts\narch/arm/boot/dts/bcm2708-rpi-cm.dts\narch/arm/boot/dts/bcm2708-rpi-zero.dts\narch/arm/boot/dts/bcm2708-rpi-zero-w.dts\narch/arm/boot/dts/bcm2709-rpi-2-b.dts\narch/arm/boot/dts/bcm2709-rpi-cm2.dts\narch/arm/boot/dts/bcm2710-rpi-2-b.dts\narch/arm/boot/dts/bcm2710-rpi-3-b.dts\narch/arm/boot/dts/bcm2710-rpi-3-b-plus.dts\narch/arm/boot/dts/bcm2710-rpi-cm3.dts\narch/arm/boot/dts/bcm2710-rpi-zero-2.dts\narch/arm/boot/dts/bcm2710-rpi-zero-2-w.dts\narch/arm/boot/dts/bcm2711-rpi-400.dts\narch/arm/boot/dts/bcm2711-rpi-4-b.dts\narch/arm/boot/dts/bcm2711-rpi-cm4.dts\narch/arm/boot/dts/bcm2711-rpi-cm4s.dts\n- all have gpiomem with reg \u003d \u003c0x7e200000 0x1000\u003e;\n- all have gpio: gpio@7e200000  with reg \u003d \u003c0x7e200000 0xb4\u003e;\n\narch/arm/boot/dts/bcm2835-rpi-a.dts\narch/arm/boot/dts/bcm2835-rpi-a-plus.dts\narch/arm/boot/dts/bcm2835-rpi-b.dts\narch/arm/boot/dts/bcm2835-rpi-b-plus.dts\narch/arm/boot/dts/bcm2835-rpi-b-rev2.dts\narch/arm/boot/dts/bcm2835-rpi-cm1-io1.dts\narch/arm/boot/dts/bcm2835-rpi-zero.dts\narch/arm/boot/dts/bcm2835-rpi-zero-w.dts\narch/arm/boot/dts/bcm2836-rpi-2-b.dts\narch/arm/boot/dts/bcm2837-rpi-3-a-plus.dts\narch/arm/boot/dts/bcm2837-rpi-3-b.dts\narch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts\narch/arm/boot/dts/bcm2837-rpi-cm3-io3.dts\n- all without gpiomem\n- all have gpio: gpio@7e200000 with reg \u003d \u003c0x7e200000 0xb4\u003e;\n\nSo 13 over 31 must rely on /dev/mem, even if user can add gpiomem in its own DT\n\nThe issue is that all rely on \"ranges\" to remap the address space, with the extra complexity of the size of addresses and size in ranges that can be 32 or 64, depending respectively on the property #address-cells and #size-cells.\nI\u0027ve just pushed https://review.openocd.org/7466 that adds some helpers to get data from the devicetree. I think it can help getting the translation.","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"729bc4c070c49b10343fc9e5820460f6cc9a0a70","unresolved":true,"context_lines":[{"line_number":18,"context_line":"available falled back /dev/mem."},{"line_number":19,"context_line":"The pads were configured at a wrong memory address if gpiomem was mapped."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"For the limited time until /dev/mem access is completely dropped"},{"line_number":22,"context_line":"use \u0027bcm2835gpio peripheral_base\u0027 parameter to choose the memory"},{"line_number":23,"context_line":"access device."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Without peripheral_base (or peripheral_base 0) use /dev/gpiomem"},{"line_number":26,"context_line":"If a non-zero peripheral_base is configured, use /dev/mem"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"e86e1892_f4eb75aa","line":23,"range":{"start_line":21,"start_character":0,"end_line":23,"end_character":14},"in_reply_to":"d8b92a36_96a52546","updated":"2023-03-06 21:16:33.000000000","message":"Antonio, sorry for long delay. I was too busy...\n\n\u003e I think it would be more user friendly to\n\u003e 1) try /dev/gpiomem\n\u003e if it fails then\n\u003e 2) LOG_WARNING(\"/dev/gpiomem not present, fallback to /dev/mem at offset 0x%x\", offset);\n\u003e 3) try /dev/mem (it could fail too for permission settings or not present)\n\nThis what the current code does.\nI don\u0027t like that availability of something external from OpenOCD (/dev/gpiomem) changes the permissions OpenOCD requires to run. That\u0027s why I would prefer mapping device selected by config, not always auto-selected, even if it seems less user friendly.\n\n\u003e Regarding compatible, the rules in upstream kernel are strict about changing DT. \u003e Your Linux box must run flawless if you use an old DT (e.g. embedded in the \n\u003e bootloader) with a new kernel+distro.\n\nIt does not prevent changing DT - it\u0027s sufficient if the new kernel understands both old and new DT. Similarly OpenOCD have to accept both variants (in Rpi case bcm2835/bcm2708 bcm2836/bcm2709 bcm2837/bcm2710 aliases in /proc/device-tree/compatible).\n\n\u003e I downloaded the kernel from https://github.com/raspberrypi/linux.git\n\u003e The driver gpiomem ignores the address passed to mmap() and uses the default in the devicetree (is this the reason it works in OpenOCD while /dev/mem seams not working?).\n\nDon\u0027t understand what you mean \u0027not working\u0027.\ngpio pads don\u0027t work on /dev/gpiomem (because they are out of mapped space\nand the old driver code writes to wrong mem locations).\n/dev/mem works if a correct peripheral base is provided.\n\n\u003e Then I analyzed devicetree specific for RPi in branch rpi-5.15.y and found two groups:\n\u003e \n\u003e arch/arm/boot/dts/bcm2708-rpi-b.dts\n...\n\u003e arch/arm/boot/dts/bcm2711-rpi-cm4s.dts\n\u003e - all have gpiomem with reg \u003d \u003c0x7e200000 0x1000\u003e;\n\u003e - all have gpio: gpio@7e200000  with reg \u003d \u003c0x7e200000 0xb4\u003e;\n\nThese are Rpi/Broadcom stuff.\n\n\u003e arch/arm/boot/dts/bcm2835-rpi-a.dts\n...\n\u003e arch/arm/boot/dts/bcm2837-rpi-cm3-io3.dts\n\u003e - all without gpiomem\n\u003e - all have gpio: gpio@7e200000 with reg \u003d \u003c0x7e200000 0xb4\u003e;\n\nThese are from upstream kernel.\n \n\u003e So 13 over 31 must rely on /dev/mem, even if user can add gpiomem in its own DT\n\nDoesn\u0027t seem important how many dts sources are in Raspberry linux git.\nThe important/mostly used are dtb distributed in the Rpi system image.\nHere is /boot dir of 64-bit Linux rpi 5.15:\n\n bcm2710-rpi-2-b.dtb       bcm2710-rpi-zero-2.dtb    bcm2711-rpi-cm4.dtb\n bcm2710-rpi-3-b.dtb       bcm2710-rpi-zero-2-w.dtb  bcm2711-rpi-cm4s.dtb\n bcm2710-rpi-3-b-plus.dtb  bcm2711-rpi-400.dtb\n bcm2710-rpi-cm3.dtb       bcm2711-rpi-4-b.dtb\n\n(all with gpiomem, no vanilla dt)\n\n\u003e I don\u0027t understand the need to look for \"/proc/device-tree/soc/ranges\"\n\u003e We could rely on the folder name /proc/device-tree/soc/gpio@*, where the hex \n\u003e after gpio@ is the base address of the gpios.\n\nWe cannot use the soc bus address (the child address of \u0027range\u0027 property in DT terminology) for mmap.\nmmap requires the parent address from \u0027range\u0027 mapping - to be precise gpio@* address mapped back from soc bus to the \u0027range\u0027 parent (CPU).\n\n\u003e The issue is that all rely on \"ranges\" to remap the address space, with the extra complexity of the size of addresses and size in ranges that can be 32 or 64, depending respectively on the property #address-cells and #size-cells.\n\nEven worse with https://www.raspberrypi.com/documentation/computers/config_txt.html#arm_peri_high\nPeripheral base is 0x47e000000 then, but soc/ranges has just one cell of\nparent address, so we read 32-bit stripped 0x7e000000. No way how to get\ncorrect peripheral address for mmap from DT without an ugly workaround.\n\n\u003e I\u0027ve just pushed https://review.openocd.org/7466 that adds some helpers to get data from the devicetree. I think it can help getting the translation.\n\nNice. Thanks","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"b0b238522df814de894e934ff79c53ea648a9cb3","unresolved":true,"context_lines":[{"line_number":18,"context_line":"available falled back /dev/mem."},{"line_number":19,"context_line":"The pads were configured at a wrong memory address if gpiomem was mapped."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"For the limited time until /dev/mem access is completely dropped"},{"line_number":22,"context_line":"use \u0027bcm2835gpio peripheral_base\u0027 parameter to choose the memory"},{"line_number":23,"context_line":"access device."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Without peripheral_base (or peripheral_base 0) use /dev/gpiomem"},{"line_number":26,"context_line":"If a non-zero peripheral_base is configured, use /dev/mem"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"cfe9a3f9_9eb57a02","line":23,"range":{"start_line":21,"start_character":0,"end_line":23,"end_character":14},"in_reply_to":"e86e1892_f4eb75aa","updated":"2023-03-06 21:25:27.000000000","message":"Just for completeness the list of dtb in 32-bit Linux Rpi 5.15.76\n $ cd /boot;ls *.dtb\n bcm2708-rpi-b.dtb       bcm2709-rpi-2-b.dtb       bcm2710-rpi-zero-2.dtb\n bcm2708-rpi-b-plus.dtb  bcm2709-rpi-cm2.dtb       bcm2710-rpi-zero-2-w.dtb\n bcm2708-rpi-b-rev1.dtb  bcm2710-rpi-2-b.dtb       bcm2711-rpi-400.dtb\n bcm2708-rpi-cm.dtb      bcm2710-rpi-3-b.dtb       bcm2711-rpi-4-b.dtb\n bcm2708-rpi-zero.dtb    bcm2710-rpi-3-b-plus.dtb  bcm2711-rpi-cm4.dtb\n bcm2708-rpi-zero-w.dtb  bcm2710-rpi-cm3.dtb       bcm2711-rpi-cm4s.dtb\n\nAll with gpiomem again.","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"2724e0140e092bb8c152b2f3a35ebda8ccac12ba","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4886f5b1_f1da7b4d","updated":"2022-11-15 15:58:20.000000000","message":"TODO:","commit_id":"3b4c81c6c3f9f7ab41d1bada998884a49d988c2d"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"3216b4307698dd2f8b5ca69144d5fa39fd6448dc","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"37aa5217_4def148c","updated":"2023-01-21 10:42:48.000000000","message":"/dev/gpiomem is not in upstream Linux.\nI agree that /dev/mem is a security risk, but what about using RPi with a vanilla kernel?\nI would not mark /dev/mem as deprecated, but I would check if there is /dev/gpiomem and issue a warning msg to the user to prefer the latter due to security concerns","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1002041,"name":"Jonathan Bell","email":"jonathan@raspberrypi.com","username":"jonathan.bell"},"change_message_id":"072887b75eae1fe7f2ed77d2630245a53093a3f7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"7619d33b_7e765caf","updated":"2022-11-16 12:09:17.000000000","message":"ACK for the code, but does this change mean that documented behaviour of the config command in Chapter 8 needs to be updated (as in when not specified, gpiomem is used)?","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"b4cce205c9831d56c0d0c24d9177de37e9ee118d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"8430b23c_9b285e3c","updated":"2023-03-31 07:24:43.000000000","message":"Antonio, Jonathan, no more comments on this?\n\nI repeat that IMO the auto-fallback to /dev/mem is potentially dangerous, because an average user would not be able to distinguish when OpenOCD needs the root privileges and he will \u0027sudo openocd\u0027 always just because it used to be necessary with an old or vanilla kernel.\n\nWe need to find agreement whether /dev/mem usage is marginal (I assume so) or relatively common (Antonio thinks so). If it\u0027s used just marginally by some core geeks, then I see no problem in forcing them to add some config commands to OpenOCD command line or user config. On the other hand if used more frequently I would prefer a dedicated config file for /dev/mem, e.g. raspberrypi-native-rooted.cfg to make clear when we should use \u0027sudo openocd\u0027","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"2cfce2b53cd4d7dd18068564681ae22dfad89620","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"5420e0b4_7e3fa1d1","updated":"2023-01-27 17:37:54.000000000","message":"I have run","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1001975,"name":"Steve Marple","email":"stevemarple@googlemail.com","username":"stevemarple"},"change_message_id":"e0f261a504b65b89716386842e2a4e094792add3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"12e15f68_f0858966","updated":"2023-05-09 20:10:28.000000000","message":"I made some comments about Linux CAP_SYS_RAWIO capabilities versus sudo/setuid and programming speed.","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"49fbfde3c3509cbd9448fb40e49669f4fe6488f0","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"0eee35d0_a93c0dbd","in_reply_to":"01774e07_a685e254","updated":"2023-01-24 10:23:06.000000000","message":"\u003e \u003e There is another problem in the case of a vanilla kernel: one has to configure the peripheral_base manually or we need at least 4 config files, one per each RPi version. With a vanilla kernel we cannot rely on kernel device tree for finding peripheral_base...\n\u003e \n\u003e Vanilla kernel uses the same compatible strings you parse in \n\u003e https://review.openocd.org/c/openocd/+/7264/3/tcl/interface/raspberrypi-native.cfg#50\n\u003e Probably the same if/then/else could be used to assign the base address, with option for user to override it.\n\nIt\u0027s true. I just didn\u0027t check vanilla kernels for such unwanted surprises like changing the compatible chip name in the raspberry kernel (former bcm2708 became bcm2835 and so on)\n\nAnother problem is that 64-bit kernel of RPi 4 has the peripheral_base dependent on kernel parameter arm_peri_high\u003d1 - so we have to extract at least the address from /proc/device-tree/soc/ranges but the parent address is just 32 bit! It seems me wrong (does not comply #address-cells \u003d \u003c2\u003e of bcm2711) and extracting the address compatible with arm_peri_high\u003d1 would need an ugly workaround. That\u0027s why I\u0027d like to avoid fiddling with DT.\n\n\u003e We could even parse the whole device-tree to look for the gpio node, but would be more complex and I have no such platforms to propose anything more.\n\nYes. The gpio address is fortunately stable as all RPi chips are compatible with bcm2835 but the mapping differs.","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"83411fe40cd7cc098c185a0df24203889da8b148","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"fe760b22_aaae8010","in_reply_to":"0eee35d0_a93c0dbd","updated":"2023-05-13 20:29:24.000000000","message":"Done","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1002041,"name":"Jonathan Bell","email":"jonathan@raspberrypi.com","username":"jonathan.bell"},"change_message_id":"89bdf6631595d3bdaaa28a854bd895b381895ad4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"79f34e94_924ec1a1","in_reply_to":"2052e598_d0391694","updated":"2022-11-16 14:36:09.000000000","message":"Oops - missed that you did that as well. The doc update is fine.","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"55cee28aad40f82c9baa63d2af4841de01f2396f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"01774e07_a685e254","in_reply_to":"2c2ef282_3666db4c","updated":"2023-01-21 15:57:49.000000000","message":"\u003e I would recommend to use (slower) linuxgpiod or sysfsgpio instead of exposing the rooted OpenOCD on the local net.\n\nThat is another option, but we already use /dev/mem for other drivers (ep93xx, imx_gpio, am335xgpio, at91rm9200) and more I expect will arrive. I\u0027m not considering /dev/mem dead, yet.\nThere have been discussion about making libgpiod more efficient but, as far as I know, nothing at the horizon yet.\n\n\u003e There is another problem in the case of a vanilla kernel: one has to configure the peripheral_base manually or we need at least 4 config files, one per each RPi version. With a vanilla kernel we cannot rely on kernel device tree for finding peripheral_base...\n\nVanilla kernel uses the same compatible strings you parse in \nhttps://review.openocd.org/c/openocd/+/7264/3/tcl/interface/raspberrypi-native.cfg#50\nProbably the same if/then/else could be used to assign the base address, with option for user to override it.\nWe could even parse the whole device-tree to look for the gpio node, but would be more complex and I have no such platforms to propose anything more.\n\n\u003e If you insist on keeping /dev/mem available I can replace \u0027deprecated\u0027 warnings by \u0027security risk\u0027 messages.\n\nYes, that would be definitively fine","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"68a99881851397fcc2305b53747efa4de5c0502f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"2c2ef282_3666db4c","in_reply_to":"37aa5217_4def148c","updated":"2023-01-21 12:06:45.000000000","message":"You\u0027re right that a vanilla kernel doesn\u0027t have /dev/gpiomem\nI would recommend to use (slower) linuxgpiod or sysfsgpio instead of exposing the rooted OpenOCD on the local net.\n\nThere is another problem in the case of a vanilla kernel: one has to configure the peripheral_base manually or we need at least 4 config files, one per each RPi version. With a vanilla kernel we cannot rely on kernel device tree for finding peripheral_base...\n\nIf you insist on keeping /dev/mem available I can replace \u0027deprecated\u0027 warnings by \u0027security risk\u0027 messages.","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"fecc0b01e49bdd14a68372bd48145b8363bef01c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"1c6e479c_c646a02f","in_reply_to":"3f453978_a808bb0e","updated":"2023-05-13 08:57:50.000000000","message":"Fair enough.\nI split the change so PS 3 contains just the switch from /dev/mem auto-fallback to the config command selecting mem map file.\n\nI will submit TCL code for DT address translation soon, WIP for the moment.","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"862b7802c632574869c06ce71584c09aa440ee68","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"3f453978_a808bb0e","in_reply_to":"577fa8c1_9417922e","updated":"2023-05-12 13:10:26.000000000","message":"/dev/mem is a security issue. The only safe way it to disable it at kernel build.\nSaid that, I still see accessing /dev/mem as a good point.\nIf you think parsing the DT is too complicated, what about:\n1. in this series make driver to use default file\u003d/dev/gpiomem, offset\u003d0, but has commands to overrides them (e.g. file\u003d/dev/mem, offset\u003dA_VALUE_FROM_TCL)\n2. in this series make config file that only uses default (so gpiomem)\n3. any user (so not in this patch set) can create a simple config where set file/offset and include the one in 2.\n4. someone later on could spend time to implement the DT parser to make the script in 3. more automatic.\n\neventually, one of the existing config files can be reworked as example for 3.","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"09fbbda82318e121fa5d5c8d83dac8be753368ad","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"2052e598_d0391694","in_reply_to":"7619d33b_7e765caf","updated":"2022-11-16 12:44:31.000000000","message":"Have you seen the doc part of this change?\n\nhttps://review.openocd.org/c/openocd/+/7350/1/doc/openocd.texi\n\nOr do you think it\u0027s not sufficient?","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1001975,"name":"Steve Marple","email":"stevemarple@googlemail.com","username":"stevemarple"},"change_message_id":"e0f261a504b65b89716386842e2a4e094792add3","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"e375cf55_4aa15774","in_reply_to":"8430b23c_9b285e3c","updated":"2023-05-09 20:10:28.000000000","message":"Wouldn\u0027t setting CAP_SYS_RAWIO on the OpenOCD binary allow access to /dev/mem without all of the other potential security issues associated with sudo (or setuid root)? I realise there are still issues with /dev/mem but IMHO the benefits of much faster programming speed outweigh the risks. For me the slow speed of linuxgpiod on a single-board computer is not useful but direct access as used by am335xgpio and bcm2835gpio is fast enough for small production runs.","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"8a04fb9e6690076d9594a17f40e0881f5e75a140","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"577fa8c1_9417922e","in_reply_to":"a3c7a5cc_232893d1","updated":"2023-05-12 08:05:46.000000000","message":"Steve,\nthanks for pointing out CAP_SYS_RAWIO. It deserves a detailed doc, the chapter \"4 Running\" should have a subchapter dedicated to the adapter access (udev rules)/ direct access (mm gpio) versus security. Would you like to write it?\n\nI tried\n  sudo setcap cap_sys_rawio\u003dep /path/to/openocd\n\nIt\u0027s not sufficient, openocd has not permission to open /dev/mem\nAdding cap_dac_override solves it, but opens another huge security hole - openocd can open files regardless of the permissions.\n\nIMO the most secure option is adding the user to kmem group, setting\n   sudo chmod g+w /dev/mem (or change it in udev rules to make it permanent)\nand then openocd with cap_sys_rawio works.\n\nIn the old days /dev/mem used to be a huge security hole easily abused to inject a malicious code to the kernel. CONFIG_STRICT_DEVMEM was introduced to mitigate the vulnerability: it claims that only memory mapped io are allowed in /dev/mem.\nBut I\u0027m not sure if it means /dev/mem is secure now. Isn\u0027t possible to write to e.g. DMA control regs and abuse DMA to access any phys memory w/o restrictions?\n\nAnyway if /dev/gpiomem is available I would strongly prefer using it over /dev/mem\n\nSo the question on which Antonio and I did not agree remains:\ndo we need full support for /dev/mem on the RPi which typically offers /dev/gpiomem? IMO RPi without /dev/gpiomem (means with a custom kernel build from vanilla sources, not from the RPi kernel fork) is really marginal phenomenon so a complicated GPIO address detection from device tree looks like an overkill to me.\nBut it could be useful for am335x, imx or other hosts where OpenOCD employs direct GPIO bitbanging as they AFAIK doesn\u0027t have something like /dev/gpiomem","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"a315a99d54e5d6c5f435beb08f3b7b57d3dfbed1","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"a3c7a5cc_232893d1","in_reply_to":"e375cf55_4aa15774","updated":"2023-05-10 08:42:23.000000000","message":"I don\u0027t see a big problem in the fallback to /dev/mem, \"but\" there should be an alert if /dev/mem is not accessible (permission). Then the manual should report the available options on how to gain permission, e.g.:\n- sudo openocd ...\n- sudo chown user /dev/mem\n- sudo setcap CAP_SYS_RAWIO /path/to/openocd\n\nBut if you insist in separating the two use cases, than I think that from user point of view it could be better having 2 config scripts, e.g.:\n- raspberrypi-native.cfg (that uses /dev/gpiomem)\n- raspberrypi-native-dev-mem.cfg (that uses /dev/mem)\nThe driver should be the same, accepting \"file\" and \"offset\".\nFor the first, file\u003d/dev/gpiomem and offset\u003d0 (or have these as defaults).\nFor the second, file\u003d/dev/mem and offset is computed in TCL by parsing the DT with something like the helpers in\nhttps://review.openocd.org/7466","commit_id":"9f8418ec20d715c1f9fd3760759d66982edd9bd0"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"d467762f39598946854434753a6f309f0517f5f3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"960884de_13d0c73f","updated":"2023-05-13 12:25:35.000000000","message":"I wrote\n\u003e Even worse with https://www.raspberrypi.com/documentation/computers /config_txt.html#arm_peri_high\n\u003e Peripheral base is 0x47e000000 then, but soc/ranges has just one cell of\n\u003e parent address, so we read 32-bit stripped 0x7e000000. No way how to get\n\u003e correct peripheral address for mmap from DT without an ugly workaround.\n\nFortunately it turns out that it was just my misunderstanding - when 2 addr cells are used, they go in big-endian order. Translation works fine even with arm_peri_high\u003d1","commit_id":"34994fd1a0c2c7f56108fc48918b86fe83d8e161"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"19bea7edf2dd344af1695cbb6a3164da168fed1b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"e6ae01a8_227bb10b","updated":"2023-05-13 16:51:19.000000000","message":"thanks!","commit_id":"34994fd1a0c2c7f56108fc48918b86fe83d8e161"}],"src/jtag/drivers/bcm2835gpio.c":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"2724e0140e092bb8c152b2f3a35ebda8ccac12ba","unresolved":true,"context_lines":[{"line_number":322,"context_line":"\t\t.name \u003d \"peripheral_base\","},{"line_number":323,"context_line":"\t\t.handler \u003d \u0026bcm2835gpio_handle_peripheral_base,"},{"line_number":324,"context_line":"\t\t.mode \u003d COMMAND_CONFIG,"},{"line_number":325,"context_line":"\t\t.help \u003d \"peripheral base to access GPIOs (RPi1 0x20000000, RPi2 0x3F000000).\","},{"line_number":326,"context_line":"\t\t.usage \u003d \"[base]\","},{"line_number":327,"context_line":"\t},"},{"line_number":328,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":1,"id":"95a7a31b_2207174f","line":325,"range":{"start_line":325,"start_character":11,"end_line":325,"end_character":78},"updated":"2022-11-15 15:58:20.000000000","message":"Update!","commit_id":"3b4c81c6c3f9f7ab41d1bada998884a49d988c2d"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"83411fe40cd7cc098c185a0df24203889da8b148","unresolved":false,"context_lines":[{"line_number":322,"context_line":"\t\t.name \u003d \"peripheral_base\","},{"line_number":323,"context_line":"\t\t.handler \u003d \u0026bcm2835gpio_handle_peripheral_base,"},{"line_number":324,"context_line":"\t\t.mode \u003d COMMAND_CONFIG,"},{"line_number":325,"context_line":"\t\t.help \u003d \"peripheral base to access GPIOs (RPi1 0x20000000, RPi2 0x3F000000).\","},{"line_number":326,"context_line":"\t\t.usage \u003d \"[base]\","},{"line_number":327,"context_line":"\t},"},{"line_number":328,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":1,"id":"69cfaa56_ea758057","line":325,"range":{"start_line":325,"start_character":11,"end_line":325,"end_character":78},"in_reply_to":"95a7a31b_2207174f","updated":"2023-05-13 20:29:24.000000000","message":"Done","commit_id":"3b4c81c6c3f9f7ab41d1bada998884a49d988c2d"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"19bea7edf2dd344af1695cbb6a3164da168fed1b","unresolved":false,"context_lines":[{"line_number":62,"context_line":"{"},{"line_number":63,"context_line":"\tif (bcm2835_peri_mem_dev)"},{"line_number":64,"context_line":"\t\treturn bcm2835_peri_mem_dev;"},{"line_number":65,"context_line":"\telse"},{"line_number":66,"context_line":"\t\treturn \"/dev/gpiomem\";"},{"line_number":67,"context_line":"}"},{"line_number":68,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":3,"id":"379fde93_0cdca377","line":65,"updated":"2023-05-13 16:51:19.000000000","message":"I don\u0027t remember anymore which static analyzer or compiler used to complain about \"else not required after return\".\nAnyway we have several such cases in OpenOCD, let\u0027s keep this too!","commit_id":"34994fd1a0c2c7f56108fc48918b86fe83d8e161"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"83411fe40cd7cc098c185a0df24203889da8b148","unresolved":false,"context_lines":[{"line_number":62,"context_line":"{"},{"line_number":63,"context_line":"\tif (bcm2835_peri_mem_dev)"},{"line_number":64,"context_line":"\t\treturn bcm2835_peri_mem_dev;"},{"line_number":65,"context_line":"\telse"},{"line_number":66,"context_line":"\t\treturn \"/dev/gpiomem\";"},{"line_number":67,"context_line":"}"},{"line_number":68,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":3,"id":"2641b373_4486c163","line":65,"in_reply_to":"379fde93_0cdca377","updated":"2023-05-13 20:29:24.000000000","message":"No problem to fix. The code looked better before...","commit_id":"34994fd1a0c2c7f56108fc48918b86fe83d8e161"}]}