Feature request: SD block read/write hypervisor DOS trap calls

[lgblgblgb]

Probably something exists already like this? What I mean: a hypervisor DOS call, to read and write SD blocks, with all the works done, ie converting block level address to byte offset if not SDHC, doing the reset, in case of an error during the operation, etc. So: a "bullet-proof" block read/write implementation. I think, it's OK to leave to the caller to fill the SD sector buffer or copy its content (in case of read), just the operation itself, with input value of the sector number (always block level addressing even in case of non-SDHC case, when it's converted by HDOS), and output as the status (error/OK), the block data itself can be transferred in the usual place without copy, ie te SD sector buffer itself. According to my tests in my "ethernet-monitor" solution, it's not so much trivial at all, especially in case of write. Also, M65's fdisk utility can benefit from this, so it don't need to implement the algorithm to write/read block just using these calls. Moreover: it would be also nice, if kickstart would do the size test on boot, and any program just query the pre-stored value from the only test time at boot. Again, it can be useful for the fdisk utility too, and for other low-level access software as well, including my project, of course.

Surely, it's just my idea, that it can be a useful function. Since HDOS can read blocks from SDHC/non-SDHC too, and now write too (if I am right), it should have the corresponding routines to do that, so the task is only to provide these functions via hypervisor trap calls as well for the "user space".

[gardners]

Hello, I'll take a look at this as I fix some other SD card related bugs soon. Paul.

…

On 24 March 2018 at 05:20, LGB ***@***.***> wrote: Probably something exists already like this? What I mean: a hypervisor DOS call, to read and write SD blocks, with all the works done, ie converting block level address to byte offset if not SDHC, doing the reset, in case of an error during the operation, etc. So: a "bullet-proof" block read/write implementation. I think, it's OK to leave to the caller to fill the SD sector buffer or copy its content (in case of read), just the operation itself, with input value of the sector number (always block level addressing even in case of non-SDHC case, when it's converted by HDOS), and output as the status (error/OK), the block data itself can be transferred in the usual place without copy, ie te SD sector buffer itself. According to my tests in my "ethernet-monitor" solution, it's not so much trivial at all, especially in case of write. Also, M65's fdisk utility can benefit from this, so it don't need to implement the algorithm to write/read block just using these calls. Moreover: it would be also nice, if kickstart would do the size test on boot, and any program just query the pre-stored value from the only test time at boot. Again, it can be useful for the fdisk utility too, and for other low-level access software as well, including my project, of course. Surely, it's just my idea, that it can be a useful function. Since HDOS can read blocks from SDHC/non-SDHC too, and now write too (if I am right), it should have the corresponding routines to do that, so the task is only to provide these functions via hypervisor trap calls as well for the "user space". — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#58>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAonT5enmNZOrwiWY4u-uOMVMa1yBSswks5thUPpgaJpZM4S5Nx2> .

[rdpeake]

Not enough memory in hypervisor for these functions