search for: write_sector

Here is a partial patch that I'm using to illustrate a few questions that I have. Looking at the gpllib write_sectors (com32/gpllib/disk/write.c) it looks like the allocated size is wrong; size is in sectors so we should adjust the alloc/memcpy by size*SECTOR. Also, comparing core/diskio.c it looks like the registers aren't even setup right. In the patch below I put an #if 0 around the old code to demonstrat...

...printf("sector: %d error: %d\n", sector, disk_errno); //disk_errno is always zero here } printf("sector: %d wrote:%d\r", sector, err); } if (zero_buf) { free(zero_buf); } } When run, the error case is always executed, but disk_errno is always zero. If I switch to write_sectors() the call succeeds (returns the same number of sectors requested), but the disk is not written. I can't find any examples of using the disk write functions anywhere in the code. Any suggestions would be appreciated. Thanks, Robert Jordan

...ion and copy length should be SECTOR * size for sectors operation. Signed-off-by: Robert <luyao-c at 360.cn> diff --git a/com32/gpllib/disk/write.c b/com32/gpllib/disk/write.c index d183ade..3c9edff 100644 --- a/com32/gpllib/disk/write.c +++ b/com32/gpllib/disk/write.c @@ -40,7 +40,7 @@ int write_sectors(const struct driveinfo *drive_info, const unsigned int lba, void *buf; int rv = -1; - buf = lmalloc(size); + buf = lmalloc(SECTOR * size); if (!buf) return -1; @@ -48,7 +48,7 @@ int write_sectors(const struct driveinfo *drive_info, const unsigned int lba, if (!dapa)...

...quot;hide" option support patch: - The code which initialized the global variable "dapa" was lost in commit 81c203f2, therefore EBIOS access did not work properly. Fixed by removing the global variable completely and moving all bounce buffer handling into read_sector() and write_sector(). - write_sector() copied data to the bounce buffer, but then tried to use the pointer to the original buffer in BIOS calls. Signed-off-by: Sergey Vlasov <vsu at altlinux.ru> --- com32/modules/chain.c | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/c...

...sted" in past months / emails that perhaps it might need to (or should?) be reviewed altogether (maybe even improving it for BIOS too ;). In the meantime, perhaps some suggested patches (regarding other issues) might deserve some attention / not-so-low priority? Recent examples: _ com32: write_sectors fixes http://www.syslinux.org/archives/2015-August/023962.html _ efi: leaving long mode in kernel_jump routine http://www.syslinux.org/archives/2015-August/023911.html (Somewhat self-centered, but not so much: I would also like to see the initial patches from Patrick about the CLI and lss...

...s * SECTOR); + rv = sectors; - return sectors; +fail: + lfree(dapa); + lfree(buf); + return rv; } diff --git a/com32/gpllib/disk/write.c b/com32/gpllib/disk/write.c index 89e530d..d183ade 100644 --- a/com32/gpllib/disk/write.c +++ b/com32/gpllib/disk/write.c @@ -36,8 +36,17 @@ int write_sectors(const struct driveinfo *drive_info, const unsigned int lba, const void *data, const int size) { com32sys_t inreg, outreg; - struct ebios_dapa *dapa = __com32.cs_bounce; - void *buf = (char *)__com32.cs_bounce + size; + struct ebios_dapa *dapa; + void *buf; + int rv = -1;...

Updating myself again: On 07-08-15 16:03, Oscar Roozen wrote: > e466d24 still has an issue with png's in vesalinux causing crashes I can confirm this remaining crash is caused by the line "MENU BACKGROUND bootlogo.png". The original bootlogo.png is 640x480. Forcing the videomode with "MENU RESOLUTION 640 480" did not resolve the crashes, nor did resizing the png