Hacking SAMD Fusee Payload Launcher V2

[electronrancher]

Hey, if it's no trouble that'd be greatly appreciated!

Piece of cake - done!

You'll need a CR2032 battery - don't take it out of your garage door opener, I've already gotten two guys who used totally dead 5 year old batteries and couldn't get the thing working - one even complained that the LED's barely lit up. Both worked fine once they replaced the battery with a new one.

 

[Kioku]

Piece of cake - done!

You'll need a CR2032 battery - don't take it out of your garage door opener, I've already gotten two guys who used totally dead 5 year old batteries and couldn't get the thing working - one even complained that the LED's barely lit up. Both worked fine once they replaced the battery with a new one.

Good to know, will attempt to remember to pick some up tomorrow.

 

[electronrancher]

Sounds good, the great ship-o-matic says the arrival estimate is Friday or Saturday. We're getting a hurricane here in the SE USA so I'm just glad it's going out before we get rocked. Next weekend is probably going to be no mail. Or power. I'll have to solder my boards over a campfire in the rain

 

[Kioku]

Sounds good, the great ship-o-matic says the arrival estimate is Friday or Saturday. We're getting a hurricane here in the SE USA so I'm just glad it's going out before we get rocked. Next weekend is probably going to be no mail. Or power. I'll have to solder my boards over a campfire in the rain

Like the good ol days! Hope you and yours stay safe.

 

[electronrancher]

Like the good ol days! Hope you and yours stay safe.

Exactly! Like pioneers in the days of yore, building payload injectors out on the prairie.

 

[electronrancher]

Hey what do you guys think about a firmware that stores bin files on the virtual flash drive instead of dropping a UF2?

Seems it would make it easier to change payloads, as no recompilation would be needed.

It's just an idea for now, I'd need to discuss the mechanics with @mattytrog as it would involve hacking the bootloader but it might be a nice path forward.

 

[mattytrog]

Hey what do you guys think about a firmware that stores bin files on the virtual flash drive instead of dropping a UF2?

Seems it would make it easier to change payloads, as no recompilation would be needed.

It's just an idea for now, I'd need to discuss the mechanics with @mattytrog as it would involve hacking the bootloader but it might be a nice path forward.

Nice idea. But you are limited on storage.

Also, the UF2 standard doesn't allow you to add files or any file extra to what is on the drive. It's the image or nothing...

So, knowing this, solutions...

Rewrite the bootloader completely.

Make the UF2 with multiple payloads... Already done...

Make the UF2 launch payloads from SD card... Already done.

You can't just have the UF2 and add payload.bin to it. Believe me, I've tried. Got half way there with the itsy by using the Circuitpy bootloader as that has 2mb spi flash as well. I've tried with SD card attached via spi too.

 

[electronrancher]

Nice idea. But you are limited on storage.

Also, the UF2 standard doesn't allow you to add files or any file extra to what is on the drive. It's the image or nothing...

So, knowing this, solutions...

Rewrite the bootloader completely.

Make the UF2 with multiple payloads... Already done...

Make the UF2 launch payloads from SD card... Already done.

You can't just have the UF2 and add payload.bin to it. Believe me, I've tried. Got half way there with the itsy by using the Circuitpy bootloader as that has 2mb spi flash as well. I've tried with SD card attached via spi too.

Ahh, interesting. You don't think it would be possible to reserve the unused space in the flash and just write the bin file there directly? Save the total length of the bin somewhere handy.

Then the launcher software just blindly sends whatever is in flash from say 0x4000 to the length we stored before.

No?

 

[mattytrog]

Ahh, interesting. You don't think it would be possible to reserve the unused space in the flash and just write the bin file there directly? Save the total length of the bin somewhere handy.

Then the launcher software just blindly sends whatever is in flash from say 0x4000 to the length we stored before.

No?

You can in theory, but the launcher would need to convert it to a byte array first on the fly. So it would need to read every byte of a payload and store it, convert it byte-by-byte and send it. And this is assuming you can somehow reduce the UF2 in size as they are stuck at 512kb.

How would you write / buffer the payload to the flash? We can do it with jlinks / rasPi etc etc but how would an end user do it? The UF2 bootloader won`t allow anything but a 512kb UF2 on there. So you would need to push it from SD or from a SPI device... Which aren`t available as mass-storage, unless you mess aroud with the itsy / feather bootloader. In which case, Circuitpy sees the full size of the flash (2mb on itsy / feather)

 

[jammybudga777]

can someone tell me what all these dongles are about. i really dont get it

 

[mattytrog]

The switch has a buggy insecure bootloader.

Nutshell...

The dongles push the payloads (think of a bomb that can`t normally get into the system) into the buggy bootloader, the buggy bootloader runs this payload bypassing TZ (trustzone) - bit like Scamsung Knox.

The internal chip does the same thing, only is connects as a dongle from inside the console to the USB testpoints, fooling the switch into thinking it has a dongle attached.

 

[jammybudga777]

so the long and short it just helps load payloads like all the other dongles?

 

[mattytrog]

Yep.

But we have been playing with multiple payloads, storing multiple ones in the device (useful if you chop and change regularly etc etc)

A lot of this isn`t needed with Hekate now, but it is handy to have incase you need a backup or <insert reason> something

 

[mattytrog]

Piece of cake - done!

You'll need a CR2032 battery - don't take it out of your garage door opener, I've already gotten two guys who used totally dead 5 year old batteries and couldn't get the thing working - one even complained that the LED's barely lit up. Both worked fine once they replaced the battery with a new one.

There are loads of garage door openers on our neighbourhood estate. It isn`t coin batteries that end up missing. It`s normally mountain bikes, air compressors or power tools...

 

[electronrancher]

You can in theory, but the launcher would need to convert it to a byte array first on the fly. So it would need to read every byte of a payload and store it, convert it byte-by-byte and send it. And this is assuming you can somehow reduce the UF2 in size as they are stuck at 512kb.

How would you write / buffer the payload to the flash? We can do it with jlinks / rasPi etc etc but how would an end user do it? The UF2 bootloader won`t allow anything but a 512kb UF2 on there. So you would need to push it from SD or from a SPI device... Which aren`t available as mass-storage, unless you mess aroud with the itsy / feather bootloader. In which case, Circuitpy sees the full size of the flash (2mb on itsy / feather)

Now my recollection may be wrong, but isn't the actual payload send just a big buffered write from 0 to FUSEE_BIN_LENGTH?
I would say that could be replaced with a read from flash, just grab and stuff piece by piece.

I was actually considering trying to lz uncompress and stuff to USB buffer a while ago to try to fit more payloads in multi loader. There was a point in the fusee write that seemed like it could easily have other processing done in between read and write.

 

[mattytrog]

Now my recollection may be wrong, but isn't the actual payload send just a big buffered write from 0 to FUSEE_BIN_LENGTH?
I would say that could be replaced with a read from flash, just grab and stuff piece by piece.

Yes you can. And it works. But you aren`t gaining anything as you still need to bet the bin onto there in the first place. I am thinking of how an end-user would get the payloads into flash in the first place without building a hex / UF2 from the Ardudildo IDE.

The closest I have is modifying SXloader, hex edit 8 of them to look for different ".dats", convert desired payloads into dat and do it that way.

The best approach is just to do a basic launcher that passes everything to SD same as what TX have done. But for actually storing in the MCU flash, thats fine, just can`t change them on the fly.

 

[electronrancher]

Yes you can. And it works. But you aren`t gaining anything as you still need to bet the bin onto there in the first place. I am thinking of how an end-user would get the payloads into flash in the first place without building a hex / UF2 from the Ardudildo IDE.

The closest I have is modifying SXloader, hex edit 8 of them to look for different ".dats", convert desired payloads into dat and do it that way.

The best approach is just to do a basic launcher that passes everything to SD same as what TX have done. But for actually storing in the MCU flash, thats fine, just can`t change them on the fly.

I would say that the bootloader and application need to be merged. Double click goes into flash drive mode, and flash memory above 0x4000 or 0x8000 is used to hold the bin file.

Sure would be nice to have an SPI flash attached to give a little more space to the flash drive, but is it really needed? I dunno.

 

[mattytrog]

I would say that the bootloader and application need to be merged.

EXACTLY. Exactly this. This would be the best solution. And is very very doable.

But we come back to the same point... The end user... How would they update? They already only need to drag a UF2 over. How can we improve that? Dragging other stuff over?

Trinket (SAMD) is becoming de facto. Its OK us doing it, but what about the others?

I love the approach. It is ideal. I just wonder how it would sit with others

 

[electronrancher]

EXACTLY. Exactly this. This would be the best solution. And is very very doable.

But we come back to the same point... The end user... How would they update? They already only need to drag a UF2 over. How can we improve that? Dragging other stuff over?

Trinket (SAMD) is becoming de facto. Its OK us doing it, but what about the others?

I love the approach. It is ideal. I just wonder how it would sit with others

The laziest plan would be to abandon UF2 updating and just use the flash as a flash drive. I mean, fusee is not going to change for any devices that already exist so one could argue that future code changes are unlikely.

The fancier method would be to recognize that a UF2 was dropped, and flash it. Does the samdx1 bootloader do any kind of checking before it flashes? I'd better go look.

 

[mattytrog]

The laziest plan would be to abandon UF2 updating and just use the flash as a flash drive. I mean, fusee is not going to change for any devices that already exist so one could argue that future code changes are unlikely.

The fancier method would be to recognize that a UF2 was dropped, and flash it. Does the samdx1 bootloader do any kind of checking before it flashes? I'd better go look.

I couldn`t find anything on alternative bootloaders. Found UF2 only. Only thing is, it isn`t meant to be used as a flash drive.

The UF2 can reprogram the whole SAMD system IIRC. The flash is only emulated as a flash drive. It isn`t "emulating" UF2 if you like.

The circuitpy bootloader would be a good place to start. I just wonder if it is worth the effort. Wether the end justifies the means.