Hacking WIP [Trinket] [Rebug] [Others] SWITCHBOOT_UF2 / FUSEE_UF2 modchip software

MatinatorX

Hardware Developer
Developer
Joined
Jul 17, 2018
Messages
366
Trophies
1
Website
www.dragoninjector.com
XP
2,538
Country
Canada
@mattytrog Hey buddy, been a while since I poked my head in here, looking great!

Wanted to stop by to see if the recent work done for the DI might be useful for you as well. I'm not completely caught up on everything your firmware does, but I do see two things I think I can help with:

1) Flash storage of settings. I noticed you're using the FlashStorage library with the alternate EEPROM functions. While the EEPROM calls are a little more verbose than the default functions, it still doesn't do any wear leveling of any kind, and the SAMD21 flash area has a fairly low rated cycle count (min 25k, average 150k cycles). In addition, FlashStorage is a bit of a space hog, though with your 256kb of flash area compared to my 64kb, maybe that's not an issue for you. :P

To combat this I wrote (and optimized with the help of stuckpixel) a 16 "bin" wear-leveling algorithm for user settings. It works as such, with byte 1 of each bin indicating a full or empty bin:

Code:
READING VALUES:
1) Code checks last row page 4, if byte 1 is > 0 then it loads the values, if not then:
2) Code checks last row page 3, if byte 1 is > 0 then it loads the values, if not then:
3) ...
15) Code checks fourth last row page 2, if byte 1 is > 0 then it loads the values, if not then:
16) Code checks fourth last row page 1, if byte 1 is > 0 then it loads the values, if not then it sets default values.

WRITING VALUES:
1) Check fourth last row page 1, if byte 1 == 0 then write the values and set byte 1 > 0, if not then:
2) Check fourth last row page 2, if byte 1 == 0 then write the values and set byte 1 > 0, if not then:
3) ...
15) Check last row page 4, if byte 1 == 0 then write the values and set byte 1 > 0, if not then:
16) Erase last four rows, write the values and set byte 1 > 0 at fourth last row page 1.

This brings our rated cycle count up to min 400k, average 2.4M cycles, at the cost of the last 1kb of flash area. The code takes advantage of the fact we have row erase granularity but page write granularity with SAMD21. With SAMD21, each page is 64 bytes, so that's how much we have for data storage. It looks like you're currently using 41 bytes for data storage, and a lot of those uint32_t's look like they could be uint8_t's, so you would have lots of room for extra settings. ;)

Plus, since we're using defined memory locations, all your user settings will persist through both user code and bootloader updates, so long as your flash area has at least 1k of free space.

The source for it is here: https://github.com/dragoninjector-project/DragonInjector-Firmware/blob/master/main/main.ino

2) A CLI. I'm sure you're aware that the UF2 bootloader can emulate a USBSerial device and does so by default for BOSSA. However, I saw this as an opportunity for easier configuration of user settings and/or an easier way for apps to configure them. Rather than poking and prodding CURRENT.UF2 (which I don't think would work for FlashStorage anyways without a magic number) we can just talk plaintext. This potentially opens up the door for fancy Homebrew right on-console which can configure our modchips - I've been told support for USB Serial would be far easier to implement than FAT16 MSC. Pretty much everything already has it. Attached is an image of me configuring a DI with my phone, and Jerome is working hard on adding a nice configuration screen to the Windows app.

Source for the CLI: https://github.com/dragoninjector-project/DragonInjector-Bootloader/blob/master/src/sam_ba_monitor.c
Source for the Windows app: https://github.com/dragoninjector-project/DragonInjector-UpdateTool

Anyways, let me know what you think! :grog:

CONFIG.png Screenshot_20191108-130452.png
 
Last edited by MatinatorX,

BizkutPhilly

Banned!
Banned
Joined
Nov 8, 2019
Messages
5
Trophies
0
Age
37
XP
3
Country
United States
ok, i did a test:
flashed first: Trinket_Rebug_Both_Straps.uf2
than Trinket_Rebug_v091_Simple-UF2.UF2

vol+ d0
joy d3

weird behaviour: at first try i get hekate (i had no sd on the slot). with sd in the slot i get black screen
EDIT: plaing a bit with this conf i get same issues as before: auto cfw boot but no vol- and no flash

joy d0
vol+ d3

auto boot on cfw but still vol button problems (it rise up at max vol and i cannot use vol-). No flash connection.

if i remove vol+ and i put joy on d0 i get again flash connection (and of course at power on ofw boot, and with power+vol+ cfw boot)

i dunno if my chip is faulty or what...

same issue here
 

mattytrog

You don`t want to listen to anything I say.
OP
Member
Joined
Apr 27, 2018
Messages
3,708
Trophies
0
Age
48
XP
4,328
Country
United Kingdom
@mattytrog Hey buddy, been a while since I poked my head in here, looking great!

Wanted to stop by to see if the recent work done for the DI might be useful for you as well. I'm not completely caught up on everything your firmware does, but I do see two things I think I can help with:

1) Flash storage of settings. I noticed you're using the FlashStorage library with the alternate EEPROM functions. While the EEPROM calls are a little more verbose than the default functions, it still doesn't do any wear leveling of any kind, and the SAMD21 flash area has a fairly low rated cycle count (min 25k, average 150k cycles). In addition, FlashStorage is a bit of a space hog, though with your 256kb of flash area compared to my 64kb, maybe that's not an issue for you. :P

To combat this I wrote (and optimized with the help of stuckpixel) a 16 "bin" wear-leveling algorithm for user settings. It works as such, with byte 1 of each bin indicating a full or empty bin:

Code:
READING VALUES:
1) Code checks last row page 4, if byte 1 is > 0 then it loads the values, if not then:
2) Code checks last row page 3, if byte 1 is > 0 then it loads the values, if not then:
3) ...
15) Code checks fourth last row page 2, if byte 1 is > 0 then it loads the values, if not then:
16) Code checks fourth last row page 1, if byte 1 is > 0 then it loads the values, if not then it sets default values.

WRITING VALUES:
1) Check fourth last row page 1, if byte 1 == 0 then write the values and set byte 1 > 0, if not then:
2) Check fourth last row page 2, if byte 1 == 0 then write the values and set byte 1 > 0, if not then:
3) ...
15) Check last row page 4, if byte 1 == 0 then write the values and set byte 1 > 0, if not then:
16) Erase last four rows, write the values and set byte 1 > 0 at fourth last row page 1.

This brings our rated cycle count up to min 400k, average 2.4M cycles, at the cost of the last 1kb of flash area. The code takes advantage of the fact we have row erase granularity but page write granularity with SAMD21. With SAMD21, each page is 64 bytes, so that's how much we have for data storage. It looks like you're currently using 41 bytes for data storage, and a lot of those uint32_t's look like they could be uint8_t's, so you would have lots of room for extra settings. ;)

Plus, since we're using defined memory locations, all your user settings will persist through both user code and bootloader updates, so long as your flash area has at least 1k of free space.

The source for it is here: https://github.com/dragoninjector-project/DragonInjector-Firmware/blob/master/main/main.ino

2) A CLI. I'm sure you're aware that the UF2 bootloader can emulate a USBSerial device and does so by default for BOSSA. However, I saw this as an opportunity for easier configuration of user settings and/or an easier way for apps to configure them. Rather than poking and prodding CURRENT.UF2 (which I don't think would work for FlashStorage anyways without a magic number) we can just talk plaintext. This potentially opens up the door for fancy Homebrew right on-console which can configure our modchips - I've been told support for USB Serial would be far easier to implement than FAT16 MSC. Pretty much everything already has it. Attached is an image of me configuring a DI with my phone, and Jerome is working hard on adding a nice configuration screen to the Windows app.

Source for the CLI: https://github.com/dragoninjector-project/DragonInjector-Bootloader/blob/master/src/sam_ba_monitor.c
Source for the Windows app: https://github.com/dragoninjector-project/DragonInjector-UpdateTool

Anyways, let me know what you think! :grog:

View attachment 185564 View attachment 185565

Will take a look!

Switchboot is due for some updates. I`ve done some experiments with wear-levelling and I did build a kind-of implementation into the UF2 bootloader. But I faced a few issues. And couldn`t be arsed to work them out. And it was probably crap...

You can poke and prod flashstorage with CERTAIN functions - by no means all.

I`ll look at your implementation and see what we can implement this side. FlashStorage was a quick and dirty way of accomplishing what I needed to at the time.

I`ve been doing work on FatFS and mounting (with tweak) the OS partitions from within the modchip software, permitting things like proper emmc cleaning, decrypting changing / re-encrypting prodinfo, full resets etc etc. Also, limited testing of chips (BQ24193 etc) by using i2c command set to attempt to diagnose problems.
For the most part, its fully working. I just don`t trust myself to not open a can of worms with it. It is powerful and could irretrievably kill your console. In fact, in the wrong hands, it certainly will.

At Skegness at the moment for the Beach races, but will get on it later.

So, yep... Probably aim for a 2.0 release with some powerful functions. Just nerves getting the better of me.

Good work sir!

Matty
 
  • Like
Reactions: MatinatorX

mattytrog

You don`t want to listen to anything I say.
OP
Member
Joined
Apr 27, 2018
Messages
3,708
Trophies
0
Age
48
XP
4,328
Country
United Kingdom
@mattytrog Hey buddy, been a while since I poked my head in here, looking great!

Wanted to stop by to see if the recent work done for the DI might be useful for you as well. I'm not completely caught up on everything your firmware does, but I do see two things I think I can help with:

1) Flash storage of settings. I noticed you're using the FlashStorage library with the alternate EEPROM functions. While the EEPROM calls are a little more verbose than the default functions, it still doesn't do any wear leveling of any kind, and the SAMD21 flash area has a fairly low rated cycle count (min 25k, average 150k cycles). In addition, FlashStorage is a bit of a space hog, though with your 256kb of flash area compared to my 64kb, maybe that's not an issue for you. :P

To combat this I wrote (and optimized with the help of stuckpixel) a 16 "bin" wear-leveling algorithm for user settings. It works as such, with byte 1 of each bin indicating a full or empty bin:

Code:
READING VALUES:
1) Code checks last row page 4, if byte 1 is > 0 then it loads the values, if not then:
2) Code checks last row page 3, if byte 1 is > 0 then it loads the values, if not then:
3) ...
15) Code checks fourth last row page 2, if byte 1 is > 0 then it loads the values, if not then:
16) Code checks fourth last row page 1, if byte 1 is > 0 then it loads the values, if not then it sets default values.

WRITING VALUES:
1) Check fourth last row page 1, if byte 1 == 0 then write the values and set byte 1 > 0, if not then:
2) Check fourth last row page 2, if byte 1 == 0 then write the values and set byte 1 > 0, if not then:
3) ...
15) Check last row page 4, if byte 1 == 0 then write the values and set byte 1 > 0, if not then:
16) Erase last four rows, write the values and set byte 1 > 0 at fourth last row page 1.

This brings our rated cycle count up to min 400k, average 2.4M cycles, at the cost of the last 1kb of flash area. The code takes advantage of the fact we have row erase granularity but page write granularity with SAMD21. With SAMD21, each page is 64 bytes, so that's how much we have for data storage. It looks like you're currently using 41 bytes for data storage, and a lot of those uint32_t's look like they could be uint8_t's, so you would have lots of room for extra settings. ;)

Plus, since we're using defined memory locations, all your user settings will persist through both user code and bootloader updates, so long as your flash area has at least 1k of free space.

The source for it is here: https://github.com/dragoninjector-project/DragonInjector-Firmware/blob/master/main/main.ino

2) A CLI. I'm sure you're aware that the UF2 bootloader can emulate a USBSerial device and does so by default for BOSSA. However, I saw this as an opportunity for easier configuration of user settings and/or an easier way for apps to configure them. Rather than poking and prodding CURRENT.UF2 (which I don't think would work for FlashStorage anyways without a magic number) we can just talk plaintext. This potentially opens up the door for fancy Homebrew right on-console which can configure our modchips - I've been told support for USB Serial would be far easier to implement than FAT16 MSC. Pretty much everything already has it. Attached is an image of me configuring a DI with my phone, and Jerome is working hard on adding a nice configuration screen to the Windows app.

Source for the CLI: https://github.com/dragoninjector-project/DragonInjector-Bootloader/blob/master/src/sam_ba_monitor.c
Source for the Windows app: https://github.com/dragoninjector-project/DragonInjector-UpdateTool

Anyways, let me know what you think! :grog:

View attachment 185564 View attachment 185565
Implementing your wear-levelling code today ;)

Hiding the settings right at the end of the flash area, into a struct.
Commit the write just before a NVIC_SystemReset.

Working well. Cheers! ;)
 

Joseph111

Active Member
Newcomer
Joined
Oct 9, 2019
Messages
36
Trophies
0
Age
25
XP
114
Country
United Kingdom
Implementing your wear-levelling code today ;)

Hiding the settings right at the end of the flash area, into a struct.
Commit the write just before a NVIC_SystemReset.

Working well. Cheers! ;)
i got my thing working now, cheers btw and what is this? Does it do anything differently, sorry I don't understand all of what you and Matin spoke about.
 

mattytrog

You don`t want to listen to anything I say.
OP
Member
Joined
Apr 27, 2018
Messages
3,708
Trophies
0
Age
48
XP
4,328
Country
United Kingdom
i got my thing working now, cheers btw and what is this? Does it do anything differently, sorry I don't understand all of what you and Matin spoke about.
See below Joseph - may help you?

@Everybody
OK. Some new features of next "official" release... This won`t be a testing release like v1.5.1 was

  • Access UF2 bootloader with vol+ switch. No need to flex covers or hold stupid reed switches to your back case any more. Just a single (or double - haven`t decided yet) press.
  • Wear-levelling added to the firmware, to vastly enable more writes / rewrites. Thanks @MatinatorX!
  • Flat battery assistance - If battery is flat, Switchboot will stay running until battery is sufficiently charged to enable a full boot, rather than bootloop. This will assist perma-CFW / autoRCM users.
  • Auto-power-off if USB unplugged. It used to launch to Hekate / Switchboot screen and stay there(usb strap users only)
  • Bugfixes and obsolete libraries / functions removed. Started from scratch effectively...
  • More coming. But VERY VERY busy with consoles, so a little is getting done every night.

So may be a day or two before its ready
 
Last edited by mattytrog,
  • Like
Reactions: MatinatorX

Joseph111

Active Member
Newcomer
Joined
Oct 9, 2019
Messages
36
Trophies
0
Age
25
XP
114
Country
United Kingdom
See below Joseph - may help you?

@Everybody
OK. Some new features of next "official" release... This won`t be a testing release like v1.5.1 was

  • Access UF2 bootloader with vol+ switch. No need to flex covers or hold stupid reed switches to your back case any more. Just a single (or double - haven`t decided yet) press.
  • Wear-levelling added to the firmware, to vastly enable more writes / rewrites. Thanks @MatinatorX!
  • Flat battery assistance - If battery is flat, Switchboot will stay running until battery is sufficiently charged to enable a full boot, rather than bootloop. This will assist perma-CFW / autoRCM users.
  • Auto-power-off if USB unplugged. It used to launch to Hekate / Switchboot screen and stay there(usb strap users only)
  • Bugfixes and obsolete libraries / functions removed. Started from scratch effectively...
  • More coming. But VERY VERY busy with consoles, so a little is getting done every night.

So may be a day or two before its ready

Access UF2 bootloader with vol+ switch. No need to flex covers or hold stupid reed switches to your back case any more

How does that work? Does Switch need to be turned on? I'm using Vol+ to launch into CFW why I ask. I understand the rest
 

mattytrog

You don`t want to listen to anything I say.
OP
Member
Joined
Apr 27, 2018
Messages
3,708
Trophies
0
Age
48
XP
4,328
Country
United Kingdom
Access UF2 bootloader with vol+ switch. No need to flex covers or hold stupid reed switches to your back case any more

How does that work? Does Switch need to be turned on? I'm using Vol+ to launch into CFW why I ask. I understand the rest
At any point when the Switch is powered on( or ideally you have sent the SAMD21_Update payload / selected the option in menu), hold vol+ for a second or two to bring up SWITCHBOOT.

We normally need to flex the back cover or hold a magnet (twice) to the back cover -(RCMX86 users).

I can now fit "hidden" chips, which live underneath the switch mainboard. If you look on my Youtube, you will see a video of a "modchip-less" console. (it isn`t really modchip-less, its underneath, fitted directly to the Switch PCB)
 
Last edited by mattytrog,

Joseph111

Active Member
Newcomer
Joined
Oct 9, 2019
Messages
36
Trophies
0
Age
25
XP
114
Country
United Kingdom
At any point when the Switch is powered on( or ideally you have sent the SAMD21_Update payload / selected the option in menu), hold vol+ for a second or two to bring up SWITCHBOOT.

We normally need to flex the back cover or hold a magnet (twice) to the back cover -(RCMX86 users)
oh that is actually cool. probably the best thing in the next update
 
  • Like
Reactions: mattytrog

mattytrog

You don`t want to listen to anything I say.
OP
Member
Joined
Apr 27, 2018
Messages
3,708
Trophies
0
Age
48
XP
4,328
Country
United Kingdom
oh that is actually cool. probably the best thing in the next update
Hekate upstream updates will be there too (once I have been through them).

This isn`t meant to be a rocketship or anything exciting. Its just a "modchip" after all. But time these loose ends were tied up :)
 
  • Like
Reactions: Joseph111

mattytrog

You don`t want to listen to anything I say.
OP
Member
Joined
Apr 27, 2018
Messages
3,708
Trophies
0
Age
48
XP
4,328
Country
United Kingdom
I put this on my standalone Gemma (used the gemma version) and it's looking for payload.bin. What do I put there? I tried putting nyx.bin and renaming it to payload... this just produces a black screen.
Fusee cannot launch nyx directly. It resides in a different area and is too big for the stack.

You need to load hekate first. You have gave me an idea though...

I may do a version of Fusee that launches nyx directly...
 

comat0se

New Member
Newbie
Joined
Oct 8, 2019
Messages
4
Trophies
0
Age
48
XP
92
Country
United States
Fusee cannot launch nyx directly. It resides in a different area and is too big for the stack.

You need to load hekate first. You have gave me an idea though...

I may do a version of Fusee that launches nyx directly...

Ok... but what do I put in there to launch hekate? I have the whole bootloader folder on the sdcard, but your file seems to be looking for payload.bin at the root. What do I use there?
 

mattytrog

You don`t want to listen to anything I say.
OP
Member
Joined
Apr 27, 2018
Messages
3,708
Trophies
0
Age
48
XP
4,328
Country
United Kingdom
Ok... but what do I put in there to launch hekate? I have the whole bootloader folder on the sdcard, but your file seems to be looking for payload.bin at the root. What do I use there?
Anything you like.

Hekate, or even if you have Kosmos on there, that should boot automatically.

Rename Hekate to payload.bin.
 

Prime420

Member
Newcomer
Joined
Mar 6, 2019
Messages
21
Trophies
0
Age
29
XP
186
Country
Germany
Had anyone fw 9.0.1 and atmosphere 0.9.4 installed? I had updated my atmosphere from 0.9.3 to 0.9.4 then i updated my emummc with choinx from 8.0.1 to 9.0.1. After a reboot i only get a black screen after the atmosphere logo, no error or something else. I cannot use switchboot 1.5, emummc and fw 9.0.1 together. With 8.0.1 it works like a charm.

When i does a fresh install on 8.0.1 with switchboot it works.
When i does a fresh install on 9.0.1 with switchboot it doesn't work.
When i does a fresh install on 9.0.1 with simpleuf2v3 and hekate 5.0.2 as payload it works.
 

mattytrog

You don`t want to listen to anything I say.
OP
Member
Joined
Apr 27, 2018
Messages
3,708
Trophies
0
Age
48
XP
4,328
Country
United Kingdom
Had anyone fw 9.0.1 and atmosphere 0.9.4 installed? I had updated my atmosphere from 0.9.3 to 0.9.4 then i updated my emummc with choinx from 8.0.1 to 9.0.1. After a reboot i only get a black screen after the atmosphere logo, no error or something else. I cannot use switchboot 1.5, emummc and fw 9.0.1 together. With 8.0.1 it works like a charm.

When i does a fresh install on 8.0.1 with switchboot it works.
When i does a fresh install on 9.0.1 with switchboot it doesn't work.
When i does a fresh install on 9.0.1 with simpleuf2v3 and hekate 5.0.2 as payload it works.
Hmmm... Working fine here.

Will investigate.
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    SylverReZ @ SylverReZ: If you want a good system to port it to, at least have a good programmer and knowledge.