Mailing List Archive

boot 32 or 64 kernel depending on cpu
Hello,

The attached l32or64.c implements a com32 module that boots two
different kernels with different initrds depending on whether the cpu
has long mode support or not.

I stumbled upon two problems while developing it with current git
version (last commit 595705ffad4f63cfeb84e9bb1243df03808c2fff).

The first was that syslinux_boot_linux didn't work for me. Both the
command line and initrd data was garbage. The code I was developing is
attached as l32or64_linux.c

The seconda was that com32/include/syslinux/boot.h declares
syslinux_run_kernel_image, but it isn't defined anywhere, so I went with
syslinux_run_command.

Regards,
Luciano Rocha

PS: not gpg-signed because syslinux@zytor.com thinks that's suspicious.

--
lfr
0/0
Re: boot 32 or 64 kernel depending on cpu [ In reply to ]
On Thu, Apr 26, 2007 at 08:38:04PM +0100, Luciano Miguel Ferreira Rocha wrote:
> PS: not gpg-signed because syslinux@zytor.com thinks that's suspicious.

Oops, force of habit, but this time it didn't go to the moderator (or he
was fast), so this is good news for me.

--
lfr
0/0

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.
Re: boot 32 or 64 kernel depending on cpu [ In reply to ]
Luciano Miguel Ferreira Rocha wrote:
>
> The first was that syslinux_boot_linux didn't work for me. Both the
> command line and initrd data was garbage. The code I was developing is
> attached as l32or64_linux.c
>

When you say garbage, are you talking about it being correct before
booting and then it being crap, or is it crap only after booting the kernel.

A lot of your code there is just plain wrong. I suggest using more of
the code from com32/modules/linux.c including the command-line parsing
and using initramfs_load_archive().

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.
Re: boot 32 or 64 kernel depending on cpu [ In reply to ]
On Thu, Apr 26, 2007 at 01:24:23PM -0700, H. Peter Anvin wrote:
> Luciano Miguel Ferreira Rocha wrote:
> >
> > The first was that syslinux_boot_linux didn't work for me. Both the
> > command line and initrd data was garbage. The code I was developing is
> > attached as l32or64_linux.c
> >
>
> When you say garbage, are you talking about it being correct before
> booting and then it being crap, or is it crap only after booting the kernel.

argv[0] is garbage when the com32 module starts.

The computed cmdline is OK, before booting the kernel, but when the
kernel is booting and prints the commandline it got it only prints
garbage.

I can't check initrd prior to booting the kernel, but the kernel
complains that it isn't initramfs (it is) and then "VFS: can't mount
root".

>
> A lot of your code there is just plain wrong. I suggest using more of
> the code from com32/modules/linux.c including the command-line parsing
> and using initramfs_load_archive().

Well, I based my code on linux.c. I used initramfs_load_archive in the
first versios, but as it didn't work I looked how it worked and used
that directly.

I don't link the command line parsing of linux.c. Mine works (well, it
prints the correct output), is smaller and IMHO cleaner.

But I'll try it tomorrow instead of mime. And just linux.c32, as it could
be unrelated to syslinux_boot_linux.

Do you think that borrowing 1K from the stack could cause problems?

--
lfr
0/0

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.
Re: boot 32 or 64 kernel depending on cpu [ In reply to ]
Luciano Miguel Ferreira Rocha wrote:
>
> I don't link the command line parsing of linux.c. Mine works (well, it
> prints the correct output), is smaller and IMHO cleaner.
>

Well, for one thing, you have "video=" instead of "vga=" (two different
options!) and your handling of suffixes is broken in two ways: a) you do
"toupper" but compare against lower-case characters, and you don't deal
with 64-bit suffixes, and risk boot failure as a result.

> But I'll try it tomorrow instead of mime. And just linux.c32, as it could
> be unrelated to syslinux_boot_linux.
>
> Do you think that borrowing 1K from the stack could cause problems?

Not really, if you did it correctly.

As far as argv[0] is concerned, that's supposed to be the name of the
c32 file itself.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.
Re: boot 32 or 64 kernel depending on cpu [ In reply to ]
On Thu, Apr 26, 2007 at 02:13:51PM -0700, H. Peter Anvin wrote:
> Luciano Miguel Ferreira Rocha wrote:
> >
> > I don't link the command line parsing of linux.c. Mine works (well, it
> > prints the correct output), is smaller and IMHO cleaner.
> >
>
> Well, for one thing, you have "video=" instead of "vga=" (two different
> options!)

You're right.

> and your handling of suffixes is broken in two ways: a) you do
> "toupper" but compare against lower-case characters,

You're also right. (I shouldn't code so late. ;)

> and you don't deal
> with 64-bit suffixes, and risk boot failure as a result.

Why should I? The prototype for syslinux_boot_linux declares mem_limit
as an uint32_t. So supporting t/p/e will only cause it to overflow. I
expect to get better results from stopping at GB than by overflowing.

Still, the argument parsing is broken as far as mem and vga are
concerned, but I didn't use them anyway and boot still fails. (Note that
I sent my debugged code. I'd test all cases before submitting a final code.)

> As far as argv[0] is concerned, that's supposed to be the name of the
> c32 file itself.

Supposed, yes, but it never did. Just garbage (and I do print the
arguments at the start of the module).

--
lfr
0/0

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.
Re: boot 32 or 64 kernel depending on cpu [ In reply to ]
Luciano Miguel Ferreira Rocha wrote:
>
> Why should I? The prototype for syslinux_boot_linux declares mem_limit
> as an uint32_t. So supporting t/p/e will only cause it to overflow. I
> expect to get better results from stopping at GB than by overflowing.
>

Overflowing is broken too, although I think linux.c32 might get that
wrong. The value should be truncated to 0xffffffff when it exceeds
4 GB. All other options are critically wrong.

> Still, the argument parsing is broken as far as mem and vga are
> concerned, but I didn't use them anyway and boot still fails. (Note that
> I sent my debugged code. I'd test all cases before submitting a final code.)
>
>> As far as argv[0] is concerned, that's supposed to be the name of the
>> c32 file itself.
>
> Supposed, yes, but it never did. Just garbage (and I do print the
> arguments at the start of the module).

I can believe that.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.
Re: boot 32 or 64 kernel depending on cpu [ In reply to ]
Luciano Miguel Ferreira Rocha wrote:
>
> Still, the argument parsing is broken as far as mem and vga are
> concerned, but I didn't use them anyway and boot still fails. (Note that
> I sent my debugged code. I'd test all cases before submitting a final code.)
>

That's always appreciated. If you find things that don't work, I
definitely would appreciate patches... my testing bandwidth is
definitely not what it should be, and is probably the biggest damper on
syslinux development speed.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.