I'd like to replace the first stage bootloader in the nand flash on a sama5d36 based system running 4.1.0-linux4sam_5.1 and buildroot-2016.02.
I can replace the kernel image with flashcp just fine, but when I try it with the bootloader, flashcp runs without errors, but the system doesn't boot afterwards, stays at the ROMBOOT prompt.
buildroot:~# flashcp -v at91bootstrap.bin /dev/mtd0
Erasing block: 1/1 (100%)
Writing kb: 14/14 (100%)
Verifying kb: 14/14 (100%)
buildroot:~# reboot
[...]
Sent SIGKILL to all processes
Requesting system reboot
�RomBOOTRestarting system
Then I can write the same bootloader image with sam-ba, and it will boot, so the image is good. How can it be flashed in Linux, without user intervention?
There should be a 208 byte header preceding the actual boot code at the beginning of the flash.
From the SAMA5D3 Datasheet (that I should have read before posting the question)
After Initialization and Reset command, the Boot Program reads the first page without an ECC check, to determine if the NAND parameter header is present. The header is made of 52 times the same 32-bit word (for redundancy reasons) which must contain NAND and
PMECC parameters used to correctly perform the read of the rest of the data in the NAND.
The header is of course there when I dump the contents of the boot sector
buildroot:~# hd < /dev/mtd0 | head -4
00000000 05 24 90 c0 05 24 90 c0 05 24 90 c0 05 24 90 c0 |.$...$...$...$..|
*
000000d0 0e 00 00 ea 05 00 00 ea 05 00 00 ea 05 00 00 ea |................|
000000e0 05 00 00 ea cc 3b 00 00 06 00 00 ea 06 00 00 ea |.....;..........|
the first four bytes are repeated over and over, and the ARM jump table begins at offset 0xD0 (=208=52 * 4)
sam-ba takes care of this header when it writes the boot sector, but the Linux mtd driver and flashcp treats it as ordinary data, so I should supply it.
Related
There is a really strange situation in my Ruby-based processes: their /proc/self/environ is really broken. For some reason, the ENV inside Ruby looks fine but I'd like to understand what's going on.
Processes are started using bundle exec, for example bundle exec sidekiq. The end result is that the /proc/<pid>/environ file only contains a couple of bytes (usually 4) of the invoked command plus a bunch of zeroes. In the example above, the environ file would look like
$ sudo hexdump -C /proc/2613895/environ
00000000 65 6b 69 71 00 00 00 00 00 00 00 00 00 00 00 00 |ekiq............|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000390 00 00 00 00 00 00 00 |.......|
00000397
When invoking another command line, for example a rake task, the environ file would contain the last couple of characters of the rake task name.
Since the environ file cannot be modified by the process itself after it starts, it must have been set by whomever made the execve call but I am stupefied who might be responsible and why.
This seems to mostly happen when processes are started through systemd, but none of the other processes started by systemd show the same behaviour; only the ones started through bundle exec so I'm thinking that it's not related to systemd.
The /proc/$pid/environ file normally only contains the environment passed to the process when it was created. It does not reflect any changes to its environment the process may have made after it began execution. Furthermore, it simply exposes the portion of the stack of the process which contained the original env vars. If the process modifies those stack locations that will be reflected in the content of that procfs file. See, for example, https://unix.stackexchange.com/questions/302948/change-proc-pid-environ-after-process-start.
I would complain to the Ruby team since they shouldn't be stomping on the original env var stack locations.
I'm having issues trying to set the LED and buzzer using APDUs on an ACR122U (firmware version 2.1.5).
This command should set the Buzzer Output for Card Detection, but I always get an error response:
> FF 00 52 00 00
< 63 00
Also, when trying to use one of the examples from the official documentation (v 2.04), I don't get the expected behavior, and the wrong response code (should be 90 02):
> FF 00 40 50 04 05 05 03 01
< 90 03
Other commands, like reading the firmware version, work as expected:
> FF 00 48 00 00
< 41 43 52 31 32 32 55 32 31 35
Has anyone had the same issues before?
Buzzer Output for Card Detection
I have two older versions of this reader here that do not seem to have a buzzer. Both of these readers always return 63 00 for that command. I'm not quite sure why this command might fail on versions that do have a buzzer though. However, looking at diffferent versions of the ACR122U API documentation, this command was only added in later versions of the reader.
Bi-color LED and Buzzer Control
The status code that you receive will only reflect the current state of the LEDs after you set the final state of the LEDs at least once. E.g. to set the final state off:
FF 00 40 0C 04 00 00 00 00
I have one communication between terminal and chip on APDU, and I need to decode that communication.
It's something like this:
Terminal: 00 B6 02 00 06 00
Chip: 49 55 7B 2C 1F 30 57 35 63 7D 24 7B 60 21
Terminal:00 B5 03 0B 04 02 00
Chip:45 43 3C 3B 4A 31 51 35 53 4B 34 2C 30 21
From what I know, terminal is sending commands to smart card chip, and smart card chip is giving response.
So, I need to know what is their communication about. It has to do with EMV standards and APDU.
How can I decode it? What are the steps and rules?
The communication between chip and terminal is using APDUs. Command APDU and response APDU. Below will give you idea about the struct of messages. For detailed reading download the documents(those are called books in emv world) from here. Infact the below are copy paste from Book 3. Have a detailed look and come back if you need more information.
All data are in hex.
The command APDU has the below format.
[Class] [Instruction] [Parameter 1] [Parameter 2] [Length of command
Data] [Command]
[Length of maximum expected data response]
Response APDU has the format
[Data] [2 bytes status of APDU execution( See coding of Sw1 Sw2 below]
Coding of the Class Byte
The most significant nibble of the class byte indicates the type of command. 0' Inter-industry command, '8' Proprietary to this specification.
Instruction bytes define the funtions you wish to do. Coding of the
Instruction Byte is
I'm trying to teach myself assembly, and am using LLDB to debug. So far, so good, but I'm wondering whether there's a quick way to inspect the memory at an address stored in a register?
Of course, I can do
register read rbp
(for example), and then use the address via
memory read <address> ...
but really I'd like to use the register name directly in the arguments to the 'memory' command (possibly with an offset). That seems like a natural thing to want to do, but so far I haven't been able to find anything about this.
You can use
(lldb) x $eax
0x799be060: f0 e6 1c 01 04 00 00 00 88 23 04 00 98 23 04 00 .........#...#..
0x799be070: a8 23 04 00 b8 23 04 00 00 00 00 00 00 00 00 00 .#...#..........
To see the memory contents displayed as e.g. 4 floats, use
(lldb) x/4f $eax
0x799be060: 0.0000000000000000000000000000000000000288183643
0x799be064: 0.00000000000000000000000000000000000000000000560519386
0x799be068: 0.000000000000000000000000000000000000000380088195
0x799be06c: 0.000000000000000000000000000000000000000380110616
I am using dtruss on MacOS X 10.8.5 in an attempt to see the conversation between a running application and an SSL server it talks to. Unlike strace on Linux, I'm not seeing full strings of data in the output, like I would expect to find as the program does send and recv on the file descriptor.
How can I get dtruss to show me the data which the app is sending and receiving with the SSL server?
Before anyone tells me to proxy the connections to an SSL server I control, yes I know this trick, and no this particular app is too smart to fall for it.
dtruss is both an elegant example of a script written for DTrace and a demonstration of what DTrace can accomplish. However, although its similarity to truss or strace is deeply welcome on the relatively barren OS X, I suspect that dtruss was never intended to be a complete substitute for either.
In any case, your question is a bit ambiguous: I'm not sure whether you are concerned that the strings that you see are truncated or that you don't see any strings at all for sendto() or recvfrom() (the underlying interfaces revealed by DTrace). I'll address both.
Firstly, DTrace collects data in the kernel; user-land buffers are obtained with the D language's copyin() or copyinstr() before being recorded and transmitted back to the consumer --- typically the dtrace(1) command. DTrace requires that its kernel buffer size be known at compile-time and therefore imposes a limit on the otherwise unpredictable length of a string. This limit is 256 bytes by default; if you are seeing truncation then you could change the limit by adding, e.g.,
#pragma D option strsize=512
below dtruss's existing pragma.
Secondly, dtruss is hard-coded to know about the formatting requirements of a variety of system calls. You don't see any buffer interpretation for sendto() or recvfrom() in its output because they're not handled explicitly in the source. There's nothing to stop you finding somewhere suitable to add them but you could instead write your own script:
bash-3.2# cat sr.d
#pragma D option rawbytes
syscall::sendto:entry,
syscall::recvfrom:entry
/pid == $target/
{
self->bufp = arg1;
self->size = arg2;
}
syscall::sendto:return,
syscall::recvfrom:return
/pid == $target && self->bufp && self->size/
{
printf("%s():\n", probefunc);
tracemem(copyin(self->bufp, self->size), 64);
printf("\n");
self->bufp = self->size = NULL;
}
bash-3.2# dtrace -qs ./sr.d -p 16988
sendto():
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
0: 68 65 6c 6c 6f 00 00 00 00 00 00 00 00 00 00 00 hello...........
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20: 00 00 00 00 00 00 00 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 ................
^C
bash-3.2#
Note that, as for strings, we're obliged to provide a hard limit on tracemem()'s use of DTrace's data-recording buffer. If the limit is rarely approached then this has the irritating result that the output can be overwhelming and mostly redundant. If you know that you're looking for strings then you could simply use copyinstr() instead; if you have a more modern DTrace implementation than my OS X 10.6.8 then you may find that you can write
tracemem(copyin(self->bufp, self->size), 64, self->size);
where the second argument is still a hard limit on the number of bytes recorded but the number of bytes displayed is limited by the optional third argument.
Finally, note that the user-land address is recorded on entry to the system call but used only on exit. This is a common idiom that allows the system call to fault-in the data if necessary --- DTrace won't do so itself and will produce an error at run-time if asked to trace a non-resident address.