Bug 10171

Summary: devmem2 w (word) is 8 bytes in x86 64 systems
Product: buildroot Reporter: Ciro Santilli <ciro.santilli>
Component: OtherAssignee: Carlos Santos <unixmania>
Status: RESOLVED FIXED    
Severity: normal CC: buildroot
Priority: P5    
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Host: Target:
Build:

Description Ciro Santilli 2017-08-05 20:20:22 UTC 
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
Comment 1 Matt Weber 2017-08-07 13:53:30 UTC 
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?
Comment 2 Ciro Santilli 2017-08-07 16:00:26 UTC 
Thanks! I didn't know busybox had devmem2. And that one use uintX_t types already.

The devmem2 package should be deprecated if possible.
Comment 3 Carlos Santos 2019-08-11 00:34:07 UTC 
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?
Comment 4 Ciro Santilli 2019-08-11 06:23:36 UTC 
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?
Comment 5 Carlos Santos 2019-08-11 23:16:50 UTC 
(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
Comment 6 Thomas Petazzoni 2019-08-12 20:40:51 UTC 
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.
Comment 7 Carlos Santos 2019-08-12 23:28:42 UTC 
(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.