Jumper T8SG V2 builds

Great Job Vlad ... I have to wait 1 full week before to receive my V2+

As I see no way of differentiating between different t8sg builds, should we go ahead and merge your changes to the upstream repository and create new targets for nightly builds?

I'm in favor. Still suggest a name change to t8sg_plus, but not a big deal.

Well, I also thought if we could modify deviation to rewrite bytes in the boot loader to correct identification in Jumpers, but any user interaction like "selecting your deviation device" when boot loader is a 256k one identifying as DEVO-7E would still require the display to work, as we cannot overwrite/modify the bootloader from DeviationUploader Any other ideas?

Without a unique identifier not much can be done. If Jumper will change the bootloader then we can support in the future.

Haven't looked at the bootloader at all. Would it be possible to modify by running special code on the tx? A dfu to be run one time?

hexfet wrote: Haven't looked at the bootloader at all. Would it be possible to modify by running special code on the tx? A dfu to be run one time?

I think it should be veryfeasible using a one time dfu, as dumping the bootloader is very simple and I don't expect write protection (see dump_bootloader.c), and libopencm3 has write flash routines. But what would indeed be a safe end user process for this?

I don't know how the walkera tool will react to a different ID...

Maybe I'll try this on the t8sg... Worst thing that could happen is hooking up the st link and reflashing the original bootloader.

But what keeps us from making deviationuploader the preferred flashing tool?

Have you had any bad experience with flashing devos? So far the only problems I see arising in this forum are filesystem related. Also, only a successful upload of our patching dfu would actually trigger bootloader patching within the device after a reset.

The bootloader patch would be pretty safe if every time the dfu runs it ensures it finishes with a valid bootloader installed. Even if it has to completely program the original bootloader due to some error. There'd still be a risk if there was some hard bit error that wasn't an issue before trying to write to the bootloader area. Definitely would want an st-link for doing the development

While a patched bootloader would be incompatible with Walkera dfuse, it's the Jumper owners who benefit from the patch so pointing them to deviationuploader might not be an issue. Walkera owners would have no reason to patch their bootloader and could keep using dfuse if desired.

However the people willing to patch their bootloader are probably people who would always burn the right firmware anyway. Maybe suggesting to Jumper to change the bootloaders would give the biggest benefit.

I only have a T8SG V2 Plus, and I just went straight for the deviationuploader when I updated mine to vlad's latest build. I'd be perfectly fine with only using the deviationuploader. I agree that the ideal would be for Jumper to update their bootloader, but I'd be perfectly happy with a deviationuploader-provided bootloader update.

hexfet wrote: However the people willing to patch their bootloader are probably people who would always burn the right firmware anyway. Maybe suggesting to Jumper to change the bootloaders would give the biggest benefit.

Reflashing the bootloader is done in other projects as well ( For example here ) so it should be pretty safe. Once we have the modified bootloader to be used for this purpose I'm sure jumper will go ahead and use it in future production batches as well, but so far there are probably >1000 devices out in the wild with the "old" bootloader.

Anyways, I suggest merging V2 plus and irange to master branch (thanks vlad for providing these early builds so quickly!), as well as publishing the deviation-uploader 0.9 as the suggested upload tool for now.