Rockbox Development > Starting Development and Compiling
Sansa E200V2 Bootloader is broken in master
Bilgus:
Also we don't make new bootloaders often so could you test some of these patches with your builds?
https://gerrit.rockbox.org/r/c/rockbox/+/4948
https://gerrit.rockbox.org/r/c/rockbox/+/4949
I've tested them on clip+ and zip so should work there too I'd guess
bahus:
--- Quote from: Bilgus on March 30, 2024, 12:02:11 AM ---you have the device. IMO it makes the most sense for you to do a patch
--- End quote ---
Ok. I just don't see it as only bootloader related fix and I'm not the one who found the issue. Created change request: https://gerrit.rockbox.org/r/c/rockbox/+/5619
--- Quote from: Bilgus on March 30, 2024, 12:18:17 AM ---Also we don't make new bootloaders often so could you test some of these patches with your builds?
--- End quote ---
It works for me and adds around 100 bytes to thumb size (119676 without, 119759 with those patches)
Bilgus:
build them on top of his patchsets he isn't going to get upset
that said don't push it yet as he might have other plans with that wip patch..
amachronic:
Thanks for doing the USB fix bahus. I created patches to enable thumb for the e200v2 bootloader by default, since you confirmed it's working now. Also, we can get rid of the codepage handling completely with this: https://gerrit.rockbox.org/r/c/rockbox/+/5622, saves ~100 bytes off the compressed image vs. your changes to unicode.c.
With all the optimizations + removing logo, we need to remove at least one more thing to make it fit:
* Remove backtraces
* Turn off priority scheduling
* Make filesystem read-onlyI would rather keep backtraces unless we have no other choice since they're useful. I don't think priority scheduling is necessary since it only affects performance and not correctness, although there could be some small risk it makes USB a bit less reliable (but only at the initial connection -- transfers should still be stable). Out of the three, I think making the filesystem read-only could give the most gains based on the WIP patch I did; it's kind of a pain, but I'd like to have headroom so we don't have this problem again because of some minor code change somewhere.
Since it's just barely fitting now with SD boot + multiboot v1 enabled, I think we should merge everything and go with disabling backtraces to get things working again.
(btw I don't have plans for the WIP patchset. I just put it up so as not to lose the changes, obviously it needs a lot of rework to be mergeable.)
bahus:
--- Quote from: amachronic on March 30, 2024, 11:49:59 AM ---Also, we can get rid of the codepage handling completely
--- End quote ---
So it makes my changes in unicode.c unnecessary, doesn't it? Let me know when you are done with your changes so I could test them and do additional clean up.
--- Quote from: amachronic on March 30, 2024, 11:49:59 AM ---I'd like to have headroom so we don't have this problem again because of some minor code change somewhere.
--- End quote ---
Unless something useful is added (exFat support?) I don't think there is a need to build bootloader (it's multiboot in this case). So most likely it won't be about some minor code changes.
--- Quote from: amachronic on March 30, 2024, 11:49:59 AM ---I would rather keep backtraces.
--- End quote ---
I'd rather keep potentially useful for user functionality. There is not much going on in bootloader and it's either work or completely dead with no indications. Also backtraces are not present in current bootloader release so it's not something we removed from released functionality.
--- Quote from: amachronic on March 30, 2024, 11:49:59 AM ---we should merge everything and go with disabling backtraces to get things working again.
--- End quote ---
Yeah. I'm all in with this plan.
Offtopic: I also tested booting from GPT-partitioned card (5dc0e4e). It works!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version