At mount time JFFS2 CLEANMARKER size change from default 0x0C (12B) to 0x0200 (512B).
I saw this behaviour when I mount my test image on target hw (NOR) and file system size increased in crazy way when I copy any file to it.
Test bench
I create a file with 512kB of "aa55" only for reference and with it the JFFS2 file system uncompressed image was created (erase block 128kB page 4kB)
dd if=<(yes $'\xaa55' |tr -d "\n") of=firma_512kB.txt bs=1024 count=512
mkdir firma/
cp firma
cp firma_512kB.txt firma/
sudo mkfs.jffs2 -v -o firma_512.jffs2 -e 0x20000 -s 0x1000 -m none -d firma/
On target the image was copied to mtd14. (It was erased previously. Look that CLEANMARKER has 0x0c size)
flash_eraseall -j /dev/mtd14
00000000 85 19 03 20 0c 00 00 00 b1 b0 1e e4 ff ff ff ff |... ............|
00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
...
000a0000 85 19 03 20 0c 00 00 00 b1 b0 1e e4 ff ff ff ff |... ............|
000a0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000c0000 85 19 03 20 0c 00 00 00 b1 b0 1e e4 ff ff ff ff |... ............|
000c0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
...
*
00860000 85 19 03 20 0c 00 00 00 b1 b0 1e e4 ff ff ff ff |... ............|
00860010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00880000
Image copy to mtd15 device and inspection, shows... (It could be seen that image was copy ok and CLEANMARKER size still is 0x0c)
dd if=firma_512.jffs2 of=/dev/mtd14
hexdump -C /dev/mtd14
(hexdump -C /dev/mtdblock14 gives the same result)
....
00081340 85 19 02 e0 44 10 00 00 6d 58 d1 84 02 00 00 00 |....D...mX......|
00081350 84 00 00 00 a4 81 00 00 e8 03 e8 03 00 00 08 00 |................|
00081360 a3 dc df 53 a3 dc df 53 a3 dc df 53 00 f0 07 00 |...S...S...S....|
00081370 00 10 00 00 00 10 00 00 00 00 00 00 db 7c 54 f0 |.............|T.|
00081380 3c 30 bd 6f aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 |<0.o.U.U.U.U.U.U|
00081390 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 |.U.U.U.U.U.U.U.U|
*
00082380 aa 55 aa 55 ff ff ff ff ff ff ff ff ff ff ff ff |.U.U............|
00082390 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000a0000 85 19 03 20 0c 00 00 00 b1 b0 1e e4 ff ff ff ff |... ............|
000a0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000c0000 85 19 03 20 0c 00 00 00 b1 b0 1e e4 ff ff ff ff |... ............|
000c0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
And now the braindeath problem, at least for me.
mount -t jffs2 /dev/mtdblock14 /mnt/app2
dmesg
CLEANMARKER node found at 0x00000000 has totlen 0xc != normal 0x200
...
CLEANMARKER node found at 0x000c0000 has totlen 0xc != normal 0x200
CLEANMARKER node found at 0x000e0000 has totlen 0xc != normal 0x200
...
CLEANMARKER node found at 0x00860000 has totlen 0xc != normal 0x200
hexdump -C /dev/mtd14
....
00081340 85 19 02 e0 44 10 00 00 6d 58 d1 84 02 00 00 00 |....D...mX......|
00081350 84 00 00 00 a4 81 00 00 e8 03 e8 03 00 00 08 00 |................|
00081360 a3 dc df 53 a3 dc df 53 a3 dc df 53 00 f0 07 00 |...S...S...S....|
00081370 00 10 00 00 00 10 00 00 00 00 00 00 db 7c 54 f0 |.............|T.|
00081380 3c 30 bd 6f aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 |<0.o.U.U.U.U.U.U|
00081390 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 |.U.U.U.U.U.U.U.U|
*
00082380 aa 55 aa 55 ff ff ff ff ff ff ff ff ff ff ff ff |.U.U............|
00082390 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000a0000 85 19 03 20 00 02 00 00 67 db 4c ad ff ff ff ff |... ....g.L.....|
000a0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000c0000 85 19 03 20 00 02 00 00 67 db 4c ad ff ff ff ff |... ....g.L.....|
000c0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000e0000 85 19 03 20 00 02 00 00 67 db 4c ad ff ff ff ff |... ....g.L.....|
000e0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
The CLEANMARKER size change not only make a mess but waste a lot of space in device. Why at mount time it is changed? It can be avoided?
Your advise/suggestion are welcome
Target desrciption:
Linux-2.6.31
NOR: Spansion S29GL512S (Erase Sector 128kB Page Size 4kB x16dBUS)
Related
I have an object that contains a temporary file buffer:
console.log(myObject)
// output:
{
path: "/some/path",
someBuffer: <Buffer fe d8 ff db 00 43 28 ae 6e 78 8c ee 64 a0 8c 82 8c b4 aa a0 be f0 ff ff f0 dc dc f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ... >
}
After I'm done doing some processing on this buffer I want to release it. How exactly do you release or free a buffer from memory? Just set to null?
myObject.someBuffer = null
Is that all there is to it? Did that free up the memory that the buffer was taking up?
How can I get via SNMP if the VLAN where a port belongs is tagged or untagged on a Procurve switch ?
I've found with this OID : .1.3.6.1.2.1.17.7.1.4.3.1.4 that it returns a series of hex code that should tell me which port belongs to a vlan (this is an extract for vlan 1 and 100):
snmpwalk -v2c -c public 192.168.0.1 .1.3.6.1.2.1.17.7.1.4.3.1.4
SNMPv2-SMI::mib-2.17.7.1.4.3.1.4.1 = Hex-STRING: 00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF 00
00 03 FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF 80 00 00 00
SNMPv2-SMI::mib-2.17.7.1.4.3.1.4.100 = Hex-STRING: FF FF FF FF E0 00 00 00 00 00 00 00 00 00 00 00
03 F0 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
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
My questions are:
How can I get the ifindex from this HEX code?
How can I understand it the port is tagged or untagged?
Thanks.
1.3.6.1.2.1.17.7.1.4.3.1.4 is dot1qVlanStaticUntaggedPorts, part of dot1qVlanStaticTable, defined in Q-BRIDGE-MIB. If a port is listed by this object, it is untagged. If a port is listed in dot1qVlanStaticEgressPorts, also part of dot1qVlanStaticTable, but not listed in dot1qVlanStaticUntaggedPorts, then it is tagged.
Both dot1qVlanStaticEgressPorts and dot1qVlanStaticUntaggedPorts are of type PortList, also defined in Q-BRIDGE-MIB. Each bit of each octet corresponds to one ifIndex, with the most significant bit of the first octet being ifIndex=1, the next bit being ifIndex=2, and so on. If the bit is 1, it is a member; if it is 0 then it is not.
Strange that the agent would be returning such long values (= many, many, many ports), though.
I've got a laptop (MSI GT72S) which features a manual GPU switch button. It can help me switch between the Nvidia GPU and the Intel one so that the disabled one will be hidden to the OS.
However, this function needs a driver called SCM which only supports Windows. When I press the button under Windows, there will be a pop-up window that asks me to reboot the machine so that it can switch to another GPU.
This is really a PIA to me as I use Linux far more often and every time I need to switch the GPU, I have to reboot into Windows and then reboot again. So I'd like to archive this function under Linux.
It seems that this is implemented by editing a block of the SMBIOS (not sure). When the Intel GPU is enabled, this block will be:
Handle 0x0052, DMI type 221, 96 bytes
OEM-specific Type
Header and Data:
DD 60 52 00 0D 01 00 00 00 00 00 00 02 00 FF FF
FF FF FF 03 04 FF FF FF FF FF 05 06 FF FF FF FF
FF 07 08 FF FF FF FF FF 09 00 00 00 00 00 00 0A
00 FF FF FF FF FF 0B 00 FF FF 00 00 00 0C 00 00
09 00 35 10 0D 00 FF FF FF FF FF 0E 00 FF FF FF
FF FF 0F 00 FF FF FF FF FF 10 11 01 02 02 03 00
Strings:
Lan Phy Version
Sensor Firmware Version
Debug Mode Status
Enabled
Performance Mode Status
Disabled
Debug Use USB(Disabled:Serial)
Disabled
ICC Overclocking Version
UNDI Version
EC FW Version
GOP Version
BIOS Guard Version
Base EC FW Version
EC-EC Protocol Version
Royal Park Version
BP1.2.2.0_RP03
...and when the Nvidia GPU is enabled,
Handle 0x0052, DMI type 221, 96 bytes
OEM-specific Type
Header and Data:
DD 60 52 00 0D 01 00 00 00 00 00 00 02 00 FF FF
FF FF FF 03 04 FF FF FF FF FF 05 06 FF FF FF FF
FF 07 08 FF FF FF FF FF 09 00 00 00 00 00 00 0A
00 FF FF FF FF FF 0B 00 FF FF 00 00 00 0C 00 FF
FF FF FF FF 0D 00 FF FF FF FF FF 0E 00 FF FF FF
FF FF 0F 00 FF FF FF FF FF 10 11 01 02 02 03 00
But I haven't touched such stuff before and I don't even know where to start. I have Googled it but few material was found. So I strongly need some suggestions now. Any help would be highly appreciated, thanks!
Looks like this is an OEM-defined structure (type 221) that reports status and version info. This information is built by the BIOS during POST, and posted to memory for reading by OS-based management agents (like dmidecode in Linux). Changing that information will not change the underlying configuration.
I have a very limited linux w/ few basic linux commands.
I need to replace a few chars in a hex / binary file:
INPUT:
# hexdump -C block.bin
00000000 11 11 50 04 42 00 00 00 58 00 00 00 3c 0e e2 d4 |..P.B...X...<...|
00000010 50 0b 00 00 00 80 00 00 00 00 00 00 00 00 d0 d7 |P...............|
00000020 1f 09 00 00 00 00 02 00 00 00 00 04 ff ff ff ff |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 28 31 98 5b d3 0e 05 00 00 00 00 00 00 00 00 00 |(1.[............|
00000050 00 00 00 00 00 00 00 00 64 00 00 00 00 00 10 00 |........d.......|
00000060 00 ff ff ff ff 00 00 00 00 03 01 0d 03 01 0d 01 |................|
00000070 00 00 00 00 0c 00 01 02 00 00 00 00 00 ff ff ff |................|
00000080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000180 00 00 20 00 00 00 ff ff ff ff 01 00 00 0c 00 00 |.. .............|
00000190 04 00 00 00 02 00 00 04 00 00 00 00 00 00 ff ff |................|
000001a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
I need to change the following:
00000060 00 ff ff ff ff 00 00 00 00 03 01 0d 03 01 0d 01 |................|
00000070 00 00 00 00 0c 00 01 02 00 00 00 00 00 ff ff ff |................|
to (and rewrite back to the same file):
00000060 00 ff ff ff ff 00 00 00 00 03 01 0d 03 01 0d 02 |................|
00000070 01 00 00 00 0c 00 01 02 00 00 00 00 00 ff ff ff |................|
Like I've said, I have a handful of commands: hexdump, od, vi, nano, awk, sed, python.
Looking through the internet, many solutions require 3rd party installs or the use of 'xxd'. Both I cannot use.
Any suggestions?
Thanks!
I don't think trying this with sed or awk is a sane idea, so we're stuck with python, which is certainly powerful enough for this task. I'm thinking along these lines:
#!/usr/bin/python
# open file in binary mode for reading and writing
f = open("block.bin", "r+b")
# seek to position and read two bytes
f.seek(0x6f)
data = f.read(2)
# seek to position again
f.seek(0x6f)
# and write the transformed characters back
for d in data:
f.write(chr(ord(d) + 1))
f.close()
Do you know of any good Buffer inspection library for Node.js?
It would be pretty useful to print out a Buffer along with its utf8 content.
Example:
Byte | HEX | UTF-8 | Name
-----+-----+-------+-----------
0 | 48 | H | UPPER H
1 | 65 | e | LOWER E
2 | 6c | l | LOWER L
3 | 6c | l | LOWER L
4 | 6f | o | LOWER O
5 | 20 | | WHITESPACE
6 | 57 | W | UPPER W
7 | 6f | o | LOWER O
8 | 72 | r | LOWER R
9 | 6c | l | LOWER L
10 | 64 | d | LOWER D
Yesterday I made a simple module called hex. It's like the hxd program. No config necessary, easy to use, for debugging purposes.
var hex = require("hex");
hex(buffer);
Output:
Offset 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
000000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000010 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000020 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000030 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000040 54 41 47 42 72 65 61 6B 69 6E 67 20 54 68 65 20 TAGBreaking The
000050 4C 61 77 00 00 00 00 00 00 00 00 00 00 00 00 00 Law.............
000060 00 4A 75 64 61 73 20 50 72 69 65 73 74 00 00 00 .Judas Priest...
000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 42 ...............B
000080 72 69 74 69 73 68 20 53 74 65 65 6C 00 00 00 00 ritish Steel....
000090 00 00 00 00 00 00 00 00 00 00 00 00 00 31 39 38 .............198
0000A0 30 47 72 65 61 74 20 73 6F 6E 67 21 00 00 00 00 0Great song!....
0000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 33 89 ..............3.