Uzebox Bootloader V5
Re: New bootloader
I merged the change into Master, hopefully OK. I also updated the top post to match the current status, from now only the binary will be accessible there (as the source became part of the Uzebox master).
Re: New bootloader
Beautiful, I love the sound of it! I'm making a fresh batch of kits now, so I will use your new bootloader from now on.That "click" was a dirty hack, however I could discover a more elaborate dirty hack to get something milder in the same ROM space: https://github.com/Jubatian/uzebox/tree/boot5010
Check it out, if you agree that it is more pleasant, I will merge this.
Re: New bootloader
Yes, I do. I have a pile of old 16MB and 32MB MMC cards "Made in Japan" and "Made in Korea" from really old phones which aren't detected at all. They worked with the old boot loader v0.4.Jubatian wrote: ↑Sun Oct 15, 2017 8:18 am Does anyone experience situations when the old bootloader can detect and use a card while this new one can not? (I am still trying to go after what happens on ry775's hardware). An obvious thing could be ancient MMC cards which have no ACMD41 implemented, I am looking for anything beyond that.
We could test it if you are interested. I could also send some to you.
Re: New bootloader
It doesn't need any testing since the situation is clear in the software: it doesn't have the MMC initialization state machine implemented (so it can only bring up SDSC or SDHC). It simply needs too many instructions to fit in while the whole thing is already size-optimized to insanity and beyond, with only 8 bytes left at the moment. So to have MMC, some substantial feature likely has to be dropped, unless someone with more coding-fu than me came around and was capable to push size-optimizing the blasted thing even further (SDHC init and FAT32 are both quite substantial, an SDHC init is significantly more complex than an MMC init).Janka wrote: ↑Sat Mar 16, 2019 2:43 amYes, I do. I have a pile of old 16MB and 32MB MMC cards "Made in Japan" and "Made in Korea" from really old phones which aren't detected at all. They worked with the old boot loader v0.4.Jubatian wrote: ↑Sun Oct 15, 2017 8:18 am Does anyone experience situations when the old bootloader can detect and use a card while this new one can not? (I am still trying to go after what happens on ry775's hardware). An obvious thing could be ancient MMC cards which have no ACMD41 implemented, I am looking for anything beyond that.
We could test it if you are interested. I could also send some to you.
Re: New bootloader
I understand SDHC and FAT32 are more important to almost all people than MMC and FAT16. The old bootloader even had problems with most SDSC cards I could get my hands on. Those MMC cards came as a problem solver.
To avoid the size problem, I try to tackle it with alternative source code. It's just a modification for me then, and anyone who needs it.
To avoid the size problem, I try to tackle it with alternative source code. It's just a modification for me then, and anyone who needs it.
Re: New bootloader
The new bootloader is capable to use either FAT16 or FAT32, so you shouldn't have any problem regarding the filesystem itself.Janka wrote: ↑Sat Mar 16, 2019 3:53 pm I understand SDHC and FAT32 are more important to almost all people than MMC and FAT16. The old bootloader even had problems with most SDSC cards I could get my hands on. Those MMC cards came as a problem solver.
To avoid the size problem, I try to tackle it with alternative source code. It's just a modification for me then, and anyone who needs it.
I just recalled that there is also a third substantial feature: the support for fragmentation, which requires actually traversing the FAT (without it, you could just grab the start sector of the file and read it). So if you feel like you don't need that, it is possible to remove it, likely freeing up enough space to add the MMC init state machine.
If you decided to patch the bootloader for yourself, the stuff you need is in sdlib.s. There is also a Bootloader Interface Library, which allows games to use the bootloader's enhanced filesystem support, but providing a minimalist fallback for the case when the new bootloader is not installed, which is actually an MMC + FAT16 interface (the same like the old bootloader uses, so games using the library would work fine with any card the old bootloader could recognize). The source is bootlib.s in the kernel, implementing the exact same functions.
So in practice, you could actually just copy-paste most of bootlib.s into the new bootloader's sdlib.s, and you will have an MMC + FAT16 (no fragmentation support) bootloader, or you could attempt to build up any mix. The bootloader is entirely written in assembler, so it will compile and work just fine (there are no such pitfalls like with the old 0.4.5 bootloader).
Re: New bootloader
Thank you. I will try that in late April and give you feedback them. (I have to complete the Würgertime game first, there is a deadline.)
Re: New bootloader
For those of you also interested in using their old MMC cards, I made a small patch to Jubatian's Game Loader v5.0.10.
This patch removes SD/SDHC support in favor of MMC support. So it's not for everyone.
For your convenience, I also made a hex file. You can flash it with an ISP programmer and e.g. avrdude with
This patch removes SD/SDHC support in favor of MMC support. So it's not for everyone.
Code: Select all
diff --git a/demos/Bootloader5/sdlib.s b/demos/Bootloader5/sdlib.s
index 862a42e..2889bbe 100644
--- a/demos/Bootloader5/sdlib.s
+++ b/demos/Bootloader5/sdlib.s
@@ -418,6 +418,32 @@ SD_Init_CMD0l_e:
breq .+2
rjmp sdlib_ret_fl_02
+#define MMC
+#ifdef MMC
+ ; Try transitioning into Ready state 256 times at most (should be
+ ; between 0.5 - 1 sec at most)
+
+ ldi ZL, 0
+SD_Init_CMD1:
+
+ ; Send Command 1 to leave Idle state
+
+ ldi r24, 1 ; ACMD1
+ rcall sdlib_cl_r23_r20 ; Argument: 0x00000000
+ rcall SD_Init_CommRel
+ cpi r24, 0x01 ; R1 is Idle?
+ breq SD_Init_CMD1_m ; Wait some more
+ brcs SD_Init_CMD1_e ; R1 is Ready? (0x00)
+ rjmp sdlib_ret_fl_03
+SD_Init_CMD1_m:
+ dec ZL
+ brne SD_Init_CMD1
+ rjmp sdlib_ret_fl_04
+SD_Init_CMD1_e:
+
+ ldi r25, 0x01 ; Card initialized (bit 0) set
+ st X, r25
+#else
; Send interface condition to enter Verified state. Don't check result
; (have no much point, init will fail later if wrong, but command is
; necessary to allow ACMD41).
@@ -483,6 +509,7 @@ SD_Init_ACMDl_e:
sbrc r23, 6 ; OCR bit 30: If set, SDHC
ori r25, 0x02 ; SDHC
st X, r25
+#endif
; Done
Code: Select all
$ avrdude -p m644 -v -U flash:w:Bootloader5-MMC.hex
- Attachments
-
- Bootloader5-MMC.hex
- (11.13 KiB) Downloaded 398 times
Re: New bootloader
I wonder if we could include both code snippets into the bootloader. All what we have to do for that is checking the result of CMD8. If it's "illegal command", the MMC part should follow, otherwise the SD part.
But you wrote there are only a few bytes left. Maybe it's possible to squeeze the code at some other place?
But you wrote there are only a few bytes left. Maybe it's possible to squeeze the code at some other place?