similar to: Calling getoneblk() from com32

Hi Peter, Please pull the following changes. Paulo, I had to revert your "pxe: resolve names via DNS from protected-mode code" change because dns_resolv() is only implemented for PXELINUX and causes undefined symbol references for ISOLINUX, etc. Feel free to make the change again on top of the revert. The following changes since commit e7bd19def830e8341b1a100956345f1028740b9e:

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

Based on syslinux 6.03 Memory allocation 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

Hey guys, I can't seem to figure out how to debug a COM32 app with GDB under qemu. I start "qemu -s" and then "gdb hello.elf ; target remote:1234" but can't set any breakpoints that work. I"m using syslinux4 (pathbased from the repo). Can anyone verify that they can use qemu+com32+gdb with something as simple as com32/samples/hello.c32 ? Also, is it

I managed to get mini-xml (www.minixml.org<http://www.minixml.org>) working with the com32 API. I use it to read additional data needed by my comboot program but doesn't necessarily belong in the Syslinux config file. Maybe someone else can find a use for it as well. First you must extract mini-xml into the Syslinux tree: tar xfz syslinux-3.82.tar.gz tar xfz mxml-2.6.tar.gz mkdir -p

Hello, Would com32 modules be considered the same as an ordinary Linux executable with respect to LGPL? That is, as long as you released any changes to syslinux/com32 libs would you also have to release the source to the com32 module? Thanks for your time.

I'm seeing some sporadic build failures with 'make -j4'. The failures are: make[4]: *** No rule to make target 'hello.c32', needed by 'all'. Stop. I've only seen the failures with com32/samples/hello.c32 and com32/rosh/rosh.c32. I'm not a make expert, but I think it's due to missing dependencies. This patch seems to fix my failures, but I'm

Here is the initial release: git://github.com/donhiatt/Syslinux-EXT2FS-Library-port.git I am very new to git so I hope I managed to get the repo setup properly. The repo is branched from 'disklib' as I plan to use it for all disk read/write access (I'm currently using modified gpllib/disk/* -- see README). Cheers, don ----- README for ext2fs module. * Description -----------

Hello. Use <inttypes.h> PRIx64 instead of llx to get rid of gcc warning format ?%llx? expects type ?long long unsigned int?, but argument 2 has type ?uint64_t? -- MartinS diff --git a/com32/gpllib/acpi/xsdt.c b/com32/gpllib/acpi/xsdt.c index 208abc6..228b6c3 100644 --- a/com32/gpllib/acpi/xsdt.c +++ b/com32/gpllib/acpi/xsdt.c @@ -63,7 +63,7 @@ int parse_xsdt(s_acpi * acpi) /*

Background: Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture between AMD and Haiguang Information Technology Co.,Ltd., aims at providing high performance x86 processor for China server market. Its first generation processor codename is Dhyana, which originates from AMD technology and shares most of the architecture with AMD's family 17h, but with different

Hi, Gene Cumm wrote: > > 3) It feels like this is a moving target where gcc keeps changing and > > different results get reported. Do we have indications that different versions of gcc5 cause different behavior on the same build and boot machines ? Ady wrote: > Since the issue is only present on specific > hardware / firmware, whatever might seem to "solve" the

Hi, When testing syslinux on Hygon Dhyana processor, there are some information as follows: boot: cpuidtest.c32 Vendor = Unknown Vendor ... boot: ifcpu.c32 debug multicore multicore : 1 cores on this system After adding support for Hygon Dhyana processor, the info- rmation is correct: boot: cpuidtest.c32 Vendor = Hygon ... boot: ifcpu.c32 debug multicore multicore : 64 cores on this

The code was passing sizeof(char *) - not the length of the buffer - to strlcpy and snprintf. Change the function to take the length of the buffer as a parameter. Fixes the warning: argument to 'sizeof' in 'snprintf' call is the same expression as the destination; did you mean to provide an explicit length? Signed-off-by: Jonathan Boeing <jonathan.n.boeing at gmail.com>

Add detection code for "FreeDOS (eXtended FDisk)" MBR to disklib. Signed-off-by: Gert Hulselmans <gerth at zytor.com> --- com32/gpllib/disk/mbrs.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/com32/gpllib/disk/mbrs.c b/com32/gpllib/disk/mbrs.c index 37309e1..6150fcf 100644 --- a/com32/gpllib/disk/mbrs.c +++ b/com32/gpllib/disk/mbrs.c @@ -27,7 +27,6

Add detection code for "MS-DOS 3.30 through Windows 95 (A)" MBR to disklib. Signed-off-by: Gert Hulselmans <gerth at zytor.com> --- com32/gpllib/disk/mbrs.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/com32/gpllib/disk/mbrs.c b/com32/gpllib/disk/mbrs.c index 77e4180..37309e1 100644 --- a/com32/gpllib/disk/mbrs.c +++ b/com32/gpllib/disk/mbrs.c @@

The speed value is available since version 2.3 of the SMBIOS specification. Set the default speed string to "Unknown" for older versions. - Sebastian Index: syslinux-3.74-20-g3b80c26/com32/gpllib/dmi/dmi.c =================================================================== --- syslinux-3.74-20-g3b80c26.orig/com32/gpllib/dmi/dmi.c +++ syslinux-3.74-20-g3b80c26/com32/gpllib/dmi/dmi.c @@

Only call CPUID function 4 if cpuid_level indicates its availability. Signed-off-by: Sebastian Herbszt <herbszt at gmx.de> diff --git a/com32/gpllib/cpuid.c b/com32/gpllib/cpuid.c index fa21204..f33e895 100644 --- a/com32/gpllib/cpuid.c +++ b/com32/gpllib/cpuid.c @@ -232,8 +232,10 @@ void generic_identify(struct cpuinfo_x86 *c) } break; case X86_VENDOR_INTEL: - cpuid(0x4,

Hi, Matt Fleming wrote: > ld: libpng/pngrtran.o: warning: relocation against `png_do_read_filler' in readonly section `.text'. > ld: warning: creating a DT_TEXTREL in object. > > Looks like your files aren't position-independent. What does, > > file com32/gpllib/dmi/dmi.o > > say? # file com32/gpllib/dmi/dmi.o com32/gpllib/dmi/dmi.o: ELF 32-bit LSB

It has been observed that binaries contents are depending on the order of linked objects. This order is caused by GNU make's wildcard function and the position of sources on filesystem. This change tries to prevent this kind of randomness. Also consider building using -j1 flag to make it even more reproductible. Change-Id: Ie8eee7f336e6f1fa2863c4150d967afd15519f1d Bug:

From: Matt Fleming <matt.fleming at linux.intel.com> Move the MCONFIG files into a mk/ directory and give them more descriptive names. This is purely a cosmetic change to make the 'include' directives a bit more coherent by making it obvious exactly which MCONFIG file we're including. For example, in com32/lua/src/Makefile we exchange the line, include ../../MCONFIG for the