| Age | Commit message (Collapse) | Author |
|---|
|
This makes it work like --no-follow and --no-exclusive using a mutex group
and dest. Although the current implementation with BooleanOptionAction is
neater it requires Python 3.9, so don't use this feature.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
|
|
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
|
|
You can set one or the other (or neither) but not both.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
|
|
The --no-exclusive flag was accidentally added to the mutex group in
178198a01df51b5f4c5ef9f38ab2fb8f6269d5f4.
The --soft-reset flag was accidentally added to the mutex group in
41adf178309759d5965c15972f04987a2635314c.
These flags can be specified independently to --[no-]follow so should not
be in that mutex group.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
|
|
Leaves the default as-is, but allows using --no-soft-reset to disable the
soft reset when connecting.
|
|
Signed-off-by: Damien George <damien@micropython.org>
|
|
Signed-off-by: Damien George <damien@micropython.org>
|
|
This is now the default, but can be overridden with CLI `--no-exclusive`,
or constructing `Pyboard(..., exclusive=False)`.
Signed-off-by: Damien George <damien@micropython.org>
|
|
Signed-off-by: Brianna Laugher <brianna.laugher@gmail.com>
|
|
This commit adds support to pyboard.py for the new raw REPL paste mode.
Note that this new pyboard.py is fully backwards compatible with old
devices (it detects if the device supports the new raw REPL paste mode).
Signed-off-by: Damien George <damien@micropython.org>
|
|
Prior to this commit, pyboard.py used eval() to "parse" file data received
from the board. Using eval() on received data from a device is dangerous,
because a malicious device may inject arbitrary code execution on the PC
that is doing the operation.
Consider the following scenario:
Eve may write a malicious script to Bob's board in his absence. On return
Bob notices that something is wrong with the board, because it doesn't work
as expected anymore. He wants to read out boot.py (or any other file) to
see what is wrong. What he gets is a remote code execution on his PC.
Proof of concept:
Eve:
$ cat boot.py
_print = print
print = lambda *x, **y: _print("os.system('ls /; echo Pwned!')", end="\r\n\x04")
$ ./pyboard.py -f cp boot.py :
cp boot.py :boot.py
Bob:
$ ./pyboard.py -f cp :boot.py /tmp/foo
cp :boot.py /tmp/foo
bin chroot dev home lib32 media opt root sbin sys usr
boot config etc lib lib64 mnt proc run srv tmp var
Pwned!
There's also the possibility that the device is malfunctioning and sends
random and possibly dangerous data back to the PC, to be eval'd.
Fix this problem by using ast.literal_eval() to parse the received bytes,
instead of eval().
Signed-off-by: Michael Buesch <m@bues.ch>
|
|
|
|
Allow defaults for --device and --baudrate to be set in the environment
using PYBOARD_DEVICE and PYBOARD_BAUDRATE.
|
|
This is run with uncrustify 0.70.1, and black 19.10b0.
|
|
This script still works with Python 2 but Python 3 is recommended.
|
|
Python 2 does not have list.clear().
|
|
This option makes pyboard.py exit as soon as the script/command is
successfully sent to the device, ie it does not wait for any output. This
can help to avoid hangs if the board is being rebooted with --comman (for
example).
Example usage:
$ python3 ./tools/pyboard.py --device /dev/ttyUSB0 --no-follow \
--command 'import machine; machine.reset()'
|
|
This patch allows executing .mpy files (including native ones) directly on
a target, eg a board over a serial connection. So there's no need to copy
the file to its filesystem to test it.
For example:
$ mpy-cross foo.py
$ pyboard.py foo.mpy
|
|
Use "-f" to select filesystem mode, followed by the command to execute.
Optionally put ":" at the start of a filename to indicate that it's on the
remote device, if it would otherwise be ambiguous.
Examples:
$ pyboard.py -f ls
$ pyboard.py -f cat main.py
$ pyboard.py -f cp :main.py . # get from device
$ pyboard.py -f cp main.py : # put to device
$ pyboard.py -f rm main.py
|
|
Prior to this patch, when a lot of data was output by a running script
pyboard.py would try to capture all of this output into the "data"
variable, which would gradually slow down pyboard.py to the point where it
would have large CPU and memory usage (on the host) and potentially lose
data.
This patch fixes this problem by not accumulating the data in the case that
the data is not needed, which is when "data_consumer" is used.
|
|
|
|
Some Python linters don't like unconditional except clauses because they
catch SystemExit and KeyboardInterrupt, which usually is not the intended
behaviour.
|
|
Following standard practice for defining custom exceptions.
|
|
The Python documentation recommends to pass the command as a string when
using Popen(..., shell=True). This is because "sh -c <string>" is used to
execute the command and additional arguments after the command string are
passed to the shell itself (not the executing command).
https://docs.python.org/3.5/library/subprocess.html#subprocess.Popen
|
|
|
|
As it may contain newlines, etc.
|
|
|
|
|
|
When trying to execute a command via raw REPL and expected "OK" reply
not received, show what was received instead.
|
|
When working with a "virtual" port, like PTY. The issue described in
http://stackoverflow.com/questions/34831131/pyserial-does-not-play-well-with-virtual-port
|
|
Without this, Zephyr's port "make test" doesn't work.
|
|
This allows to execute a command and communicate with its stdin/stdout
via pipes ("exec") or with command-created pseudo-terminal ("execpty"),
to emulate serial access. Immediate usecase is controlling a QEMU process
which emulates board's serial via normal console, but it could be used
e.g. with helper binaries to access real board over other hadware
protocols, etc.
An example of device specification for these cases is:
--device exec:../zephyr/qemu.sh
--device execpty:../zephyr/qemu2.sh
Where qemu.sh contains long-long qemu startup line, or calls another
command. There's a special support in this patch for running the command
in a new terminal session, to support shell wrappers like that (without
new terminal session, only wrapper script would be terminated, but its
child processes would continue to run).
|
|
Some "device" implementations may be sensitive to this.
|
|
Previous to this patch pyboard.py would open a new serial connection to
the target for each script that was run, and for any command that was run.
Apart from being inefficient, this meant that the board was soft-reset
between scripts/commands, which precludes scripts from accessing variables
set in a previous one.
This patch changes the behaviour of pyboard.py so that the connection to
the target is created only once, and it's not reset between scripts or any
command that is sent with the -c option.
|
|
|
|
Also prints a nicer error message if the serial connection could not be
established.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The adapter class "TelnetToSerial" is used to access the Telnet
connection using the same API as with the serial connection. The
function pyboard.run-test() has been removed to made the module
generic and because this small test is no longer needed.
|
|
|
|
When looking for chars to indicate raw repl is active, look for the full
string of chars to improve reliability of entering raw repl correctly.
Previous to this patch there was the possibility that raw repl was
entered in a dirty state, where not all input chars from previous
invocation were drained.
|
|
|
|
In raw REPL ">" indicates the prompt. We originally read this character
upon entering the raw REPL, and after reading the last bit of the
output. This patch changes the logic so the ">" is read only just
before trying to send the next command. To make this work (and as an
added feature) the input buffer is now flushed upon entering raw REPL.
The main reason for this change is so that pyboard.py recognises the EOF
when sys.exit() is called on the pyboard. Ie, if you run pyboard.py
with a script that calls sys.exit(), then pyboard.py will exit after
the sys.exit() is called.
|
|
This allows pyboard.py to be used over a UART interface
rather than just over a USB serial interface.
|
|
|
|
Also flush stdout so you can see output as it comes.
|
