New: devmem2 w (word) is 8 bytes in x86 64 systems

https://bugs.busybox.net/show_bug.cgi?id=10171

Bug ID: 10171
Summary: devmem2 w (word) is 8 bytes in x86 64 systems
Product: buildroot
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: ciro.santilli at gmail.com
CC: buildroot at uclibc.org
Target Milestone: ---

http://free-electrons.com/pub/mirror/devmem2.c

w maps to unsigned long

Let's use uintX_t for all accesses, and introduce q (quadword) for 64 bit

Specially unintuitive since h (half-word) maps to short int, which in x86_64 is 2 bytes, and thus not half of word.

Also can we move the .c source into the buildroot tree itself in the same directory as the .mk, since it is so tiny. Or create a separate official git repo for it.

I'll send patch if you agree.

Like this:
https://github.com/cirosantilli/linux-kernel-module-cheat/blob/d871c008fbf0832e502f8ae1367ecf8ab6796aa5/kernel_module/user/devmem3.c

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=10171

--- Comment #1 from Matt Weber <[email protected]> --- FYI, the busybox version of devmem is the most up to date and supports quadword access. This app I believe is just for backwards compatibility and there are other address casting address issues with 32bit access on a 64bit bus (like on the SoC FPGA ARM processors) with this tool. Maybe a note should be added to the package to reflect it's in a partially depreciated state? Or we should remove it and make it a virtual package setting the busybox option to enabled?

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=10171

--- Comment #2 from Ciro Santilli <[email protected]> --- Thanks! I didn't know busybox had devmem2. And that one use uintX_t types already.

The devmem2 package should be deprecated if possible.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=10171

Carlos Santos <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |ASSIGNED
           Assignee|unassigned at buildroot.uclibc |unixmania at gmail.com
                   |.org                        |

--- Comment #3 from Carlos Santos <[email protected]> --- I'm taking this one.

This bug has been frozen for two years. I think we could simply replace devmem2 by a shell script that invokes the busybox devmem utility, mapping the 'type' argument to the corresponding 'width' one, keeping backward compatibility:

b -> 8
h -> 16
w -> 32

Do you agree?

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=10171

--- Comment #4 from Ciro Santilli <[email protected]> --- busybox 1.17.2 has:

Usage: devmem ADDRESS [WIDTH [VALUE]]

Read/write from physical address

ADDRESS Address to act upon
WIDTH Width (8/16/...)
VALUE Data to be written

I forgot the original motivation, but I think this covers it?

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=10171

--- Comment #5 from Carlos Santos <[email protected]> --- (In reply to Ciro Santilli from comment #4)

I found that ti-gfx contains a script using devmem2 and submitted a patch to remove the dependency: https://patchwork.ozlabs.org/patch/1145451/

There are still 8 board configurations that select devmem2, for reasons that I don't know:

- at91sam9x5ek_dev_defconfig
- at91sam9x5ek_mmc_dev_defconfig
- atmel_sama5d27_som1_ek_mmc_dev_defconfig
- atmel_sama5d2_xplained_mmc_dev_defconfig
- atmel_sama5d3_xplained_dev_defconfig
- atmel_sama5d3_xplained_mmc_dev_defconfig
- atmel_sama5d4_xplained_dev_defconfig
- atmel_sama5d4_xplained_mmc_dev_defconfig

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=10171

--- Comment #6 from Thomas Petazzoni <[email protected]> --- Thanks Carlos for taking care of the issue. It certainly makes sense to use the devmem applet from Busybox, when Busybox is enabled.

However, I'm wondering if it makes sense to keep a standalone version of this program. Most (all?) applets provided by Busybox also have a counterpart "full-blown" version, which can be useful in situations where Busybox is not used.

Overall, it feels like this bug is not really a Buildroot bug: it's an upstream devmem2 bug, which should be reported to upstream and not to Buildroot.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=10171

--- Comment #7 from Carlos Santos <[email protected]> --- (In reply to Thomas Petazzoni from comment #6)

Considering that devmem2 is abandoneware and that after commits 2f6e3eae55 and 559856480b6 it is not used by any package or board in Buildroot I think we can either leave it as is or simply drop the package. It can be resurrected later, if necessary.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=10171

Thomas Petazzoni <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #8 from Thomas Petazzoni <[email protected]> --- Fixed by
https://git.buildroot.org/buildroot/commit/?id=2b2579afebfc7a9b8a458af1f2d206101fbfa19c.

You are receiving this mail because:
You are on the CC list for the bug.