search for: inregs

This patch will improve the flow at disk_write_sectors and disk_read_sectors significantly, but it *will* introduce bugs if either of the above functions gets called before disk_get_params. --- com32/include/syslinux/disk.h | 21 +++++ com32/lib/syslinux/disk.c | 170 +++++++++++++++++++++-------------------- 2 files changed, 108 insertions(+), 83 deletions(-) diff --git

Pulled common code out of these functions into new ones. The functions chs_setup and ebios_setup were created for this purpose. Signed-off-by: Raphael S.Carvalho <raphael.scarv at gmail.com> --- com32/include/syslinux/disk.h | 7 ++ com32/lib/syslinux/disk.c | 173 +++++++++++++++++++++-------------------- 2 files changed, 97 insertions(+), 83 deletions(-) diff --git

This patch will improve the flow at disk_write_sectors and disk_read_sectors. It does that by creating a table of values respective to the operation. Besides, read and write operations are pretty similar to each other, so I redesigned the routines to avoid duplication. Signed-off-by: Raphael S.Carvalho <raphael.scarv at gmail.com> --- com32/include/syslinux/disk.h | 18 ++++

Hi Peter Anvin I tried to use open file and read file SYSLINUX API. But it always make my PC104 freeze. My snip code : ================================================ int __start(void) { int ax,cx,dx,es,si,di,t; com32sys_t inreg,outreg; memset(&inreg, 0, sizeof inreg); memset(&outreg, 0, sizeof outreg); strcopy(__com32.cs_bounce, "test.txt"); inreg.eax.w[0] = 0x0006; //

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

Rework disk library to work on a firmware independent way. Each specific implementation goes through subdirs like "bios/" and "efi/" respectively. Signed-off-by: Paulo Alcantara <pcacjr at zytor.com> --- com32/include/syslinux/disk.h | 50 +++- com32/lib/Makefile | 2 + com32/lib/syslinux/disk.c | 583

Hi all, I've been discussing parameter attributes and their impact on first-class struct parameters. Duncan and I came to the conclusion that the only attribute that could be applied to structs currently, is the inreg attribute. However, since there is no support anywhere for that currently (transformation passes and backends?), it might be better to disallow the inreg attribute for struct

On Tue, Jul 8, 2008 at 2:28 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote: > Hi all, > > I've been discussing parameter attributes and their impact on first-class > struct parameters. Duncan and I came to the conclusion that the only attribute > that could be applied to structs currently, is the inreg attribute. However, > since there is no support anywhere for

eparam will only be used if EBIOS is available on the underlying disk. If not so, then there is no reason to allocate eparam. --- com32/lib/syslinux/disk.c | 13 +++++++------ 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/com32/lib/syslinux/disk.c b/com32/lib/syslinux/disk.c index 093751a..554bed3 100644 --- a/com32/lib/syslinux/disk.c +++ b/com32/lib/syslinux/disk.c @@ -73,7

eparam would only be used if EBIOS is available. If it is not, then there is no reason to allocate eparam. Signed-off-by: Raphael S.Carvalho <raphael.scarv at gmail.com> --- com32/lib/syslinux/disk.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/com32/lib/syslinux/disk.c b/com32/lib/syslinux/disk.c index 093751a..d96acbf 100644 ---

...ny later version; incorporated herein by reference. + * + * ----------------------------------------------------------------------- */ + +/* + * poweroff.c + * + * APM poweroff module + */ + +#include <stdio.h> +#include <string.h> +#include <com32.h> + +int main() +{ + com32sys_t inregs, outregs; + + memset(&inregs, 0, sizeof inregs); + + inregs.eax.l = 0x5300; /* APM Installation Check (00h) */ + inregs.ebx.l = 0; /* APM BIOS (0000h) */ + __intcall(0x15, &inregs, &outregs); + + if (outregs.eflags.l & EFLAGS_CF) { + printf("APM not present.\n"); + retur...

...a/com32/chain/utility.c b/com32/chain/utility.c index fb59551..b54e0cd 100644 --- a/com32/chain/utility.c +++ b/com32/chain/utility.c @@ -94,24 +94,30 @@ void lba2chs(disk_chs *dst, const struct disk_info *di, uint64_t lba, uint32_t m uint32_t get_file_lba(const char *filename) { com32sys_t inregs; - uint32_t lba; + uint32_t lba = 0; + int size = 65536; + char *buf; /* Start with clean registers */ memset(&inregs, 0, sizeof(com32sys_t)); + buf = lmalloc(size); + if (!buf) + return 0; + /* Put the filename in the bounce buffer */ - strlcpy(__com32.c...

Functions with __attribute__((fastcall)) pop their arguments and take up to two arguments in ecx and edx. Currently we represent them by just setting the x86_fastcallcc calling convention. The problem is that the ABI has some strange conventions on when a register is used or not. For example: void __attribute__((fastcall)) foo1(int y); will take 'y' in ecx, but struct S1 { int x; };

> On Mar 3, 2016, at 2:00 AM, Renato Golin <renato.golin at linaro.org> wrote: > > On 2 March 2016 at 20:03, John McCall <rjmccall at apple.com> wrote: >> We don’t need to. We don't use the intermediary convention’s rules for aggregates. >> The Swift rule for aggregate arguments is literally “if it’s too complex according to >> <foo>, pass it

Does the COMBOOT stuff with 2.04 work correctly with function calls? or does one need to write it as one huge function? If memory serves me correctly, there was some problem if hello.c was modified to include additional functions, in an earlier version. - Murali

Personally, I'd love to see a setup where instead of LLVM implementing each calling convention and ABI hack, we provide a means of actually describing this. Specifically, I'd love to see a design for how to specify in the IR which register(s) (if any register(s)) a particular value should be placed into. Don't get me wrong, I don't have any good ideas about how to do this, I'm

> On Mar 3, 2016, at 10:06 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 3 March 2016 at 17:36, John McCall <rjmccall at apple.com> wrote: >> I’m not sure of your point here. We don’t use the Swift CC to call C functions. >> It does not matter, at all, whether the frontend lowering of an aggregate under >> the Swift CC resembles the frontend

From: Raphael S. Carvalho <raphael.scarv at gmail.com> My commit 09f4ac33 broke 'com32/lib/syslinux/disk.c' __lowmem doesn't work for declarations outside the core. Using __lowmem outside the core wouldn't have the desired effect, then lmalloc must be used instead to store dapa into the correct section (".lowmem"). Reported-by: Dark Raven <drdarkraven at

...http://www.plop.at/en/bootmanager.html + */ + +#include <com32.h> +#include <stdlib.h> +#include <stdio.h> +#include <string.h> +#include <alloca.h> +#include <console.h> +#include <syslinux/boot.h> + +static bool plop_INT13h_check(void) +{ + com32sys_t inregs, outregs; + + /* Prepare the register set */ + memset(&inregs, 0, sizeof inregs); + + /* + * Check if PLoP already has booted a CDROM or USB drive by checking + * for the presence of the PLoP INT13h hook. + * + * The following assembly code (NASM) can detect the PLoP IN...

On Fri, 06 Sep, at 01:00:55AM, Raphael S.Carvalho wrote: > eparam will only be used if EBIOS is available on the underlying disk. > If not so, then there is no reason to allocate eparam. > --- > com32/lib/syslinux/disk.c | 13 +++++++------ > 1 files changed, 7 insertions(+), 6 deletions(-) > > diff --git a/com32/lib/syslinux/disk.c b/com32/lib/syslinux/disk.c > index