similar to: Syslinux 4.03-pre4 - Release Candidate

I am getting cc1: warnings being treated as errors strspn.c: In function 'strxspn': strspn.c:14:20: error: inlining failed in call to 'set_bit': optimizing for size and code size would grow strspn.c:32:9: error: called from here strspn.c:14:20: error: inlining failed in call to 'set_bit': optimizing for size and code size would grow strspn.c:36:9: error: called from here

Hi, For 6.xx: git://hasevolq.net/syslinux.git sys6 Michal Soltys (3): chain/partiter: call notsane_gpt_hdr() per header chain/partiter: add options to ignore GPT crc checks chain: year update in commments (trivial) Main addition here are separate options from 'strict' to ignore crc checks against gpt header and/or gpt partition list, so the user can force booting

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

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

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

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

> 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

I have just released SYSLINUX 2.09-pre4 with a few changes: a) SYSLINUX should now correctly handle mode changes from within a COMBOOT program. b) Tweaks to the menu system to avoid the "grey text on black" problem. c) A new color scheme for the menu system (Murali, check it out and see if you think it works for you.) ftp://ftp.kernel.org/pub/linux/utils/boot/syslinux/Testing/

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

Hello, the following patches should get multidisk access working. The syntax accepted is the following: (hdx,y)/path/to/file where x is the disk number and start at 0 and the y is the partition number starting at 1. So (hd0,1) is the first partition of the first disk. the other accepted syntax is using MBR's 32 bits disk signature so for example: (mbr:0x12345678,2)/foo/bar would address

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

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; //

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; };

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

Hi all, I have pushed out Syslinux 3.81-pre4, which is now a release candidate for 3.81. This version includes halt on idle, and so I'm very keen on getting this tested. -hpa

Hi all, I have pushed out a SYSLINUX 3.32-pre4. This version attempts to work around the "missing floppy drive" issue. If you have systems on which MEMDISK doesn't work without a floppy drive, I would appreciate it if you would test this out. -hpa

Yet another test release for the rewrite in progress. This version generalizes the definition of a boot sector, and puts the boot sector code into all the modules, so that a CD-ROM "boot sector" (like WinNT uses) and a PXE NBP should now all be possible to chainload. PLEASE test it out, pretty please... I haven't heard anything from anyone since at least 1.73-pre2.

hi i'm about to upgrade systems. yesterday i got https://www.zytor.com/pub/syslinux/Testing/6.04/syslinux-6.04-pre3.tar.xz in order to upgrade 6.04-pre1 version. i first was upgrading a usb-disk which was booting smootly with a simple configuration. i changed the EFI installation in /EFI/BOOT: efi64/efi/syslinux.efi (UEFI bootloader for EFI X64 (x86_64) firmware) ?

I have just pushed out SYSLINUX 3.36-pre4; the main difference is a rewritten MBR which can boot from logical partitions. I plan to eventually submit that to be added into (s)fdisk in util-linux. -hpa