Re^6: Accessing Memory-mapped I/O

Stievieb- thank you for trying the code on your systems.

I am using altera-ltsi 4.1.33 on an armv7l (32-bit) and perl 5.2.22.

I understand that the Perl code isn't doing the same thing as the C-code. My question really is whether there is something with my Perl build (or code) that would prevent me from accessing memory outside the system ram. Other processes can access that ram without an issue.

Comment on Re^6: Accessing Memory-mapped I/O

Replies are listed 'Best First'.
Re^7: Accessing Memory-mapped I/O by jcb (Parson) on Nov 01, 2019 at 22:42 UTC
I am using altera-ltsi 4.1.33 on an armv7l (32-bit) and perl 5.2.22. Is that an error or is your perl even more ancient than the venerable (and now very obsolete) 5.005?	[reply]
Re^8: Accessing Memory-mapped I/O by jdmonk (Initiate) on Nov 04, 2019 at 19:25 UTC
Good catch. That should be 5.22.2.	[reply]
Re^7: Accessing Memory-mapped I/O by Anonymous Monk on Nov 01, 2019 at 12:18 UTC
My last sentence should be: "Other processes can access addresses outside the system ram without an issue."	[reply]
Re^8: Accessing Memory-mapped I/O by Corion (Patriarch) on Nov 01, 2019 at 15:07 UTC
You will have to find out whether `/dev/mem` supports what you want, and whether the seek call accepts offsets larger than 2GB on your system. If either of these fails, you will have to find a different approach than reading from `/dev/mem`, like using one of the mmap calls. If the `seek` function takes and understands a 64bit value, you will have to look at the output of `perl -V` to find out why it is not using this version of the `seek` call. For example if `-Duselargefiles` is missing in the output, that is a sure sign that your Perl was not build properly for your system.	[reply] [d/l] [select]