SHA-3: Implementation of Theta function according to FIPS-202 not behaving as expected - hash

I'm implementing SHA-3 following the official FIPS-202 document in Verilog.
My state is represented by a one-dimensional register and I use a macro function to calculate the corresponding state index from the (x,y,z) coordinates in the document:
A[x, y, z] = S [W(5y + x) + z], W = 64 (p. 9)
I'm strictly following the guide on page 11 and came up with this:
// Macros for transforming dimensions
`define sub_1(x) (x == 0 ? 4 : x - 1)
`define add_1(x) (x == 4 ? 0 : x + 1)
`define sub_1_W(x) (x == 0 ? (W - 1) : x - 1)
`define s(x,y,z) ((W * ((5 * y) + x)) + z)
`define s_xz(x,z) ((W * x) + z)
// Wires
wire [0:(1600 - 1)] absorbed_data, after_theta;
wire [0:((5 * 64) - 1)] C, D;
genvar x, z;
for(x = 0; x < 5; x = x + 1) begin
for(z = (W - 1); z >= 0; z = z - 1) begin
// Step 1
assign C[`s_xz(x,z)] = absorbed_data[`s(x,0,z)] ^ absorbed_data[`s(x,1,z)] ^ absorbed_data[`s(x,2,z)] ^ absorbed_data[`s(x,3,z)] ^ absorbed_data[`s(x,4,z)];
// Step 2
assign D[`s_xz(x,z)] = C[`s_xz(`sub_1(x),z)] ^ C[`s_xz(`add_1(x),`sub_1_W(z)];
end
end
genvar x, y, z;
generate
for(x = 0; x < 5; x = x + 1) begin
for(y = 0; y < 5; y = y + 1) begin
for(z = 0; z < W; z = z + 1) begin
// Step 3
assign after_theta[`s(x,y,z)] = absorbed_data[`s(x,y,z)] ^ D[`s_xz(x,z)];
end
end
end
endgenerate
The issue I'm currently facing seems to be in the Theta function. For example for SHA-224 and an empty message should yield the intermediate results and the final output as shown in this document.
Strangely, I get the same absorbed_data (06 00 ... 00 80) but different values for C and D:
C
as is: 06 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 80 | 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00
to be: 00 00 00 00 00 00 00 06 | 00 00 00 00 00 00 00 00 | 80 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00
D
as is: 00 00 00 00 00 00 00 00 | 06 00 00 00 00 00 01 00 | 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 80 | 0c 00 00 00 00 00 00 00
to be: 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 07 | 00 00 00 00 00 00 00 00 | 80 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 0c
Firstly, for C the bit order seems to be different but not on the bit-level but on the byte-level (as 06 stays 06).
Secondly, for D I get 06 00 .. 01 00 whereas the correct result should be 00 .. 00 07. This is never possible for my implementation as, according to FIPS-202, the bit at z can only be shifted by one position ( (z - 1) mod w).
In the to-be case D will yield the correct result because 06 ^ (80 << 1) = 07.
In conclusion, I would say that my implementation behaves as one can expect from the definition in FIPS-202, correct?
Any idea what I'm doing wrong here?
Thanks in advance!

I think I found the solution.
It is described in appendix of FIPS 202 B.1 (starting on page 26). A hint on this topic is given on page 25:
The convention for interpreting hexadecimal strings as bit strings for the inputs and outputs of the SHA-3 examples is different from the convention for other functions on the examples page. The conversion functions between hexadecimal strings and SHA-3 bit strings are specified in Sec. B.1. For byte-aligned messages, the hexadecimal forms of the padding for the SHA-3 functions are described in Sec. B.2.
There is a good explanation on how to circumvent this issue on cryptologie.net.

Related

How should I pass values to openSCAD in command line?

I want to apply a certain modification on a bunch of stl files. So I wrote an openSCAD program and wanted to script from the command line, but it doesn't work and I can't figure out why.
According to the man page, I thought the following command would work but it doesn't (Ah, also I use an appimage version of openSCAD (for in case it would be important):
OpenSCAD-2021.01-x86_64.AppImage -o [OUTPUT FILE NAME] 'myscript.scad' -D filename=[INPUT FILE NAME]
However, it appears, the -D options doesn't do what I expect. So I made a little test script:
echo ("START");
filename1="cube.stl";
echo(filename1=filename1, filename2=filename2);
minkowski() {
import(filename1);
sphere(r=1, $fn=24);
}
translate([30, 0, 0])
minkowski() {
import(filename2);
sphere(r=1, $fn=24);
}
If I test myscript.scad with the gui version of openSCAD, it gives the following result (which is expected):
Compiling design (CSG Tree generation)...
ECHO: "START"
WARNING: Ignoring unknown variable 'filename2' in file test.scad, line 5
ECHO: filename1 = "cube.stl", filename2 = undef
WARNING: Ignoring unknown variable 'filename2' in file test.scad, line 14
Compiling design (CSG Products generation)...
ERROR: Unsupported file format while trying to import file '""', import() at line 14
Geometries in cache: 5
Geometry cache size in bytes: 128056
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Compiling design (CSG Products normalization)...
Normalized tree has 2 elements!
Compile and preview finished.
Total rendering time: 0:00:00.177
However, if I test it in command line, no value is initialized, and by the way, I have no idea what are both those warning on line 19 and 20 while my scad file only has 16 lines:
MyPrompt> ./OpenSCAD-2021.01-x86_64.AppImage -o 'test.stl' 'test.scad' -D filename1=cube.stl -D filename2=cube.stl
WARNING: Ignoring unknown variable 'cube' in file test.scad, line 19
WARNING: Ignoring unknown variable 'cube' in file test.scad, line 20
ECHO: "START"
ECHO: filename1 = undef, filename2 = undef
ERROR: Unsupported file format while trying to import file '""', import() at line 8
Geometries in cache: 4
Geometry cache size in bytes: 118112
CGAL Polyhedrons in cache: 1
CGAL cache size in bytes: 1362752
Total rendering time: 0:00:00.854
Top level object is a 3D object:
Simple: yes
Vertices: 576
Halfedges: 3168
Edges: 1584
Halffacets: 2024
Facets: 1012
Volumes: 3
For reference the cube.stl was made with the cube(); command and contains:
00000000 4f 70 65 6e 53 43 41 44 20 4d 6f 64 65 6c 0a 00 |OpenSCAD Model..|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000050 0c 00 00 00 00 00 00 80 00 00 00 00 00 00 80 3f |...............?|
00000060 00 00 00 00 00 00 80 3f 00 00 80 3f 00 00 80 3f |.......?...?...?|
*
00000080 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 00 00 |...?............|
00000090 80 3f 00 00 80 3f 00 00 00 00 00 00 80 3f 00 00 |.?...?.......?..|
000000a0 00 00 00 00 80 3f 00 00 80 3f 00 00 00 00 00 00 |.....?...?......|
000000b0 00 00 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 |.....?..........|
000000c0 00 00 80 bf 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000d0 00 00 80 3f 00 00 80 3f 00 00 00 00 00 00 80 3f |...?...?.......?|
000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 |................|
000000f0 00 00 00 00 80 bf 00 00 80 3f 00 00 80 3f 00 00 |.........?...?..|
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000110 00 00 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 |.....?..........|
00000120 00 00 80 bf 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000130 00 00 00 00 00 00 80 3f 00 00 00 00 00 00 80 3f |.......?.......?|
00000140 00 00 00 00 00 00 00 00 00 00 80 3f 00 00 00 00 |...........?....|
00000150 00 00 00 00 80 bf 00 00 00 80 00 00 80 3f 00 00 |.............?..|
00000160 00 00 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 |.....?..........|
*
00000180 00 00 80 3f 00 00 00 80 00 00 00 00 00 00 80 3f |...?...........?|
00000190 00 00 00 00 00 00 80 3f 00 00 80 3f 00 00 80 3f |.......?...?...?|
*
000001b0 00 00 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 |.....?..........|
000001c0 80 3f 00 00 80 3f 00 00 00 00 00 00 80 3f 00 00 |.?...?.......?..|
000001d0 00 00 00 00 80 3f 00 00 80 3f 00 00 00 00 00 00 |.....?...?......|
000001e0 00 00 00 00 00 00 00 00 00 00 80 3f 00 00 00 80 |...........?....|
000001f0 00 00 80 3f 00 00 80 3f 00 00 00 00 00 00 00 00 |...?...?........|
00000200 00 00 80 3f 00 00 80 3f 00 00 80 3f 00 00 80 3f |...?...?...?...?|
00000210 00 00 80 3f 00 00 00 00 00 00 00 00 80 3f 00 00 |...?.........?..|
00000220 00 00 00 00 00 00 00 00 80 3f 00 00 80 3f 00 00 |.........?...?..|
00000230 80 3f 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 |.?...?..........|
00000240 80 3f 00 00 00 00 00 00 00 00 80 bf 00 00 00 00 |.?..............|
00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000260 00 00 00 00 00 00 80 3f 00 00 80 3f 00 00 00 00 |.......?...?....|
00000270 00 00 80 3f 00 00 00 00 00 00 00 00 80 bf 00 00 |...?............|
00000280 00 80 00 00 00 00 00 00 00 00 00 00 80 3f 00 00 |.............?..|
00000290 80 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |.?..............|
000002a0 00 00 00 00 00 00 00 00 80 3f 00 00 |.........?..|
Ok, Got it :
The problem comes from the fact that openSCAD wants to receive string with the quotation marks. However, the shell will try to eat them. So, the correct calling syntax will be :
MyPrompt> ./Téléchargements/OpenSCAD-2021.01-x86_64.AppImage -o 'test.stl' 'test.scad' -D filename1='"cube.stl"' -D filename2='"cube.stl"'
ECHO: "START"
ECHO: filename1 = "cube.stl", filename2 = "cube.stl"
Geometries in cache: 4
Geometry cache size in bytes: 136832
CGAL Polyhedrons in cache: 1
CGAL cache size in bytes: 1524416
Total rendering time: 0:00:01.021
Top level object is a 3D object:
Simple: yes
Vertices: 672
Halfedges: 3536
Edges: 1768
Halffacets: 2200
Facets: 1100
Volumes: 3
This also explains the warnings, because it wasn't try to interpret cube.stl as a string, but as a variable name in dot notation (so the main variable name was indeed cube).

Matlab fscanf string read strange behavior

I'm trying to read a file in matlab using fscanf. The file is the dump of a some memory area in a microcontroller. I export it from the IDE and the encoding is 'ISO-8859-1'.
Here's one line from the file as I open it in matlab:
25 08 00 00 7E 05 00 00 08 08 00 00 85 05 00 00 0D 06 00 00 76 06 00 00 04 0C 00 00 FB 07 00 00
3A 06 00 00 0C 06 00 00 01 06 00 00 0C 06 00 00 C3 05 00 00 EF 05 00 00 05 06 00 00 FF 05 00 00
EF 05 00 00 FB 05 00 00 89 08 00 00 74 06 00 00 0D 06 00 00 FC 05 00 00 10 06 00 00 C3 05 00 00
C5 05 00 00 F2 05 00 00 81 05 00 00 1C 06 00 00 85 05 00 00 F0 05 00 00 C2 05 00 00 5F 05 00 00
(here the complete file)
And this is correct: same numbers I see in the IDE.
What I do is:
fileID = fopen('testdataadc.txt','r','n','ISO-8859-1');
% Read all characters excluding white spaces.
vecDump = fscanf(fileID, '%s' ,[25 Inf]);
fclose(fileID);
Where 'n' is for native endiannes: Your system byte ordering (default).
And now the first column in vecDump (which is a 25x64 char variable):
25060000F5080000F8070000F0050000E5050000FC060000EF06000000070000
The format is the one I expected, but values are wrong.
For example:
25 08 00 00 becomes 25 06 00 00
7E 05 00 00 becomes F5 08 00 00
What am I doing wrong here?
The output of fscanf is a 25x64 char matrix. The data from the file fills this matrix column-wise. If you look along the first column, you will see: "250800007E05", etc. Because the file has 64 non-space characters along each row, you should read the file into a 64xN matrix, and then transpose it:
vecDump = fscanf(fileID, '%s', [64,Inf]).'
Now vecDump will look like your file, but without the spaces.

Device::HID read barcode scanner convert binary to Ascii

I try to read barcode form scanner. I had got data from scanner and the format is binary. How do I conert binary to Ascii string?
The barcode type is code 39.
A1234 => [Barcode SCANNRT] => [perl] => binary => ?? A1234 ???
use Device::HID;
use Data::Hexdumper qw(hexdump);
my $dev = Device::HID->new(vendor => 0x04b4, product => 0x0100) or die "No such device !\n";
$dev->timeout = 0.1; # seconds (=100 ms)
my $buf;
my $len=128;
while(defined(my $in = $dev->read_data($buf, $len))){
if ($in == 0) {
next;
}
print hexdump(
data => $buf, # what to dump
suppress_warnings => false,
space_as_space=> true,
);
}
The input "A1234" binary output. How to convert to sting "A1234".
0x0000 : 02 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 1E 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 1F 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 : .. .............
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 21 00 00 00 00 00 00 00 00 00 00 00 00 00 : ..!.............
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 00 : ..(.............
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
I change code to get hexadecimal for each package.
use Device::HID;
use Data::Hexdumper qw(hexdump);
my $dev = Device::HID->new(vendor => 0x04b4, product => 0x0100) or die "No such device !\n";
$dev->timeout = 0.1; # seconds (=100 ms)
my $buf;
my $len=128;
my $i=0;
while(defined(my $in = $dev->read_data($buf, $len))){
if ($in == 0) {
next;
}
$i++;
my $hex = unpack( 'H*', $buf );
print sprintf("%02d",$i)." => $hex\n";
}
The out is hexadecimal. I change code to output hexadecimal. I received 12 package.
How to convert to string 'A1234' ?
01 => 0200040000000000
02 => 0000000000000000
03 => 00001e0000000000
04 => 0000000000000000
05 => 00001f0000000000
06 => 0000000000000000
07 => 0000200000000000
08 => 0000000000000000
09 => 0000210000000000
10 => 0000000000000000
11 => 0000280000000000
12 => 0000000000000000
Split into 8 byte chunks (for your device, it depends on the device descriptor). Column 0 is control key (2nd bit indicates the shift key is pressed), column 2 is the usage code as per section 10 (page 53) of the USB HID Usage Tables doc:
https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
If the key is a 0, then just ignore it.
So this input:
0x0000 : 02 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 1E 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0x0000 : 00 00 1F 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
becomes:
02 04 (shift + a) = "A"
00 00 (ignore)
00 1E (1) = "1"
00 00 (ignore)
00 00 (ignore)
00 00 (ignore)
00 1F (2) = "2"
00 00 (ignore)
...and so on.

What are the three 255's before the image in a monochrome .bmp?

I'm trying to figure out bitmap formatting for a project I'm working on, but there's one thing I don't really get. In this .bmp:
00000000 42 4d aa 00 00 00 00 00 00 00 82 00 00 00 6c 00 |BM............l.|
00000010 00 00 0a 00 00 00 0a 00 00 00 01 00 01 00 00 00 |................|
00000020 00 00 28 00 00 00 13 0b 00 00 13 0b 00 00 02 00 |..(.............|
00000030 00 00 02 00 00 00 42 47 52 73 00 00 00 00 00 00 |......BGRs......|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000060 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 |................|
00000070 00 00 00 00 00 00 00 00 00 00 ff ff ff 00 00 00 |................|
00000080 00 00 ff c0 00 00 ff c0 00 00 ff c0 00 00 ff c0 |................|
*
000000a0 00 00 ff c0 00 00 aa 80 00 00 |..........|
000000aa
what are the three 256's at offset 122 (line 7). I assume they're some sort of color indicators, but I'm not sure.
This is the image I'm using.
The top part of your hex dump is a "BITMAPINFO structure" (https://msdn.microsoft.com/en-us/library/dd183375(v=vs.85).aspx). This is immediately followed by a color index array bmiColors (although its length may be 0, and you should check this in the BITMAPINFO data).
Although some say that
[t]hough seemingly a simple format, it is complicated by its many different versions, lack of an official specification, lack of any version control process, and ambiguities and contradictions in the documentation.
(http://fileformats.archiveteam.org/wiki/BMP)
you don't actually need to understand each single byte. The various structures either have a fixed size (the initial BITMAPFILEHEADER for example), or have their length as its first value.
A line by line annotation of most well-documented parts:
-------- BITMAPFILEHEADER
00000000 42 4d file type identifier
00000002 aa 00 00 00 size in bytes of the entire file
00000006 00 00 (reserved and must be 0)
00000008 00 00 (reserved and must be 0)
0000000A 82 00 00 00 offset from the beginning of the BITMAPFILEHEADER structure to the bitmap bits
-------- BITMAPINFOHEADER
0000000E 6c 00 00 00 BITMAPINFOHEADER structure size
00000012 0a 00 00 00 image width in pixels
00000016 0a 00 00 00 image height in pixels
0000001A 01 00 number of planes
0000001C 01 00 number of bits per pixel
0000001E 00 00 00 00 compression
00000022 28 00 00 00 size in bytes of image data
00000026 13 0b 00 00 horizontal resolution in pixels-per-meter
0000002A 13 0b 00 00 vertical resolution in pixels-per-meter
0000002E 02 00 00 00 number of colors in the color table that are actually used by the bitmap
00000032 02 00 00 00 number of color indexes that are required ("important")
........ badly documented stuff ........
00000036 42 47 52 73 00 00 00 00 00 00
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000060 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00
00000070 00 00 00 00 00 00 00 00 00 00
-------- end of BITMAPINFOHEADER
-------- bmiColors array
0000007A ff ff ff 00 color table entry #0
0000007E 00 00 00 00 color table entry #1
-------- Image data
00000082 ff c0 00 00 ff c0 00 00 ff c0 00 00 ff c0
000000a0 00 00 ff c0 00 00 aa 80 00 00
The "number of bits per pixel" at 0000001C is 1:
"1 = The bitmap is monochrome, and the bmiColors member of BITMAPINFO contains two entries. Each bit in the bitmap array represents a pixel. If the bit is clear, the pixel is displayed with the color of the first entry in the bmiColors table; if the bit is set, the pixel has the color of the second entry in the table."
(https://msdn.microsoft.com/en-us/library/dd183376(v=vs.85).aspx)
and the number of colors in the array is reported to be 2. So the bmiColors array contains 2 elements in Microsoft's RGBQUAD format, with values in the odd order Blue, Green, Red, and Reserved.
In short: in your image, a pixel value of 0 (a 0 bit in a monochrome image) is FFFFFF: white, and a pixel value of 1 is 000000: black.

sed extract data from dos text file convert to csv

I need to pull RAM information from several cpuz reports and put them into a csv for reporting reasons.
below is an example text file (snipped) which contains the text i want to extract.
I want to extract all the text following the lines beginning with DIMM but only where the next line begins with tab and SMBus address, and going down to nominal voltage. I'd then like to split them into columns (although I only really care about the type, size and max bandwidth)
the resultant csv would have the following columns (and 2 rows in this example)
computer name (from file name), Dimm #, smbus address, memory type, manufacturer, etc.
However I have fallen at the first, extraction phase. I was using sed but fell over at this multiline command:
sed -n -e 'N;/DIMM #\t*[0-9]\r\n\t/,/Nominal/p' cpuz-FHD505.txt
for some reason it only picks up the DIMM #2 block.
what sed statement should I use to just give me the two dimm blocks up to the line including Nominal voltage?
to be honest I'm probably going to give up and write this in python anyway as I'm more familiar, but I'd love to know where I've screwed up on this multiline sed statement.
cpuz output:-
Chipset
-------------------------------------------------------------------------
Northbridge Intel i845G rev. A1
Southbridge Intel 82801DB (ICH4) rev. 01
Memory Type DDR
Memory Size 1024 MBytes
Memory Frequency 132.9 MHz (1:1)
CAS# latency (CL) 2.0
RAS# to CAS# delay (tRCD) 3
RAS# Precharge (tRP) 3
Cycle Time (tRAS) 6
DRAM Idle Timer 16
Memory SPD
-------------------------------------------------------------------------
DIMM # 1
SMBus address 0x50
Memory type DDR
Manufacturer (ID) Infineon (C1494E46494E454F)
Size 512 MBytes
Max bandwidth PC2700 (166 MHz)
Part number 64D64320GU6B
Serial number 075ADD21
Manufacturing date Week 56/Year 03
Number of banks 2
Data width 64 bits
Correction None
Registered no
Buffered no
Nominal Voltage 2.50 Volts
EPP no
XMP no
JEDEC timings table CL-tRCD-tRP-tRAS-tRC # frequency
JEDEC #1 2.0-3-3-6-n.a. # 133 MHz
JEDEC #2 2.5-3-3-7-n.a. # 166 MHz
DIMM # 2
SMBus address 0x51
Memory type DDR
Manufacturer (ID) Samsung (CE00000000000000)
Size 512 MBytes
Max bandwidth PC2700 (166 MHz)
Part number M3 68L6423ETN-CB3
Serial number 060EFC37
Manufacturing date Week 54/Year 04
Number of banks 2
Data width 64 bits
Correction None
Registered no
Buffered no
Nominal Voltage 2.50 Volts
EPP no
XMP no
JEDEC timings table CL-tRCD-tRP-tRAS-tRC # frequency
JEDEC #1 2.0-3-3-6-n.a. # 133 MHz
JEDEC #2 2.5-3-3-7-n.a. # 166 MHz
DIMM # 1
SPD registers
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 80 08 07 0D 0A 02 40 00 04 60 70 00 82 08 00 01
10 0E 04 0C 01 02 20 C0 75 70 00 00 48 30 48 2A 40
20 75 75 45 45 00 00 00 00 00 3C 48 30 2D 55 00 00
30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
40 C1 49 4E 46 49 4E 45 4F 08 36 34 44 36 34 33 32
50 30 47 55 36 42 20 20 20 20 20 20 01 4A 03 38 07
60 5A DD 21 00 00 00 00 00 00 00 00 00 00 00 00 00
70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
90 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
A0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
B0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
D0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
E0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
DIMM # 2
SPD registers
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 80 08 07 0D 0A 02 40 00 04 60 70 00 82 08 00 01
10 0E 04 0C 01 02 20 C0 75 70 00 00 48 30 48 2A 40
20 80 80 45 45 00 00 00 00 00 3C 48 30 2D 55 00 00
30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 27
40 CE 00 00 00 00 00 00 00 01 4D 33 20 36 38 4C 36
50 34 32 33 45 54 4E 2D 43 42 33 20 4E 45 04 36 06
60 0E FC 37 00 58 39 42 36 37 30 30 00 00 00 00 00
70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80 00 03 B2 10 09 19 FF FF FF FF FF 05 12 05 FF FF
90 00 03 B2 10 09 39 FF FF FF FF FF 02 20 18 FF FF
A0 00 03 B2 10 09 19 FF FF FF FF FF 04 23 54 FF FF
B0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
D0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
E0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Monitoring
-------------------------------------------------------------------------
Mainboard Model 07E4h (0x00000148 - 0x00024680)
LPCIO
-------------------------------------------------------------------------
LPCIO Vendor SMSC
LPCIO Vendor ID 0x55
LPCIO Chip ID 0x6D
Config Mode I/O address 0x2E
Config Mode LDN 0x8
Config Mode registers
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00
10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20 6D 01 09 00 04 00 2E 00 00 00 00 00 00 00 00 00
30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Hardware Monitors
-------------------------------------------------------------------------
Hardware monitor SMSC EMC6D10X
Voltage 0 0.00 Volts [0x0] (+1.5V)
Voltage 1 1.47 Volts [0x7D] (CPU VCORE)
Voltage 2 3.26 Volts [0xBE] (ATX +3.3V)
Voltage 3 5.10 Volts [0xC4] (ATX +5V)
Voltage 4 11.98 Volts [0xBF] (ATX +12V)
Temperature 0 0°C (32°F) [0x0] (Diode 1)
Temperature 1 24°C (75°F) [0x18] (Internal)
Temperature 2 33°C (91°F) [0x21] (Diode 2)
Fan 0 1455 RPM [0xE7F] (FANIN0)
Register space SMBus, base address = 0x0FC00
SMBus request channel 0x0, address 0x2E
output:
DIMM # 2
SMBus address 0x51
Memory type DDR
Manufacturer (ID) Samsung (CE00000000000000)
Size 512 MBytes
Max bandwidth PC2700 (166 MHz)
Part number M3 68L6423ETN-CB3
Serial number 060EFC37
Manufacturing date Week 54/Year 04
Number of banks 2
Data width 64 bits
Correction None
Registered no
Buffered no
Nominal Voltage 2.50 Volts
EPP no
Give this a try:
sed -n ':a; /^DIMM/,/^[[:blank:]]*Nominal Voltage/ N; /^DIMM/,/[[:blank:]]*Nominal Voltage/ ! d ;/[[:blank:]]*Nominal Voltage/ {/[[:blank:]]*Nominal Voltage/p;d}; ba' cpuz-FHD505.txt
awk -vRS="" -F"\n" '/DIMM/&&$2~/SMBus/{
for(i=1;i<=NF;i++) {
print $i
# from here, you process the columns you need
}
}' file