I'm trying to send a command line through PowerShell so I can power on a projector via serial port. I'm using a NEC projector and the command for turn on and turn off the projector are these:
Power On: 02H 00H 00H 00H 00H 02H
Power Off: 02H 01H 00H 00H 00H 03H
I use the manufacture's software and I did monitor what it sent and for turn it on it use the following:
Open COM port
wrote:
00 bf 00 00 01 00 c0
read:
20 bf 01 20 10 00 ff 22 4d 33 35 33 57 53 00 00
00 08 12 00 00 dd
wrote:
00 bf 00 00 01 02 c2
read:
20 bf 01 20 10 02 0f ff ff ff ff 00 00 00 00 00
00 00 00 00 00 1d
Wrote (this is the command line I identified in the manual):
02 00 00 00 00 02
and then it close the open COM port.
I'm trying to figure out how to send the command.
I did some digging and found out the command:
$port.WriteLine
but it doesn't send hex, it sends this:
30 30 20 62 66 20 30 30 20 30 30 20 30 31 20 30 00 bf 00 00 01 0
30 20 63 30 0a 0 c0.
[Byte[]] $powerOn = 0x02,0x00,0x00,0x00,0x00,0x02
[Byte[]] $powerOff = 0x02,0x01,0x00,0x00,0x00,0x03
# Use your COM port here
$port = new-Object System.IO.Ports.SerialPort COM3,9600,None,8,one
$port.Open()
$port.Write($powerOn, 0, $powerOn.Count)
# ...
$port.Write($powerOff, 0, $powerOff.Count)
$port.Close()
Related
As part of installation of linux, I would like to set the "console device properties"(example, console=ttyS0,115200n1) via the kernel cmdline for Intel based platform.
There is No VGA console, only serial consoles via COM interface.
On these systems BIOS already has the required settings to interact using the appropriate serial port.
I see that EFI has variables ConIn, ConOut, ConErr which I am able to see from /sys/firmware/efi but unable to decode the contents of it.
Is it possible to identify which COM port is being used by the BIOS by examining the efi variables.
Example, of the EFI var on my box.
root#linux:~# efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Name: "ConOut"
Attributes:
Non-Volatile
Boot Service Access
Runtime Service Access
Value:
00000000 02 01 0c 00 d0 41 03 0a 00 00 00 00 01 01 06 00 |.....A..........|
00000010 00 1a 03 0e 13 00 00 00 00 00 00 c2 01 00 00 00 |................|
00000020 00 00 08 01 01 03 0a 18 00 9d 9a 49 37 2f 54 89 |...........I7/T.|
00000030 4c a0 26 35 da 14 20 94 e4 01 00 00 00 03 0a 14 |L.&5.. .........|
00000040 00 53 47 c1 e0 be f9 d2 11 9a 0c 00 90 27 3f c1 |.SG..........'?.|
00000050 4d 7f 01 04 00 02 01 0c 00 d0 41 03 0a 00 00 00 |M.........A.....|
00000060 00 01 01 06 00 00 1f 02 01 0c 00 d0 41 01 05 00 |............A...|
00000070 00 00 00 03 0e 13 00 00 00 00 00 00 c2 01 00 00 |................|
00000080 00 00 00 08 01 01 03 0a 18 00 9d 9a 49 37 2f 54 |............I7/T|
00000090 89 4c a0 26 35 da 14 20 94 e4 01 00 00 00 03 0a |.L.&5.. ........|
000000a0 14 00 53 47 c1 e0 be f9 d2 11 9a 0c 00 90 27 3f |..SG..........'?|
000000b0 c1 4d 7f ff 04 00 |.M.... |
root#linux:~#
The contents of the ConOut variable are described in the UEFI specification - current version (2.8B):
3.3 - globally defined variables:
| Name | Attribute | Description |
|---------|------------|------------------------------------------------|
| ConOut | NV, BS, RT | The device path of the default output console. |
For information about device paths, we have:
10 - Protocols — Device Path Protocol:
Apart from the initial description of device paths, table 44 shows you the Generic Device Path Node structure, from which we can start decoding the contents of the variable.
The type of the first node is 0x02, telling us this node describes an ACPI device path, of 0x000c bytes length. Now jump down to 10.3.3 - ACPI Device Path and table 52, which tells us 1) that this is the right table (subtype 0x01) and 2) that the default ConOut has a _HID of 0x0a03410d and a _UID of 0.
The next node has a type of 0x01 - a Hardware Device Path, described further in 10.3.2, in this case table 46 (SubType is 0x01) for a PCI device path.
The next node describes a Messaging Device Path of type UART and so on...
Still, this only tells you what UEFI considers to be its default console, SPCR is what an operating system is supposed to be looking at for serial consoles. Unfortunately, on X86 the linux kernel handily ignores SPCR apart from for earlycon. I guess this is what you're trying to work around. It might be good to start some discussion on kernel development lists about whether to fix that and have X86 work like ARM64.
In my case since I know that console port is a "Serial IOPORT",
I could get the details now as follows.
a. Get hold of the /sys/firmware/acpi/tables/SPC table.
b. Read the Address offset 44-52. Actually one the last two bytes suffice.
Reference:
a. https://learn.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table states that
Base Address 12 40
The base address of the Serial Port register set described using the ACPI Generic Address Structure.
0 = console redirection disabled
Note:
COM1 (0x3F8) would be:
Integer Form: 0x 01 08 00 00 00000000000003F8
Viewed in Memory: 0x01080000F803000000000000
COM2 (Ox2F8) would be:
Integer Form: 0x 01 08 00 00 00000000000002F8
Viewed in Memory: 0x01080000F802000000000000
When I use powershell tee-object cmdlet to save the output to a file, blank lines are created between each actual line. Output gets doubled and ugly, in both screen output, as well in the redirected file.
regular command, and output:
# db2 connect to sample
Database Connection Information
Database server = DB2/NT64 11.5.0.0
SQL authorization ID = SAMUEL
Local database alias = SAMPLE
but, when you use Tee-Object against it... here is what happens:
# db2 connect to sample | Tee-Object test.out
Database Connection Information
Database server = DB2/NT64 11.5.0.0
SQL authorization ID = SAMUEL
Local database alias = SAMPLE
In both screen output, and also in the generated file a well:
# type test.out
Database Connection Information
Database server = DB2/NT64 11.5.0.0
SQL authorization ID = SAMUEL
Local database alias = SAMPLE
--- edit ---
#js2010, here is the entire hex-format for better reading.. cant paste it properly in the comments.
# format-hex test.out
Path: E:\PowerShell_Tests\db2mon\test.out
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 FF FE 0D 00 0A 00 0D 00 0A 00 20 00 20 00 20 00 .þ........ . . .
00000010 44 00 61 00 74 00 61 00 62 00 61 00 73 00 65 00 D.a.t.a.b.a.s.e.
00000020 20 00 43 00 6F 00 6E 00 6E 00 65 00 63 00 74 00 .C.o.n.n.e.c.t.
00000030 69 00 6F 00 6E 00 20 00 49 00 6E 00 66 00 6F 00 i.o.n. .I.n.f.o.
00000040 72 00 6D 00 61 00 74 00 69 00 6F 00 6E 00 0D 00 r.m.a.t.i.o.n...
00000050 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 20 00 .............. .
00000060 44 00 61 00 74 00 61 00 62 00 61 00 73 00 65 00 D.a.t.a.b.a.s.e.
00000070 20 00 73 00 65 00 72 00 76 00 65 00 72 00 20 00 .s.e.r.v.e.r. .
00000080 20 00 20 00 20 00 20 00 20 00 20 00 20 00 3D 00 . . . . . . .=.
00000090 20 00 44 00 42 00 32 00 2F 00 4E 00 54 00 36 00 .D.B.2./.N.T.6.
000000A0 34 00 20 00 31 00 31 00 2E 00 35 00 2E 00 30 00 4. .1.1...5...0.
000000B0 2E 00 30 00 0D 00 0A 00 0D 00 0A 00 20 00 53 00 ..0......... .S.
000000C0 51 00 4C 00 20 00 61 00 75 00 74 00 68 00 6F 00 Q.L. .a.u.t.h.o.
000000D0 72 00 69 00 7A 00 61 00 74 00 69 00 6F 00 6E 00 r.i.z.a.t.i.o.n.
000000E0 20 00 49 00 44 00 20 00 20 00 20 00 3D 00 20 00 .I.D. . . .=. .
000000F0 53 00 41 00 4D 00 55 00 45 00 4C 00 0D 00 0A 00 S.A.M.U.E.L.....
00000100 0D 00 0A 00 20 00 4C 00 6F 00 63 00 61 00 6C 00 .... .L.o.c.a.l.
00000110 20 00 64 00 61 00 74 00 61 00 62 00 61 00 73 00 .d.a.t.a.b.a.s.
00000120 65 00 20 00 61 00 6C 00 69 00 61 00 73 00 20 00 e. .a.l.i.a.s. .
00000130 20 00 20 00 3D 00 20 00 53 00 41 00 4D 00 50 00 . .=. .S.A.M.P.
00000140 4C 00 45 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 L.E.............
00000150 0D 00 0A 00 ....
Also, your 2nd test reveals that the problem is not about using tee-object cmdlet, but actually, just piping the output causes it...
Another information, If I perform a redirect to a file, from a regular windows cmd window, the issue does not happens,
from cmd window:
E:\PowerShell_Tests\db2mon>db2 connect to sample > cmd.out
E:\PowerShell_Tests\db2mon>type cmd.out
Database Connection Information
Database server = DB2/NT64 11.5.0.0
SQL authorization ID = SAMUEL
Local database alias = SAMPLE
but, performing the same redirect from a powershell session, created the double lines again:
# db2 connect to sample > pwsh.out
PS [Samuel]E:\PowerShell_Tests\db2mon
# Get-Content pwsh.out
Database Connection Information
Database server = DB2/NT64 11.5.0.0
SQL authorization ID = SAMUEL
Local database alias = SAMPLE
--- end edit ---
--- edit 2 ---
#js2010
# db2 connect to sample | format-hex
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 20 20 20 44 61 74 61 62 61 73 65 20 43 6F 6E 6E Database Conn
00000010 65 63 74 69 6F 6E 20 49 6E 66 6F 72 6D 61 74 69 ection Informati
00000020 6F 6E on
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 20 44 61 74 61 62 61 73 65 20 73 65 72 76 65 72 Database server
00000010 20 20 20 20 20 20 20 20 3D 20 44 42 32 2F 4E 54 = DB2/NT
00000020 36 34 20 31 31 2E 35 2E 30 2E 30 64 11.5.0.0
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 20 53 51 4C 20 61 75 74 68 6F 72 69 7A 61 74 69 SQL authorizati
00000010 6F 6E 20 49 44 20 20 20 3D 20 53 41 4D 55 45 4C on ID = SAMUEL
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 20 4C 6F 63 61 6C 20 64 61 74 61 62 61 73 65 20 Local database
00000010 61 6C 69 61 73 20 20 20 3D 20 53 41 4D 50 4C 45 alias = SAMPLE
--- end edit 2 ---
Does any one has any clue on what is going on, and how can I "fix" it ?
Thanks
As your Format-Hex output implies, db2 - bizarrely - uses CRCRLF ("`r`r`n" in PowerShell terms) rather than the usual CRLF sequences ("`r`n") as newlines (to separate its output lines) - it is a behavior it shares with sfc.exe.
When you print to the display, this anomaly doesn't surface, but it does when you capture or redirect the output, such as via Tee-Object.
The workaround is to eliminate every other line, which discards the extra lines that result from PowerShell interpreting a CR ("`r") by itself as a newline too:
$i = 0
db2 ... | Where-Object { ++$i % 2 } | Tee-Object test.out
Update: You've since provided a convenient wrapper function based on this solution in your own answer.
for other Db2 DBAs out there trying to use powershell as me..
I have created this small hack, to handle this for all my db2 ps sessions.
Edit your powershell user profile, creating an function and alias as above:
$Home[My ]Documents\PowerShell\Microsoft.PowerShell_profile.ps1 :
# db2 settings for powershell
Set-Item -Path env:DB2CLP -value "**$$**"
# Handle db2 output, avoiding doubled lines due 'CRCRLF' pattern
Function Handle-Db2 {
$i = 0
db2 $args | Where-Object { ++$i % 2 }
}
New-Alias -Name "db2ps" Handle-Db2
Now, if you want to use the hacked version, instead of calling db2 .... you can use db2ps ... instead and have a proper output.
# db2ps describe table employee | Tee-Object employee.out
Data type Column
Column name schema Data type name Length Scale Nulls
------------------------------- --------- ------------------- ---------- ----- ------
EMPNO SYSIBM CHARACTER 6 0 No
FIRSTNME SYSIBM VARCHAR 12 0 No
MIDINIT SYSIBM CHARACTER 1 0 Yes
LASTNAME SYSIBM VARCHAR 15 0 No
WORKDEPT SYSIBM CHARACTER 3 0 Yes
PHONENO SYSIBM CHARACTER 4 0 Yes
HIREDATE SYSIBM DATE 4 0 Yes
JOB SYSIBM CHARACTER 8 0 Yes
EDLEVEL SYSIBM SMALLINT 2 0 No
SEX SYSIBM CHARACTER 1 0 Yes
BIRTHDATE SYSIBM DATE 4 0 Yes
SALARY SYSIBM DECIMAL 9 2 Yes
BONUS SYSIBM DECIMAL 9 2 Yes
COMM SYSIBM DECIMAL 9 2 Yes
14 record(s) selected.
# db2ps describe table employee | Select-String "DEC"
SALARY SYSIBM DECIMAL 9 2 Yes
BONUS SYSIBM DECIMAL 9 2 Yes
COMM SYSIBM DECIMAL 9 2 Yes
It would be nice if IBM fix this odd CRCRLF behavior on db2 commands on windows.
Until this not happens, enjoy!
Regards
In my attempt to get "Steam for Linux" working on Debian, I've run into an issue. libcef (Chromium Embedded Framework) works fine with GLIBC_2.13 (which eglibc on Debian testing can provide), but requires one pesky little extra function from GLIBC_2.15 (which eglibc can't provide):
$ readelf -s libcef.so | grep -E "#GLIBC_2\.1[4567]"
1037: 00000000 0 FUNC GLOBAL DEFAULT UND __fdelt_chk#GLIBC_2.15 (49)
2733: 00000000 0 FUNC GLOBAL DEFAULT UND __fdelt_chk##GLIBC_2.15
My plan of attack here was to LD_PRELOAD a shim library that provides just these functions. This doesn't seem to work. I really want to avoid installing GLIBC_2.17 (since it is in Debian experimental; even Debian sid still has GLIBC_2.13).
This is what I've tried.
fdelt_chk.c is basically stolen from the GNU C library:
#include <sys/select.h>
# define strong_alias(name, aliasname) _strong_alias(name, aliasname)
# define _strong_alias(name, aliasname) \
extern __typeof (name) aliasname __attribute__ ((alias (#name)));
unsigned long int
__fdelt_chk (unsigned long int d)
{
if (d >= FD_SETSIZE)
__chk_fail ();
return d / __NFDBITS;
}
strong_alias (__fdelt_chk, __fdelt_warn)
My Versions script looks as follows:
GLIBC_2.15 {
__fdelt_chk; __fdelt_warn;
};
I then build the library as follows:
$ gcc -m32 -c -fPIC fdelt_chk.c -o fdelt_chk.o
$ gcc -m32 -shared -nostartfiles -Wl,-s -Wl,--version-script Versions -o fdelt_chk.so fdelt_chk.o
However, if I then run Steam (with a bunch of extra stuff to get it working in the first place), the loader still refuses to find the symbol:
% LD_LIBRARY_PATH="/home/tinctorius/.local/share/Steam/ubuntu12_32" LD_PRELOAD=./fdelt_chk.so:./steamui.so ./steam
./steam: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by /home/tinctorius/.local/share/Steam/ubuntu12_32/libcef.so)
However, the version symbol is also provided by the .so I just built:
% readelf -s fdelt_chk.so
Symbol table '.dynsym' contains 8 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FUNC GLOBAL DEFAULT UND __chk_fail#GLIBC_2.3.4 (3)
2: 0000146c 0 NOTYPE GLOBAL DEFAULT ABS _edata
3: 0000146c 0 NOTYPE GLOBAL DEFAULT ABS _end
4: 00000310 44 FUNC GLOBAL DEFAULT 11 __fdelt_warn##GLIBC_2.15
5: 00000310 44 FUNC GLOBAL DEFAULT 11 __fdelt_chk##GLIBC_2.15
6: 00000000 0 OBJECT GLOBAL DEFAULT ABS GLIBC_2.15
7: 0000146c 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
At this point, I don't know what I can do to trick the loader (who?) into choosing my symbols. Am I going in the right direction at all?
I ran into this same problem, though not with Steam. What I was trying to run wanted 2.15 for fdelt_chk while my system had 2.14. I found a solution for simple cases like ours where we can easily provide our own implementation for the missing functionality.
I started out from your attempted solution of implementing the functionality and LD_PRELOADing it. Using LD_DEBUG=all (as suggested by osgx) showed that the linker was still looking for 2.15, so just having the right symbol wasn't enough and there was some other versioning mechanism somewhere. I noticed that objdump -p and readelf -V both showed references to 2.15, so I looked up documentation on ELF and found information on version requirements.
So my new goal was to transform references to 2.15 into references to something else. It seemed reasonable that I could just overwrite structures that referred to 2.15 with the structures that referred to some lower version, like 2.1. In the end, after some trial and error, I found just editing the right Elfxx_Vernaux(es?) in .gnu.version_r was sufficient, but caveat hacker, I guess.
The .gnu.version_r section is a list of 16-byte Elfxx_Verneeds and 16-byte Elfxx_Vernauxes. Each Elfxx_Verneed entry is followed by the associated Elfxx_Vernauxes. As far as I could tell, vn_file is actually how many associated Elfxx_Vernauxes there are, even though the docs say number of associated verneed array entries. It might just be a misunderstanding on my part, though.
So, to start off making the edits, let's look at some of the info from readelf -V. I snipped out parts we don't care about.
$ readelf -V mybinary
<snip stuff before .gnu.version_r>
Version needs section '.gnu.version_r' contains 5 entries:
Addr: 0x00000000000021ac Offset: 0x0021ac Link: 4 (.dynstr)
<snip libraries that don't refer to GLIBC_2.15>
0x00c0: Version: 1 File: libc.so.6 Cnt: 10
0x00d0: Name: GLIBC_2.3 Flags: none Version: 19
0x00e0: Name: GLIBC_2.7 Flags: none Version: 16
0x00f0: Name: GLIBC_2.2 Flags: none Version: 15
0x0100: Name: GLIBC_2.2.4 Flags: none Version: 14
0x0110: Name: GLIBC_2.1.3 Flags: none Version: 13
0x0120: Name: GLIBC_2.15 Flags: none Version: 12
0x0130: Name: GLIBC_2.4 Flags: none Version: 10
0x0140: Name: GLIBC_2.1 Flags: none Version: 9
0x0150: Name: GLIBC_2.3.4 Flags: none Version: 4
0x0160: Name: GLIBC_2.0 Flags: none Version: 2
From this we see that the section starts at 0x21ac. Each file listed will have a Elfxx_Verneed followed by an Elfxx_Vernaux for each of the subentries (like GLIBC_2.3). I assume the order of the info in the output will always match the order in the file since readelf is just dumping the structures. Here's my entire .gnu.version_r section.
000021A0 01 00 02 00
000021B0 A3 0C 00 00 10 00 00 00 30 00 00 00 11 69 69 0D
000021C0 00 00 11 00 32 0D 00 00 10 00 00 00 10 69 69 0D
000021D0 00 00 0B 00 3C 0D 00 00 00 00 00 00 01 00 02 00
000021E0 BE 0C 00 00 10 00 00 00 30 00 00 00 13 69 69 0D
000021F0 00 00 08 00 46 0D 00 00 10 00 00 00 10 69 69 0D
00002200 00 00 07 00 3C 0D 00 00 00 00 00 00 01 00 02 00
00002210 99 0C 00 00 10 00 00 00 30 00 00 00 11 69 69 0D
00002220 00 00 06 00 32 0D 00 00 10 00 00 00 10 69 69 0D
00002230 00 00 05 00 3C 0D 00 00 00 00 00 00 01 00 02 00
00002240 AE 0C 00 00 10 00 00 00 30 00 00 00 11 69 69 0D
00002250 00 00 12 00 32 0D 00 00 10 00 00 00 10 69 69 0D
00002260 00 00 03 00 3C 0D 00 00 00 00 00 00 01 00 0A 00
00002270 FF 0C 00 00 10 00 00 00 00 00 00 00 13 69 69 0D
00002280 00 00 13 00 46 0D 00 00 10 00 00 00 17 69 69 0D
00002290 00 00 10 00 50 0D 00 00 10 00 00 00 12 69 69 0D
000022A0 00 00 0F 00 5A 0D 00 00 10 00 00 00 74 1A 69 09
000022B0 00 00 0E 00 64 0D 00 00 10 00 00 00 73 1F 69 09
000022C0 00 00 0D 00 70 0D 00 00 10 00 00 00 95 91 96 06
000022D0 00 00 0C 00 7C 0D 00 00 10 00 00 00 14 69 69 0D
000022E0 00 00 0A 00 87 0D 00 00 10 00 00 00 11 69 69 0D
000022F0 00 00 09 00 32 0D 00 00 10 00 00 00 74 19 69 09
00002300 00 00 04 00 91 0D 00 00 10 00 00 00 10 69 69 0D
00002310 00 00 02 00 3C 0D 00 00 00 00 00 00
To briefly talk about the structure here, it starts out with an Elfxx_Verneed. As per the docs, we can see there will be 2 Elfxx_Vernauxes, one offset 16 bytes, and the next Elfxx_Verneed is offset 48 bytes. These offsets are from the start of the current structure. It looks like technically the associated Elfxx_Vernauxes might not be adjacent after the current Elfxx_Verneed but it was actually so in all the files I poked around in.
From this we can find the file we want (libc.so.6) in a few different ways. Cross reference the string (which I won't get into), find the Elfxx_Verneed with a count of 0A 00 (10, matching our readelf output above), or find the last Elfxx_Verneed since it's the last one readelf output. In any case, the right one for my file is at 0x226C. Its first Elfxx_Vernaux starts at 0x227C.
We want to find the Elfxx_Vernaux with a version of 0C 00 (12, again matching our readelf output above). We see the Elfxx_Vernaux that matches is at 0x22CC and the entire structure is 95 91 96 06 00 00 0C 00 7C 0D 00 00 10 00 00 00. We'll be overwriting the first 12 bytes so as to leave the offset alone. We're only modifying the data, not moving around the structures, after all.
To pick the data to overwrite with, we just copy it from a different Elfxx_Vernaux for a version of glibc we can satisfy. I picked one for 2.1, which is at 0x22EC in my file, with the data 11 69 69 0D 00 00 09 00 32 0D 00 00 10 00 00 00. So take the first 12 bytes from this and overwrite the first 12 bytes above, and that's it for the hex editing.
Of course, you might have multiple references to deal with. Your program might have multiple binaries to edit.
At this point, our program still won't run. But instead of being told something like GLIBC_2.15 not found it should complain about missing __fdelt_chk. Now we do the shim and LD_PRELOADing described in the question, except instead of versioning our implementation as 2.15, we use the version we picked while hex editing. At this point the program should run.
This method depends on being able to provide an implementation for whatever's missing. Our __fdelt_chk is extremely simple but I don't doubt that in some cases providing an implementation could be more difficult than just upgrading the system's libc instead.
For what it's worth, the __fdelt_chk function is related to the FORTIFY_SOURCE feature which was added in glibc 2.15. It enables compile-time and run-time checking for buffer overflows.
If you were able to recompile with the following CFLAGS added, it would build a backwards compatible binary without the extra checking:
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
I write the following bytes into a file named disk.img
FA 8D 36 1B 7C E8 01 00 F4 AC 3C 00 74 0C B4 0E
BB 07 00 B9 01 00 CD 10 EB EF C3 4D 61 79 20 74
68 65 20 66 6F 72 63 65 20 62 65 20 77 69 74 68
20 79 6F 75 21 0D 0A 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
..enough zero to make the size of file 512bytes.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
The above bytes are proper instructions and magic number that should work when loading into the boot sector. But after I executed "qemu-X86_64 disk.img", error happens.
Error -13 while loading disk.img
Does anyone know how to solve the problem or what is the reason that might lead to this error?
Thank you!
I don't know if you can fill an image with just anything and expect it to work just because you have 55 AA in the correct place. Since you seem to be writing a bootloader make sure your code thinks it is executing at the correct place. It should be in offset 0x7C00 (if I remember this correctly, double check that). You set it by writing the line [org 0x7C00] at the top of your assembly file.
Also I'm not sure you can have only a 512 byte file. Try to make the disk image bigger than that using something like dd if=/dev/zero of=disk.img bs=512 count=2000 and then just copy your bootloader to the first part of the disk using dd again.
Also, you should use the -hda or -fda tags, so it would be qemu -hda disk.img. -hda means hard drive image, and -fda means floppy disk image.
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