Linux64 upload-reset appears to be a 32 bit binary

upload reset linux64 is there
https://github.com/rogerclarkmelbourne/ … ls/linux64

actually even if upload-reset is 32bits it should still run. however, there may be some dependencies
Arduino_STM32/tools/linux64> ldd upload-reset
linux-gate.so.1 (0xf76f6000)
libc.so.6 => /lib/libc.so.6 (0xf74fb000)
/lib/ld-linux.so.2 (0xf76f9000)


@ag123

The issue is not if upload-reset is in the linux64 directory. It is that the upload-reset is a 32 bit binary in a directory for 64 bit items of which all other binaries are in fact 64 bit binaries. If one wants to use a 32 bit binary then one can use the binaries in the linux directory which are 32 bit binaries. Why would a 32 bit binary be in both the 32 and 64 bit binaries? The purpose of a 64 bit directory is to have 64 bit binaries.

Regards,

John L. Males
Toronto, Ontario
Canada
01 June 2017 15:00 EDT

i think the 64 bits version is not yet compiled, hence, the 32 bit version is copied into the 64 bits directory
it should still work so long as the dependent 32 bit dynamic link libraries are available on the system.

alternatively you could compile it and put a copy in your local linux64 directory.
https://github.com/rogerclarkmelbourne/ … load-reset

i’ve just compiled it and uploaded it here
gcc -o upload-reset upload-reset.c

for the others who are using linux, do test it out as there is a chance those libc dynamic link libraries etc on your system are different.
however, dynamic linking allows it to work on any system with the appropriate dll versions and possibly prevent ‘hard fault’ with calls into the kernel.
do comment in this thread if it works for you or not

keypunch wrote:The issue is not if upload-reset is in the linux64 directory. It is that the upload-reset is a 32 bit binary in a directory for 64 bit items of which all other binaries are in fact 64 bit binaries. If one wants to use a 32 bit binary then one can use the binaries in the linux directory which are 32 bit binaries. Why would a 32 bit binary be in both the 32 and 64 bit binaries? The purpose of a 64 bit directory is to have 64 bit binaries.

Rick Kimball wrote:keypunch wrote:The issue is not if upload-reset is in the linux64 directory. It is that the upload-reset is a 32 bit binary in a directory for 64 bit items of which all other binaries are in fact 64 bit binaries. If one wants to use a 32 bit binary then one can use the binaries in the linux directory which are 32 bit binaries. Why would a 32 bit binary be in both the 32 and 64 bit binaries? The purpose of a 64 bit directory is to have 64 bit binaries.

for some reason that i don’t fully understand a fixed upload-reset seem to make thing ‘worse’
prior that with the ‘not working’ 32 bit upload-reset, i simply press reset
now with the fixed 64 bits upload-reset, the reset seemed goofy
it doesn’t seem to work with certain sketches installed

i.e. it probably has nothing to do with whether it is 32 bits or 64 bits upload-reset
rather the reset in the sketch itself doesn’t work all the time. it seemed to be dependent on the sketch installed on the device

@ ag123

The binary is 64 bit. it would seem to me best to static link binaries meant to accomodate ranges of distributions and distribution libraries that can change. In such situtaion of my own code that needs to span different distributions and releases that reduces variables related to dynamic libraries with different naming conventions and/or binary interfaces at the library level quite a bit.

If one does the “upload-reset /dev/maple” from the CLI outside the Arduino IDE what is the expected behaviour? For example is there any visual indications?

I have done both inside and outside the IDE. First outside the IDE. I asked the question above as there seems to be mixed behaviour.

Regards,

John L. Males
Toronto, Ontario
Canada
01 June 2017 12:41 EDT
01 June 2017 13:31 EDT Small, but important typo correction jlm

P.S. Opps prior posts today I mixed up stating EDT when was UTC. Sorry. jlm

i’d prefer not to do a static link as the interface between libc or several of the dynamic link libraries to the linux kernel is actually different between different kernel versions. doing a static link can cause it to abort / error out on every other platform the syscall interface is different i think there are quite a lot of changes between the v3 and v4 kernels. and static linking would cause a v4 binary to fail on v3 kernel or a v3 binary to fail on a v4 kernel etc.

while for dynamic linking, those are just symbols and so long as the correct version (normally simply a same or later version) of libc dll is found on the system, it would simply work. while libc deals with the interface between itself and the kernel which can be different on different systems

note that libc and the kernel has tight linkage and that libc and the kernel is normally build in a rather elaborate ‘sandboxing’ process so that it makes a particular libc works with a particular kernel and all other apps can be dynamically linked to the libc (normally on the major version). and those same apps would work on a different platform / distribution / kernel version as long as the same libc dll version is there
https://sourceware.org/glibc/wiki/Testing/Builds
——–
upload-reset sends a ‘DTR pulse’ on usb-serial and then send the text ‘1EAF’
http://docs.leaflabs.com/static.leaflab … 3-rev5-dfu
The IDE performs this reset automatically by performing a special sequence of changes on the USB serial port:
– Pulse DTR (high and then low, so that you’ve created a negative edge)
– Write “1EAF” in ASCII over the serial pipe.
This will cause Maple to reset. Only the first 4 bytes after a negative edge of DTR are checked for this command, so it’s important you actually create a negative edge, rather than just ensuring DTR is low.

hence running
>./upload-reset /dev/maple

in case you are looking for a solution, in the libmaple core:
https://github.com/rogerclarkmelbourne/ … l.cpp#L297
#ifdef SERIAL_USB
// Got the magic sequence -> reset, presumably into the bootloader.
// Return address is wait_reset, but we must set the thumb bit.
uintptr_t target = (uintptr_t)wait_reset | 0x1;
asm volatile("mov r0, %[stack_top] \n\t" // Reset stack
"mov sp, r0 \n\t"
"mov r0, #1 \n\t"
"mov r1, %[target_addr] \n\t"
"mov r2, %[cpsr] \n\t"

ag123,

I will pass on the dynamic vs static linking as you know my reasons and I know why vendors static link code.

I asked what to expect when doing an “upload-reset /dev/maple” from the CLI outside the Arduino IDE because I had mixed behaviour.

1) First time did this via CLI and LED went solid.
2) After pressing “reset” buttom on uC board no LED light.
3) Via Arduino post (2) not good and no LED.
4) After “reset” button on uC and usb power cycle IDE was not successful and is different problem in my opinion that needs new topic for that unique proble,

The upload-reset now works for linux64, but appears there are other issues beyond that will need a new topic.

Where does one find the source for upload-reset?

Regards,

John L. Males
Toronto, Ontario
Canada
01 June 2017 16:36/17:11

keypunch wrote:
Where does one find the source for upload-reset?