similar to: [PATCH 1/1] efi/x86_64: fix trivial compilation warning

Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux leaves long mode in kernel_jump assembly routine does not follow AMD64 specifications. More precisely: 1. After setting a new GADT, `cs` has to be refresh by doing a long jump, but it is not 2. Other segments have to be updated, but they are not 3. Disabling paging has to be done before disabling long mode, but the

On Fri, 11 Sep 2015 03:59:09 +0200 celelibi--- via Syslinux <syslinux at zytor.com> wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > Missing */ at the end of a comment. > > Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> Reviewed-by: Paulo Alcantara <pcacjr at zytor.com> Thanks, Paulo > --- > efi/x86_64/linux.S | 2 +- >

On Tue, Aug 4, 2015 at 2:55 AM, Thomas Letan via Syslinux <syslinux at zytor.com> wrote: > Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux > leaves long mode in kernel_jump assembly routine does not follow AMD64 > specifications. More precisely: > 1. After setting a new GADT, `cs` has to be refresh by doing a long > jump, but it is not > 2. Other

On Mon, 14 Sep 2015 05:50:56 +0200 celelibi--- via Syslinux <syslinux at zytor.com> wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > OBJ directory creation changed from a .PHONY target to a real target > used through an order-only dependency. > > A target depending on another target marked .PHONY is always rebuilt, > thus forcing all the .o files to

On Wed, 26 Aug 2015 05:54:04 +0200 celelibi--- via Syslinux <syslinux at zytor.com> wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > Some firmware implementations may need ExitBootServices to be called > twice. The second time with an updated memory map key. > > Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> > --- > efi/main.c |

From: Sylvain Gault <sylvain.gault at gmail.com> These few patches contain a few improvement about the Makefiles for EFI. Mainly, to rebuild the files when needed, and only when needed. The three shell scripts efi/{check,build,clean}-gnu-efi.sh disappeared and are now integrated as makefile recipes. You'll notice an argument ARFLAGS=rvU to the recursive make calls to gnu-efi. This is

From: Sylvain Gault <sylvain.gault at gmail.com> The command-line parsing used to return a pointer to a local array. The code used to work by chance, but now, gcc 5 is able to detect it and return a NULL pointer instead. The buffer is now marked static. This shouldn't be a problem as only one command line can be read at a time. Signed-off-by: Sylvain Gault <sylvain.gault at

From: Sylvain Gault <sylvain.gault at gmail.com> TL;DR: The section aligment in linker scripts messed-up the memory mapping needed for the compression / decompression to work. The bug with gcc 5 is not trivial, I'll do my best to explain it here. Basically, there are two memory mappings of the code. One in "virtual memory", and one in "load memory". The one in

From: Sylvain Gault <sylvain.gault at gmail.com> On some architecture, including my hardware, the function ExitBootServices may need to be called twice in order to successfully exit the boot services. As stated by the UEFI spec, the first call to ExitBootServices may perform a partial shutdown of the services. It seems that during this partial shutdown, the memory map can be modified, thus

From: Sylvain Gault <sylvain.gault at gmail.com> I found something suspicious while hunting another bug a while ago. The conditions for that bug to occur seems quite hard to meet, but it's still code quality improvement. See the commit message for details. Sylvain Gault (1): efi: Suspicious size reduction in emalloc efi/main.c | 4 +--- 1 file changed, 1 insertion(+), 3

From: Sylvain Gault <sylvain.gault at gmail.com> The assembly instruction lgdt take a segment limit that is one less than the actual size, so that base+limit points to the last byte. Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> --- efi/main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/efi/main.c b/efi/main.c index 94878f9..bdf9353 100644

On 10/12/15 21:04, celelibi--- via Syslinux wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > The behavior when running a "CONFIG" command line is to reload > ldlinux.c32 with the new file as argument. This call never return. > > In order to avoid stacking up the calls to start_ldlinux, this patch > introduce a setjmp/longjmp to return to the

From: Sylvain Gault <sylvain.gault at gmail.com> I don't know if I should merge those trivial warning fix into one commit. I can reformat it as requested. Those are a few warning fixes for the efi part. The code involved has mainly been introduced in recent commits. Sylvain Gault (3): efi: fix warnings about argument types efi: fix pointer-type mismatch assigment warning efi: fix

2014-02-13 4:04 UTC+01:00, Sylvain Gault <sylvain.gault at gmail.com>: > 2014-02-13 3:20 UTC+01:00, celelibi at gmail.com <celelibi at gmail.com>: >> From: Sylvain Gault <sylvain.gault at gmail.com> >> > > It looks like git-send-email messed the headers when changing the sender. > Actually this was correct. It's the git-send-email way to specify the

On Mon, Sep 14, 2015 at 05:50:56AM +0200, celelibi--- via Syslinux wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > OBJ directory creation changed from a .PHONY target to a real target > used through an order-only dependency. > > A target depending on another target marked .PHONY is always rebuilt, > thus forcing all the .o files to be rebuilt everytime.

Due to delayed allocation feature on XFS filesystems, a write is not guaranteed to flushed out to the underlying file system after crash or something else - so we need to make sure that ldlinux.sys is installed correctly in the mounted filesystem. Signed-off-by: Paulo Alcantara <pcacjr at zytor.com> --- extlinux/main.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/extlinux/main.c

From: Sylvain Gault <sylvain.gault at gmail.com> Hello there, I propose 2 patches that fix two possible stack overflows either when running a COM32 module or when loading a new config file. I didn't find a better way to do this than to use the infamous setjmp/longjmp functions to restore the stack to a previous state. This makes the logic a bit more complex, but the behavior is not

On Tue, Sep 01, 2015 at 11:40:14PM -0300, Raphael S Carvalho via Syslinux wrote: > On Tue, Sep 1, 2015 at 8:58 PM, Paulo Alcantara via Syslinux < > syslinux at zytor.com> wrote: > > > Hi, > > > > My name is Paulo Alcantara. I've been working on BIOS/UEFI firmware and > > file systems development for a long time already. For those does not > > know,

xfs_is_valid_magicnum is not actually a generic function that checks for magic numbers, instead it checks only for superblock's one. Signed-off-by: Paulo Alcantara <pcacjr at zytor.com> --- core/fs/xfs/xfs.c | 13 +++++-------- core/fs/xfs/xfs.h | 19 ++++++++++--------- 2 files changed, 15 insertions(+), 17 deletions(-) diff --git a/core/fs/xfs/xfs.c b/core/fs/xfs/xfs.c index

Op 2014-02-13 om 04:04 schreef Sylvain Gault: > 2014-02-13 3:20 UTC+01:00, celelibi at gmail.com <celelibi at gmail.com>: > > From: Sylvain Gault <sylvain.gault at gmail.com> > > > > It looks like git-send-email messed the headers when changing the sender. And there was no actual patch ( no unified diff output ) in that e-mail. Please rerun providing