On Tue, Jun 30, 2015 at 4:29 PM, poma <pomidorabelisima at gmail.com> wrote:> "A real serial port that can reliably operate at 115200 8n1 may be > necessary." > > Gene, is there something special in "A real serial port" usage, compared to emulated?I should restate: A serial port that responds on BIOS IO port 3F8h that can reliably operate at 115200 8n1 may be necessary. A USB serial port that the BIOS doesn't bother setting up for IO port 3F8h is just random hardware. In order to utilize it, the serial port should not be utilized for normal use (mixing gets ugly) and a special build must be made by changing mk/devel.mk (although it's been a while). Lines 3 and 4 must be uncommented and line 5 must be commented out. Booting such a build may take a long time while data is pumped over the serial. Although perhaps not helpful in this case, I'd normally suggest a simpler config like the following: #syslinux.cfg-begin DEFAULT linux PROMPT 1 LABEL linux LINUX vmlinuz APPEND initrd=myinitrd.cgz my-options #syslinux.cfg-end The sole use such a simpler config could serve in this instance is to minimize the serial-debug data generated by a working build to compare against a broken build. -- -Gene
On 06/30/2015 01:52 PM, Gene Cumm via Syslinux wrote:> > I should restate: A serial port that responds on BIOS IO port 3F8h > that can reliably operate at 115200 8n1 may be necessary. A USB > serial port that the BIOS doesn't bother setting up for IO port 3F8h > is just random hardware. >A USB serial port looks completely different from a UART serial port, so that is not really an option. -hpa
On 30.06.2015 22:52, Gene Cumm wrote:> On Tue, Jun 30, 2015 at 4:29 PM, poma <pomidorabelisima at gmail.com> wrote: > >> "A real serial port that can reliably operate at 115200 8n1 may be >> necessary." >> >> Gene, is there something special in "A real serial port" usage, compared to emulated? > > I should restate: A serial port that responds on BIOS IO port 3F8h > that can reliably operate at 115200 8n1 may be necessary. A USB > serial port that the BIOS doesn't bother setting up for IO port 3F8h > is just random hardware. > > In order to utilize it, the serial port should not be utilized for > normal use (mixing gets ugly) and a special build must be made by > changing mk/devel.mk (although it's been a while). Lines 3 and 4 must > be uncommented and line 5 must be commented out. Booting such a build > may take a long time while data is pumped over the serial. >GCCWARN += -DDEBUG_MALLOC GCCWARN += -DDEBUG_PORT=0x3f8 -DCORE_DEBUG=1 These directives have made it unnecessary: - switch to 'isolinux-debug.bin' usage - engage "serial 0" within the 'isolinux.cfg' To put it another way, the effect is the same.> Although perhaps not helpful in this case, I'd normally suggest a > simpler config like the following: > > > #syslinux.cfg-begin > DEFAULT linux > PROMPT 1 > > LABEL linux > LINUX vmlinuz > APPEND initrd=myinitrd.cgz my-options > #syslinux.cfg-end > > > The sole use such a simpler config could serve in this instance is to > minimize the serial-debug data generated by a working build to compare > against a broken build. >
To remind you once again.
ISOLINUX >= 6.00 built with GCC >= 5.0.0 causes a broken boot.
This relates specifically to the use of the vesamenu.c32,
menu.c32 works without problemos.
This "code" is already in 6.03, therefore this is not a fix for it!
Revert "SYSAPPEND: Fix space stripping"
This reverts commit 3106dcd
http://repo.or.cz/w/syslinux.git/commit/3106dcd
Fixes broken boot via vesamenu.c32 for the current git - 5186539 2015-06-27
version 6.04 2015 built with gcc version 5.1.1
---
com32/elflink/ldlinux/readconfig.c | 2 +-
com32/menu/readconfig.c | 2 +-
core/sysappend.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/com32/elflink/ldlinux/readconfig.c
b/com32/elflink/ldlinux/readconfig.c
index 381b43f..dcdf91b 100644
--- a/com32/elflink/ldlinux/readconfig.c
+++ b/com32/elflink/ldlinux/readconfig.c
@@ -330,7 +330,7 @@ static char *copy_sysappend_string(char *dst, const char
*src)
char c;
while ((c = *src++)) {
- if (c <= ' ' || c == '\x7f') {
+ if (c <= ' ' && c == '\x7f') {
if (!was_space)
*dst++ = '_';
was_space = true;
diff --git a/com32/menu/readconfig.c b/com32/menu/readconfig.c
index 257b042..b7814be 100644
--- a/com32/menu/readconfig.c
+++ b/com32/menu/readconfig.c
@@ -299,7 +299,7 @@ static char *copy_sysappend_string(char *dst, const char
*src)
char c;
while ((c = *src++)) {
- if (c <= ' ' || c == '\x7f') {
+ if (c <= ' ' && c == '\x7f') {
if (!was_space)
*dst++ = '_';
was_space = true;
diff --git a/core/sysappend.c b/core/sysappend.c
index 758703e..5c3f650 100644
--- a/core/sysappend.c
+++ b/core/sysappend.c
@@ -35,7 +35,7 @@ static char *copy_and_mangle(char *dst, const char *src)
char c;
while ((c = *src++)) {
- if (c <= ' ' || c == '\x7f') {
+ if (c <= ' ' && c == '\x7f') {
if (!was_space)
*dst++ = '_';
was_space = true;
--
2.4.5
On Tue, Jun 30, 2015 at 5:39 PM, H. Peter Anvin <hpa at zytor.com> wrote:> On 06/30/2015 01:52 PM, Gene Cumm via Syslinux wrote: >> >> I should restate: A serial port that responds on BIOS IO port 3F8h >> that can reliably operate at 115200 8n1 may be necessary. A USB >> serial port that the BIOS doesn't bother setting up for IO port 3F8h >> is just random hardware. >> > > A USB serial port looks completely different from a UART serial port, so > that is not really an option.I wasn't sure if it's possible (albeit a lot of work that probably hasn't been done/implemented by anyone) to have a BIOS use a USB serial adapter and emulate a traditional UART. -- -Gene