Hello,
A new version of the Gujin bootloader has been released, with those
improvements:
- fix the problem booting kernels after linux-2.6.22
- can also install the second stage inside a filesystem (contigous file, no RAID
supported) by:
"instboot boot.bin /boot/gujin.ebios"
and remove by:
Kenneth Howlett wrote:
> The loadlin boot loader fails to boot 2.6.23 kernels.
Maybe not a solution with loadlin, but is it working with the "tiny.exe"
version
of Gujin?
Download:
http://www.mirrorservice.org/sites/download.sourceforge.net/pub/sourceforge/g/gu/gujin/install-2.3.tar.gz/install/t
--- Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Note that Gujin has a simple problem by using that 32 bits entry point:
>
> There is really no 32bit entry point today usable for external users.
That is why I added the 16 bits entry point support (selected by default),
my target with Gujin was not
Eric W Biederman wrote:
> >> This is the classic skip the 16bit code and enter the kernel
> >> in 32bit mode filling in the fields that the 16bit mode code would
> >> have filled in the same way approach.
> > ..
> >
> > For in tree code it can be just updated. But weirdo-EFI-boot loader
> > can
--- Alan Cox <[EMAIL PROTECTED]> wrote:
> > I can reliably (6 times in one hour) freeze completely (Scroll lock/Caps
> > lock
> > flashing together, mouse frozen in X) my PC (AMD sempron on MSI K8MM3-V
> > K8M800
> > Socket 754) by doing an FTP using a standard modem connected on the serial
> >
--- Alan Cox <[EMAIL PROTECTED]> wrote:
> Can you get this to happen outside of X at all (eg if you do a yum update
> and pull in packages over the modem for a while with 2.6.23-rc1 does it
> die). Just trying to work out what has become unstable.
I'll try more stuff tonight. A wild guess of the
Hi,
A new version of the Gujin bootloader has been released, with those
improvements:
- Uses now by default the 16 bits entry point of bzImage Linux files (zImage not
supported) and do not uncompress the initrd, under the control of the "force
bzImage protocol" of the graphic menu, or the "/
Hi,
I can reliably (6 times in one hour) freeze completely (Scroll lock/Caps lock
flashing together, mouse frozen in X) my PC (AMD sempron on MSI K8MM3-V K8M800
Socket 754) by doing an FTP using a standard modem connected on the serial port
of the motherboard, and a bit of browsing (i.e. machine
--- "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> >> - The VGA recalc has the same bug as the assembly version where a VGA
> >> write protected register is written (Overflow register) without setting
> >> the enable bit (see VGA docs).
>
> I dug into this, and it turns out you're incorrect. Both
--- "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Etienne Lorrain wrote:
> > "mov %fs:(%ebx,%eax,4),%ecx" works for me.
>
> That's an example on what "m" can generate.
>
> "g" could produce stuff like:
>
>
--- "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> - Does not save and restore %ds when printing a char on the screen (%ds
> is
> destroyed only when the content of the screen scroll - only for some
> video cards)
> >> %ds? Aren't you confusing it with the old bug which woul
--- "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Chuck Ebbert wrote:
Wrong name.
> >> Have fun, this code:
> >> - do not open the fast A20 gate before checking if the slow A20 gate is
> >> open or
> closed.
>
> As does the current code; this is highly intentional behaviour since
> there ar
Andi wrote:
> The only thing questionable is that .code16gcc is arguably quite
> an abuse of gcc. I even checked with some gcc developers
> and they weren't too happy about it. e.g. it's not regression
> tested at all so we would be basically on our own with it.
On the other hand GCC just produc
On Thu, 12 Jul 2007, Linus Torvalds wrote:
> On Thu, 12 Jul 2007, Andrew Morton wrote:
> >
> > This code has been in -mm since 11 May, as git-newsetup.patch. It has
> > caused (for what it is) astonishingly few problems. Maybe a couple of
> > build glitches and one runtime failure, all quickly f
> This patch set replaces the x86 setup code, which is currently all in
> assembly, with a version written in C, using the ".code16gcc" feature
> of binutils (which has been present since at least 2001.)
".code16gcc" is useable since a bit earlier than that, in fact since:
http://sourceware.org/m
For me, adding the "local_irq_enable();" in default_idle() of
arch/i386/kernel/process.c
make the floppy work again without problem.
Etienne.
___
Découvrez une nouvelle façon d'obteni
> a. Can someone please confirm the described problem?
I can confirm that "mdir a:" without a floppy in the driver does not crash.
If there is a floppy, it crashes immediately (do "sync; sync" before to
limit file corruption). Tried with and without tickless, not related (no
change).
If loc
--- "Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> What I was thinking is that in the not we place the physical address
> and length that we load the real mode code at. My assumption being
> that we have marked the real mode code __init or the equivalent,
> so we always load and just ignore it l
--- "Eric W. Biederman" wrote:
> So I really don't care if we move whole real mode section into a note
> or if we just put a pointer to it into a note. What is important is
> that we use a note to find it.
Well, we can advertise by a note the section number or the section
name which contains the
Eric W. Biederman wrote:
> Etienne Lorrain writes:
> > Well, a self relocating image cannot be an ELF file because the code
> > to relocate the ELF cannot be executed at the wrong place.
> > If relocation is needed, I would better like not to link vmlinux at a
> > f
--- Vivek Goyal <[EMAIL PROTECTED]> wrote:
> No, as of today, kexec does not relocate vmlinux. At compilation time,
> vmlinux is compiled for a fixed address and vmlinux is loaded at that
> address. This compile address can be controlled with CONFIG_PHYSICAL_START,
> as you already mentioned in you
> > I assume you care about this ELF header because you are also a user of
> > the ELF file vmlinux, aren't you?
>
> Yes I am. I use kexec boot loader which has capability to load ELF kernel
> images (vmlinux). That's why I am concerned about linking real mode code
> in vmlinux as for kdump case I
Vivek Goyal wrote:
> > Etienne Lorrain wrote:
> > Yes, any PT_LOAD below 64 Kbytes can only be real mode, and real-mode
> > cannot be loaded higher, and cannot be bigger than 640 Kbytes, anything
> > different (like with virtual address at 0xC000) is Linux protected m
Vivek Goyal wrote:
>How do I know which program header is real mode code and the boot loader
> is not supposed to load it? May be PT_LOAD header with physical addr 0?
> What happens if changes happen and down the line we start compiling
> real mode code for non-zero address?
Yes, any PT_LOAD bel
Eric W. Biederman wote:
> H. Peter Anvin wrote:
> > That's not a valid comparison, because you're using 32-bit registers to hold
> > 16-bit pointers, and then sticking 67 prefixes on completely unnecessarily.
>
> Regardless if the size is good enough we can use it :)
>
> For romcc I had a 3x code b
H. Peter Anvin wrote:
> I've long wished that someone would do a proper 16-bit x86 port of gcc;
> however, the .code16gcc is usually good enough, although it produces
> code which is a lot bigger than it needs to be.
It is only that much bigger if you compare to 16 bits integer compilers,
b
Eric W. Biederman wrote:
> Etienne Lorrain <[EMAIL PROTECTED]> writes:
>> Well, if the function called at offset 0 in the real-mode section return
>> non zero, that is probably an error - that is Gujin interface, but do not
>> ask
>> me to change other boo
Eric W. Biederman wrote:
> Etienne Lorrain <[EMAIL PROTECTED]> writes:
> > New features are more that this real-mode function can return an error
> > to the bootloader to tell something to the user, so the user can select
> > another kernel with the right processor,
H. Peter Anvin
> Etienne Lorrain wrote:
> > Also there isn't any more kernel size limit.
>
> What kernel size limit?
Sorry - there isn't any limit for the kernel size, f
H. Peter Anvin wrote:
> Actually, as far as I can see, he has re-invented having a real-mode
> code chunk which then gets run before the protected-mode kernel. We
> already have that!
I did not claim to have invented anything there, this is just a quite
simple C code to execute instead of th
H. Peter Anvin, Vivek Goyal wrote:
>> Either way, though, putting Gujin-specific code in the main kernel
>> output is a pretty dull thud.
>
> Agreed.
May I ask if you are refering to the Gujin structures under the
ROOT_EXTENSIVE_SEARCH compilation switch, or the
C structures describing the BIOS
> Building real mode code with kernel binary (vmlinux) has got another
> disadvantage that it breaks using vmlinux for kdump purposes. One compiles
> the kernel binary to execute from a different address but real mode code/data
> will continue to be at virtual/physical addr 0 and kexec can not load
> First of all, if sending attached patches, *MAKE SURE* they're text/plain.
Sorry, next time I'll do.
> The standard way to do this is to have a command line argument named
> BOOT_IMAGE (as in BOOT_IMAGE=/foo/bar/baz). There is no reason to do
> this differently from every other bootloader.
The two standalone executable...
___
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des interna
Hello,
The Gujin bootloader (now at version 1.8) can natively load
compressed ELF files, and these three patches enable to generate
this "linux-2.6.20.kgz" file format.
Just as a remainder, to generate a bzImage file, those steps
are needed:
1- Compile the core kernel and link it into the ELF
This fourth patch is included in the subject line.
Have fun,
Etienne.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://ww
and the initial name of the kernel at GZIP
time (either "make /boot/kernel.kgz" or "make /kernel.kgz" with or
without a separate partition for /boot).
Signed-off-by: Etienne Lorrain <[EMAIL PROTECTED]>
diff -uprN -X linux-2.6.13/Documentation/dontdiff -x '*.orig'
function produce exactly the same memory mapping for real
mode parameters (file zero-page.txt), and is inserted at end of the ELF
vmlinux file by the linker.
There isn't any more a limit for the size of the uncompressed kernel.
Signed-off-by: Etienne Lorrain <[EMAIL PROTECTED]>
> > Do you see grub saying "uncompressing kernel..." or whatever that says?
>
> Grub says...
>
> root (hd2,2)
> Filesystem type is ext2fs, partition type 0x83
> kernel /boot/vmlinuz-2.6.12.4 root=/dev/md0 ro nodma
> [Linux-bzImage, setup=0x1e00, size=0x1302ff]
May I suggest to try a boot wit
> If I want to upgrade my IDE Hard drive by my self, how can I
> restore that kind of data on other diferent PC?
So the content of the HPA should be limited to program which are
special: a boot loader is position dependant and you do not want
to copy it blindly to another hard disk with maybe
>> Note that this HPA is a good place to store a bootloader too, in fact
>> I like to think of it as the big floppy drive of the PC which no more
>> have any floppy drive: create a FAT filesystem of 64 Mbytes there and
>> copy all the floppy you used to have there. Your bootloader, if it
>> is goo
> > > My question is now: why is an HPA disabled i.e. disprotected when
> > > detected? Why not let the HPA alone, because a certain set of disk
> > > sectors shall not be accessible by the OS?
> >
> > Because the HPA is most commonly used to hide all but a fraction of a
> > disk to work with older
> I'd like to have a discussion about FAT robustness.
> Please give your thought, comments and related issues.
What I would like is to treat completely differently writing to
FAT (writing to a removeable drive) which need a complete "mount",
and just reading quickly a file (a standard use of r
so that the x86_64 architecture will need some cleanning too,
but it will only be the third step.
Signed-off-by: Etienne Lorrain <[EMAIL PROTECTED]>
Have fun [you can check by yourself, it works],
Etienne.
patch-gujin-2613rc2.gz
Description: application/gzip-compressed
Just if you are interrested in Linux startup, you may have a look
at gujin/vmlinuz.[ch]:
Howto (with changelog at end):
http://sourceforge.net/docman/display_doc.php?docid=1989&group_id=15465
Download:
http://sourceforge.net/project/showfiles.php?group_id=15465&release_id=18235
Discussion For
Hello,
I have uploaded on:
http://sourceforge.net/projects/gujin/
a new version of my bootloader. It loads and analyse a vmlinuz
file (do not need LILO) selected by the user using a graphical
menu (up to 1600x1200 32 BPP) and a mouse (serial or PS2).
It find all possible vmlinuz* by scannin
46 matches
Mail list logo
