Re: DM42 License Statement
Posted: Mon Jun 04, 2018 8:08 am
Perhaps I'm missing something here but, how does one compile the DMCP?
Regards.
SwissMicros Calculator Forum
forum.swissmicros.com
https://forum.swissmicros.com/
DM42 License Statement
Page 4 of 9
Re: DM42 License Statement
Posted: Mon Jun 04, 2018 5:27 pm
Re: DM42 License Statement
Posted: Mon Jun 04, 2018 5:44 pm
I got both parts installed but what's the PGM part for? 
Re: DM42 License Statement
Posted: Mon Jun 04, 2018 6:04 pm
Hi akaTB,
Thanks a lot!
Maybe the makefile could use the PATH into that bin-folder
instead of searching system wide and fail?
Cheers!
Meino
Thanks a lot!
Maybe the makefile could use the PATH into that bin-folder
instead of searching system wide and fail?
Cheers!
Meino
Re: DM42 License Statement
Posted: Mon Jun 04, 2018 6:13 pm
It's in the README (not README.md).
For Linux:
At first you need a target compiler/cross compiler for that, generating ARM-Code (CoreM3),
since the heart of our beloved DM42 is a STM32-cpu
.Then follow the README/White Rabbit, Neo and take the RED PILL!
Type 'make' while following the steps described in the README and...VOILA!
There it is.
@Micheal: Is there a chance of checking that the compiled product is a valid firmware
before flashing it?
The command "file" on the two files in question gave here:
DM42PGM_flash.bin: Compiled PSI (v1) data
DM42PGM_qspi.bin: data
which looks a little "very strange" to me...
In comparison:
The same "file" command on the FORTH-firmware for my STM32F103C8T6 gave:
mecrisp-stellaris-stm32f103.bin: DOS executable (COM, 0x8C-variant)
which is different but also very strange...but I know, that this firmware works fine.
Cheers
Meino
Re: DM42 License Statement
Posted: Mon Jun 04, 2018 6:33 pm
Hi Michael,
from experimenting with the "Blue Pill"-board, which has a STM32F103C8T6 (which by no means is comparable
to the "power cookie" of the DM42...but at least it is an STM32 ARM processor, too), I know, that the STM32F103 is
nearly unbrickable as long as one dont plan exactly how to brick the chip. This is due to the bootloader being in the
ROM and therefore not alterable (as far as I know...).
How is the situation when it comes to the DM42?
When looking at the PCB then I see at least one UART and one SPI and some other contacts which looks like interfaces
like those.
When we will dive into the adventure of being a creative part of the "Great Family of DM42 owners"...how "risky" (not really
speaking of a risk here...its only my Denglisch/Genglish) will it be, to flash a modified firmware onto the DM42?
As with the STM32F103...is there a fall-back, a never shut door into summer, a """backdoor""" (only meant positively), to
recover from a bloody programming error one did while adding the "one plus ultra modification" to the firmware?
On my desk there is a soldering iron, an USB-to-serial adapter (3.3V/5V), two different STLINKv2-clones and if I flash the
according firmware to one of my STM32F10C8T6-boards I can add a "Black Magic Probe" to that.
No oscilloscope, though.
What is the safest way to test modifications of the firmware?
What ways out of lock-ups, endless loops and soft bricks are there?
Thanks a lot for any help in advance!
Cheers!
Meino
from experimenting with the "Blue Pill"-board, which has a STM32F103C8T6 (which by no means is comparable
to the "power cookie" of the DM42...but at least it is an STM32 ARM processor, too), I know, that the STM32F103 is
nearly unbrickable as long as one dont plan exactly how to brick the chip. This is due to the bootloader being in the
ROM and therefore not alterable (as far as I know...).
How is the situation when it comes to the DM42?
When looking at the PCB then I see at least one UART and one SPI and some other contacts which looks like interfaces
like those.
When we will dive into the adventure of being a creative part of the "Great Family of DM42 owners"...how "risky" (not really
speaking of a risk here...its only my Denglisch/Genglish) will it be, to flash a modified firmware onto the DM42?
As with the STM32F103...is there a fall-back, a never shut door into summer, a """backdoor""" (only meant positively), to
recover from a bloody programming error one did while adding the "one plus ultra modification"
to the firmware?On my desk there is a soldering iron, an USB-to-serial adapter (3.3V/5V), two different STLINKv2-clones and if I flash the
according firmware to one of my STM32F10C8T6-boards I can add a "Black Magic Probe" to that.
No oscilloscope, though.
What is the safest way to test modifications of the firmware?
What ways out of lock-ups, endless loops and soft bricks are there?
Thanks a lot for any help in advance!
Cheers!
Meino
Re: DM42 License Statement
Posted: Mon Jun 04, 2018 8:20 pm
I also noticed the same error when trying to build the project:
Code: Select all
...
arm-none-eabi-objcopy --only-section .qspi -O ihex build/DM42PGM.elf build/DM42PGM_qspi.hex
arm-none-eabi-objcopy --only-section .qspi -O binary build/DM42PGM.elf build/DM42PGM_qspi.bin
check_qspi_crc DM42PGM dm/qspi_crc.h || ( make clean && false )
/bin/sh: 1: check_qspi_crc: not found
...Makefile should be updated. Could one make a pull-request?
Re: DM42 License Statement
Posted: Mon Jun 04, 2018 8:54 pm
Studying the code I see that the source code for 100+ functions is not included. Instead such functions are called via hard-coded pointers pointing to addresses inside what seems to be a closed source library loaded at a fixed address in memory.
Can't see a way how this can be compatible with the statement: "[...] we will be releasing the full source code to be able to build your own DM42 firmware. All components of DM42 will be open-sourced" [bold is mine].
Regards.
Can't see a way how this can be compatible with the statement: "[...] we will be releasing the full source code to be able to build your own DM42 firmware. All components of DM42 will be open-sourced" [bold is mine].
Regards.
Re: DM42 License Statement
Posted: Mon Jun 04, 2018 8:59 pm
That's the same with the STM32L476. On the PCB there are two buttons, RESET and PGM. If PGM is pressed during pressing RESET, the bootloader kicks in the dm_tool can be used to flash it with a good firmware.
Nope, it's not broken, but RTFM my friend. In the readme it says:
Add GNU ARM toolchain and bin/ directory path to PATH.
The file check_qspi_crc is in the /bin/ directory and you need to put that directory in your PATH.
Re: DM42 License Statement
Posted: Mon Jun 04, 2018 9:12 pm
Many different licenses were used for the DM42 and some of the code can not be open sourced, not our decision.emece67 wrote: ↑Mon Jun 04, 2018 8:54 pmStudying the code I see that the source code for 100+ functions is not included. Instead such functions are called via hard-coded pointers pointing to addresses inside what seems to be a closed source library loaded at a fixed address in memory.
Can't see a way how this can be compatible with the statement: "[...] we will be releasing the full source code to be able to build your own DM42 firmware. All components of DM42 will be open-sourced" [bold is mine].
The 100+ functions are system functions which can be called from the loaded program.