Uzebox Bootloader V5

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: New bootloader

Post by Jubatian »

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).
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: New bootloader

Post by uze6666 »

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.
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. :mrgreen:
User avatar
Janka
Posts: 214
Joined: Fri Sep 21, 2012 10:46 pm
Location: inside Out

Re: New bootloader

Post by Janka »

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.
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.

We could test it if you are interested. I could also send some to you.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: New bootloader

Post by Jubatian »

Janka wrote: Sat Mar 16, 2019 2:43 am
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.
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.

We could test it if you are interested. I could also send some to you.
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).
User avatar
Janka
Posts: 214
Joined: Fri Sep 21, 2012 10:46 pm
Location: inside Out

Re: New bootloader

Post by Janka »

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.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: New bootloader

Post by Jubatian »

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.
The new bootloader is capable to use either FAT16 or FAT32, so you shouldn't have any problem regarding the filesystem itself.

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).
User avatar
Janka
Posts: 214
Joined: Fri Sep 21, 2012 10:46 pm
Location: inside Out

Re: New bootloader

Post by Janka »

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.)
User avatar
Janka
Posts: 214
Joined: Fri Sep 21, 2012 10:46 pm
Location: inside Out

Re: New bootloader

Post by Janka »

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.

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
 
For your convenience, I also made a hex file. You can flash it with an ISP programmer and e.g. avrdude with

Code: Select all

$ avrdude -p m644 -v -U flash:w:Bootloader5-MMC.hex
Attachments
Bootloader5-MMC.hex
(11.13 KiB) Downloaded 395 times
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: New bootloader

Post by Jubatian »

Janka wrote: Fri Apr 26, 2019 3:18 pmFor those of you also interested in using their old MMC cards, I made a small patch to Jubatian's Game Loader v5.0.10.
Nice! I added a link to your comment to the top post, so people looking for the bootloader may find it!
User avatar
Janka
Posts: 214
Joined: Fri Sep 21, 2012 10:46 pm
Location: inside Out

Re: New bootloader

Post by Janka »

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?
Post Reply