This applies to 2.6.31 & 2.6.32 kernels for certain, but probably other newer kernels as well.
I'm a user of mkelfImage; I am currently unable to get an .ebi generated by mkelfImage to boot properly - I can't load it directly, or via a mechanism like kexec.
The moment the command (be it etherboot/gpxe, or kexec) tries to load the kernel, the system immediately reboots.
If I directly kexec a kernel (minus mkelfImage), the kernel loads correctly, so it appears the problem is in mkelfImage.
Unfortunately, I don't know how to fix it, and I _have_ to use mkelfImage to generate .ebi images for my systems.
I've tried 2.6.27, 2.6.31, 2.6.32; of those, 2.6.27 (and older kernels, work fine. 2.6.31 & 32 results in an .ebi that causes the system to reboot.
Any help!?
Thanks, Troy Telford
Troy Telford wrote:
Any help!?
2.6.30 introduced more sections in vmlinux that mkelfImage didn't deal with.
Yinghai sent a patch, which was committed to mkelfImage trunk. See if it works for you. svn://coreboot.org/coreboot/trunk/util/mkelfImage
http://www.coreboot.org/Mkelfimage
//Peter
On Saturday, May 15, 2010 03:57:52 pm Peter Stuge wrote:
Troy Telford wrote:
Any help!?
2.6.30 introduced more sections in vmlinux that mkelfImage didn't deal with.
Yinghai sent a patch, which was committed to mkelfImage trunk. See if it works for you. svn://coreboot.org/coreboot/trunk/util/mkelfImage
I'm aware of the patch; in fact, I was hoping that it would solve the problem.
I downloaded the svn tree, built mkelfImage, and then tested it.
Unfortunately, when I ran:
../mkelfImage vmlinuz-2.6.32.12-0.6-default --initrd=initrd-2.6.32.12-0.6- default newtest.ebi
and then kexec it, the system immediately reboots. So it seems that more needs to be done. I _wish_ I knew how to do it, but it's well above my current skill level.
On Saturday, May 15, 2010 04:26:03 pm you wrote:
On Saturday, May 15, 2010 03:57:52 pm Peter Stuge wrote:
Troy Telford wrote:
and then kexec it, the system immediately reboots.
Just a quick clarification: By "immediately reboots", I mean I'm sent back to the BIOS/POST screen, instead of the kernel loading.
The kernel initialization code as of boot protocol 2.10 is now reading the kernel_alignment field. With the field left the kernel attempts to align things to 4GB which is unlikely to work, so change the alignment to the kernels normal value of 16MB so newer kernels process by mkelfImage will boot.
Signed-off-by: "Eric W. Biederman" ebiederm@xmission.com
Index: mkelfImage-2.7/linux-i386/convert_params.c =================================================================== --- mkelfImage-2.7.orig/linux-i386/convert_params.c +++ mkelfImage-2.7/linux-i386/convert_params.c @@ -178,7 +178,10 @@ struct parameters { uint32_t cmd_line_ptr; /* 0x228 */ /* 2.03+ */ uint32_t initrd_addr_max; /* 0x22c */ - uint8_t reserved15[0x2d0 - 0x230]; /* 0x230 */ + /* 2.05+ */ + uint32_t kernel_alignment; /* 0x230 */ + uint8_t relocateable_kernel; /* 0x234 */ + uint8_t reserved15[0x2d0 - 0x235]; /* 0x235 */
struct e820entry e820_map[E820MAX]; /* 0x2d0 */ uint8_t reserved16[688]; /* 0x550 */ @@ -1503,6 +1506,9 @@ void initialize_linux_params(struct para /* No loader flags */ info->real_mode->loader_flags = 0; + + /* Set it to 16M instead of 4G */ + info->real_mode->kernel_alignment = 16*1024*1024; /* Ramdisk address and size ... */ info->real_mode->initrd_start = 0;
Awesome!
Acked-by: Stefan Reinauer stepan@coresystems.de
On 19.05.2010, at 13:42, ebiederm@xmission.com (Eric W. Biederman) wrote:
The kernel initialization code as of boot protocol 2.10 is now reading the kernel_alignment field. With the field left the kernel attempts to align things to 4GB which is unlikely to work, so change the alignment to the kernels normal value of 16MB so newer kernels process by mkelfImage will boot.
Signed-off-by: "Eric W. Biederman" ebiederm@xmission.com
Index: mkelfImage-2.7/linux-i386/convert_params.c
--- mkelfImage-2.7.orig/linux-i386/convert_params.c +++ mkelfImage-2.7/linux-i386/convert_params.c @@ -178,7 +178,10 @@ struct parameters { uint32_t cmd_line_ptr; /* 0x228 */ /* 2.03+ */ uint32_t initrd_addr_max; /* 0x22c */
- uint8_t reserved15[0x2d0 - 0x230]; /* 0x230 */
/* 2.05+ */
uint32_t kernel_alignment; /* 0x230 */
uint8_t relocateable_kernel; /* 0x234 */
uint8_t reserved15[0x2d0 - 0x235]; /* 0x235 */
struct e820entry e820_map[E820MAX]; /* 0x2d0 */ uint8_t reserved16[688]; /* 0x550 */
@@ -1503,6 +1506,9 @@ void initialize_linux_params(struct para
/* No loader flags */ info->real_mode->loader_flags = 0;
/* Set it to 16M instead of 4G */
info->real_mode->kernel_alignment = 16*1024*1024;
/* Ramdisk address and size ... */ info->real_mode->initrd_start = 0;
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Wednesday, May 19, 2010 05:42:36 am Eric W. Biederman wrote:
The kernel initialization code as of boot protocol 2.10 is now reading the kernel_alignment field. With the field left the kernel attempts to align things to 4GB which is unlikely to work, so change the alignment to the kernels normal value of 16MB so newer kernels process by mkelfImage will boot.
Signed-off-by: "Eric W. Biederman" ebiederm@xmission.com
I've applied the patch and built it. (Twice - once against svn, and once against 2.7.0. It doesn't seem to matter).
The change to work for any of the machines I'm trying it on (mostly the old HDAMA LinuxBIOS machines, but some newer hardware as well).
I'm creating the .ebi using the following: ./mkelfImage vmlinuz-2.6.32.12-0.6-default \ --initrd=initrd-2.6.32.12-0.6-default \ --command-line="console=tty0 console=ttyS0,115200 panic=60" test.ebi
and loading it using kexec as follows: ./kexec -l ./test.ebi ./kexec -e
The serial console returns the following: Starting new kernel Firmware type: LinuxBIOS Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.8.10Normal Thu Jul 28 09:16:27 MDT 2005 rebooting...
With similar results on a PCBIOS machine (ie. it reboots)
If I boot using Linux/PC BIOS and etherboot, the behavior is slightly different: Searching for server (DHCP)... ...Me: 10.0.1.1, Server: 10.0.10.1, Gateway 10.0.10.1 Loading x-slam://10.0.10.1:10006/239.192.0.131:10006 .....(ELF)... done Firmware type: LinuxBIOS
and: Searching for server (DHCP)... ...Me: 10.0.1.2, Server: 10.0.10.1, Gateway 10.0.10.1 Loading x-slam://10.0.10.1:10006/239.192.0.131:10006 .....(ELF)... done Firmware type: PCBIOS
And that's all that happens. It doesn't reboot, but there is nothing else returned, even with kernel verbosity cranked up to full, or waiting 20 minutes or so in case the serial console is disabled...
Troy Telford ttelford.groups@gmail.com writes:
On Wednesday, May 19, 2010 05:42:36 am Eric W. Biederman wrote:
The kernel initialization code as of boot protocol 2.10 is now reading the kernel_alignment field. With the field left the kernel attempts to align things to 4GB which is unlikely to work, so change the alignment to the kernels normal value of 16MB so newer kernels process by mkelfImage will boot.
Signed-off-by: "Eric W. Biederman" ebiederm@xmission.com
I've applied the patch and built it. (Twice - once against svn, and once against 2.7.0. It doesn't seem to matter).
The change to work for any of the machines I'm trying it on (mostly the old HDAMA LinuxBIOS machines, but some newer hardware as well).
Odd. That change was enough to get it to work in my testing. In the case that doesn't reboot now could you try adding an earlyprintk=ttyS0,115200 to your command line? With a little luck that will give you some output.
Eric
I'm creating the .ebi using the following: ./mkelfImage vmlinuz-2.6.32.12-0.6-default \ --initrd=initrd-2.6.32.12-0.6-default \ --command-line="console=tty0 console=ttyS0,115200 panic=60" test.ebi
and loading it using kexec as follows: ./kexec -l ./test.ebi ./kexec -e
The serial console returns the following: Starting new kernel Firmware type: LinuxBIOS Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.8.10Normal Thu Jul 28 09:16:27 MDT 2005 rebooting...
With similar results on a PCBIOS machine (ie. it reboots)
If I boot using Linux/PC BIOS and etherboot, the behavior is slightly different: Searching for server (DHCP)... ...Me: 10.0.1.1, Server: 10.0.10.1, Gateway 10.0.10.1 Loading x-slam://10.0.10.1:10006/239.192.0.131:10006 .....(ELF)... done Firmware type: LinuxBIOS
and: Searching for server (DHCP)... ...Me: 10.0.1.2, Server: 10.0.10.1, Gateway 10.0.10.1 Loading x-slam://10.0.10.1:10006/239.192.0.131:10006 .....(ELF)... done Firmware type: PCBIOS
And that's all that happens. It doesn't reboot, but there is nothing else returned, even with kernel verbosity cranked up to full, or waiting 20 minutes or so in case the serial console is disabled...
On Thursday, May 20, 2010 12:56:48 pm Eric W. Biederman wrote:
Troy Telford ttelford.groups@gmail.com writes:
On Wednesday, May 19, 2010 05:42:36 am Eric W. Biederman wrote:
The kernel initialization code as of boot protocol 2.10 is now reading the kernel_alignment field. With the field left the kernel attempts to align things to 4GB which is unlikely to work, so change the alignment to the kernels normal value of 16MB so newer kernels process by mkelfImage will boot.
Signed-off-by: "Eric W. Biederman" ebiederm@xmission.com
I've applied the patch and built it. (Twice - once against svn, and once against 2.7.0. It doesn't seem to matter).
The change to work for any of the machines I'm trying it on (mostly the old HDAMA LinuxBIOS machines, but some newer hardware as well).
Odd. That change was enough to get it to work in my testing. In the case that doesn't reboot now could you try adding an earlyprintk=ttyS0,115200 to your command line? With a little luck that will give you some output.
Lady luck rarely smiles upon me. This looks like this is no exception.
I modified the kernel command line to add the 'earlyprintk=<foo>' at the end of the command line, and the result is the same: - no output until the system rebooted (when using kexec) - no output at all (etherboot)
Troy Telford ttelford.groups@gmail.com writes:
On Thursday, May 20, 2010 12:56:48 pm Eric W. Biederman wrote:
Troy Telford ttelford.groups@gmail.com writes:
On Wednesday, May 19, 2010 05:42:36 am Eric W. Biederman wrote:
The kernel initialization code as of boot protocol 2.10 is now reading the kernel_alignment field. With the field left the kernel attempts to align things to 4GB which is unlikely to work, so change the alignment to the kernels normal value of 16MB so newer kernels process by mkelfImage will boot.
Signed-off-by: "Eric W. Biederman" ebiederm@xmission.com
I've applied the patch and built it. (Twice - once against svn, and once against 2.7.0. It doesn't seem to matter).
The change to work for any of the machines I'm trying it on (mostly the old HDAMA LinuxBIOS machines, but some newer hardware as well).
Odd. That change was enough to get it to work in my testing. In the case that doesn't reboot now could you try adding an earlyprintk=ttyS0,115200 to your command line? With a little luck that will give you some output.
Lady luck rarely smiles upon me. This looks like this is no exception.
I modified the kernel command line to add the 'earlyprintk=<foo>' at the end of the command line, and the result is the same:
- no output until the system rebooted (when using kexec)
- no output at all (etherboot)
Ugh.
I can think of two things that might be useful.
1) Add a print statement into mkelfImage that prints the value of kernel_alignment Most of the fields are already printed so this just requires tweaking linux-i386/convert_params.c
Where you still have a reboot in the kexec case I am a little curious if everything applied ok.
2) What needs to happen is to get a kernel instrumented up with a bunch of debug prints to see where it is failing. The attached linux-debug.S is a serial console print statement that I cut and past into early boot to get print statements before the normal print statement infrastructure initializes. I am posting this more as documentation than anything else.
There are some deep issues with mkelfimage that looks like they need to be fixed for it to survive long term. The current bug with kernel_alignment was caused by not initializing the kernel parameters like the normal kernel does. I think that needs to be fixed, but I'm not going to have time to look at that for a little while yet.
Eric
#if 1 /* Base Address */ #define TTYS0_BASE 0x3f8 /* Data */ #define TTYS0_RBR (TTYS0_BASE+0x00) #define TTYS0_TBR (TTYS0_BASE+0x00) /* Control */ #define TTYS0_IER (TTYS0_BASE+0x01) #define TTYS0_IIR (TTYS0_BASE+0x02) #define TTYS0_FCR (TTYS0_BASE+0x02) #define TTYS0_LCR (TTYS0_BASE+0x03) #define TTYS0_MCR (TTYS0_BASE+0x04)
#define TTYS0_DLL (TTYS0_BASE+0x00) #define TTYS0_DLM (TTYS0_BASE+0x01) /* Status */ #define TTYS0_LSR (TTYS0_BASE+0x05) #define TTYS0_MSR (TTYS0_BASE+0x06) #define TTYS0_SCR (TTYS0_BASE+0x07)
#define TTYS0_BAUD 9600 #define TTYS0_DIV (115200/TTYS0_BAUD) #define TTYS0_DIV_LO (TTYS0_DIV&0xFF) #define TTYS0_DIV_HI ((TTYS0_DIV >> 8)&0xFF)
#if ((115200%TTYS0_BAUD) != 0) #error Bad ttyS0 baud rate #endif
#define TTYS0_INIT \ /* disable interrupts */ \ movb $0x00, %al ; \ movw $TTYS0_IER, %dx ; \ outb %al, %dx ; \ ; \ /* enable fifos */ \ movb $0x01, %al ; \ movw $TTYS0_FCR, %dx ; \ outb %al, %dx ; \ ; \ /* Set Baud Rate Divisor to TTYS0_BAUD */ \ movw $TTYS0_LCR, %dx ; \ movb $0x83, %al ; \ outb %al, %dx ; \ ; \ movw $TTYS0_DLL, %dx ; \ movb $TTYS0_DIV_LO, %al ; \ outb %al, %dx ; \ ; \ movw $TTYS0_DLM, %dx ; \ movb $TTYS0_DIV_HI, %al ; \ outb %al, %dx ; \ ; \ movw $TTYS0_LCR, %dx ; \ movb $0x03, %al ; \ outb %al, %dx
/* uses: ax, dx */ #define TTYS0_TX_AL \ mov %al, %ah ; \ 9: mov $TTYS0_LSR, %dx ; \ inb %dx, %al ; \ test $0x20, %al ; \ je 9b ; \ mov $TTYS0_TBR, %dx ; \ mov %ah, %al ; \ outb %al, %dx
/* uses: ax, dx */ #define TTYS0_TX_CHAR(byte) \ mov byte, %al ; \ TTYS0_TX_AL
/* uses: eax, dx */ #define TTYS0_TX_HEX32(lword) \ mov lword, %eax ; \ shr $28, %eax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %eax ; \ shr $24, %eax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %eax ; \ shr $20, %eax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %eax ; \ shr $16, %eax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %eax ; \ shr $12, %eax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %eax ; \ shr $8, %eax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %eax ; \ shr $4, %eax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %eax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL
/* uses: rax, dx */ #define TTYS0_TX_HEX64(lword) \ mov lword, %rax ; \ shr $60, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %rax ; \ shr $56, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %rax ; \ shr $52, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %rax ; \ shr $48, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %rax ; \ shr $44, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %rax ; \ shr $40, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %rax ; \ shr $36, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %rax ; \ shr $32, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %rax ; \ shr $28, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %rax ; \ shr $24, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %rax ; \ shr $20, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %rax ; \ shr $16, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %rax ; \ shr $12, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %rax ; \ shr $8, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %rax ; \ shr $4, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL ; \ ; \ mov lword, %rax ; \ and $0x0f, %al ; \ add $'0', %al ; \ cmp $'9', %al ; \ jle 9f ; \ add $39, %al ; \ 9: ; \ TTYS0_TX_AL
#define DEBUG(x) TTYS0_TX_CHAR($x) ; TTYS0_TX_CHAR($'\r') ; TTYS0_TX_CHAR($'\n') #define DEBUG_TX_HEX32(x) TTYS0_TX_HEX32(x); TTYS0_TX_CHAR($'\r') ; TTYS0_TX_CHAR($'\n') #define DEBUG_TX_HEX64(x) TTYS0_TX_HEX64(x); TTYS0_TX_CHAR($'\r') ; TTYS0_TX_CHAR($'\n') #endif
#if 1 #include <linux/console.h> #include <asm/io.h>
static void ttys0_write(struct console *console, const char *str, unsigned len);
static struct console minimal_serial_console = { write: ttys0_write, flags: CON_ENABLED, next: NULL, };
/* Base Address */ #define TTYS0 0x3f8 /* Data */ #define TTYS0_RBR (TTYS0+0x00) #define TTYS0_TBR (TTYS0+0x00) /* Control */ #define TTYS0_IER (TTYS0+0x01) #define TTYS0_IIR (TTYS0+0x02) #define TTYS0_FCR (TTYS0+0x02) #define TTYS0_LCR (TTYS0+0x03) #define TTYS0_MCR (TTYS0+0x04)
#define TTYS0_DLL (TTYS0+0x00) #define TTYS0_DLM (TTYS0+0x01) /* Status */ #define TTYS0_LSR (TTYS0+0x05) #define TTYS0_MSR (TTYS0+0x06) #define TTYS0_SCR (TTYS0+0x07)
#define TTYS0_BAUD 115200 #define TTYS0_DIV (115200/TTYS0_BAUD)
static void ttys0_init(void) { /* disable interrupts */ outb(0x0, TTYS0_IER); /* enable fifo's */ outb(0x01, TTYS0_FCR); /* Set Baud Rate Divisor to TTYS0_BAUD */ outb(0x83, TTYS0_LCR); outb(TTYS0_DIV & 0xFF, TTYS0_DLL); outb((TTYS0_DIV >> 8) & 0xFF, TTYS0_DLM); outb(0x03, TTYS0_LCR);
} static void ttys0_tx_byte(unsigned byte) { while((inb(TTYS0_LSR) & 0x20) == 0) ; outb(byte, TTYS0_TBR); } static void ttys0_write(struct console *console, const char *str, unsigned len) { static int firsttime = 1; int c; if ((console->next) || (console_drivers != &minimal_serial_console)) return; if (firsttime) { firsttime = 0; ttys0_init(); } while(len--) { c = *str++; if (c == '\n') { ttys0_tx_byte('\r'); } ttys0_tx_byte(c); } }
#endif
#if 1 console_drivers = &minimal_serial_console; #endif xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx static void put_hex(unsigned long val) { static const char digit[] = "0123456789abcdef"; char buf[sizeof(val)*2 +1]; int i,j; for(j = 0, i = sizeof(val)*8 -4; i >= 0; i -= 4, j++) { buf[j] = digit[(val >> i) & 0xf]; } buf[j] = '\0'; puts(buf); } xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx #if 1 /* Base Address */ #define TTYS0 0x3f8 #define TTYS0_LSR (TTYS0+0x05) #define TTYS0_TBR (TTYS0+0x00)
static void serial_tx_byte(unsigned byte) { /* Wait until I can send a byte */ while((inb(TTYS0_LSR) & 0x20) == 0) ; outb(byte, TTYS0_TBR); /* Wait until the byte is transmitted */ while(!(inb(TTYS0_LSR) & 0x40)) ; } static void serial_puts(const char *str) { int c; while( ( c = *str++ ) != '\0') { if (c == '\n') { serial_tx_byte('\r'); } serial_tx_byte(c); } } #endif
static void puts(const char *s) { vid_puts(s); #if 1 serial_puts(s); #endif } xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx #if 1 /* Base Address */ #define TTYS0 0x3f8 #define TTYS0_LSR (TTYS0+0x05) #define TTYS0_TBR (TTYS0+0x00)
static void serial_tx_byte(unsigned byte) { /* Wait until I can send a byte */ while((inb(TTYS0_LSR) & 0x20) == 0) ; outb(byte, TTYS0_TBR); /* Wait until the byte is transmitted */ while(!(inb(TTYS0_LSR) & 0x40)) ; } static void serial_tx_hex(unsigned long val) { int i,j; for(j = 0, i = sizeof(val)*8 -4; i >= 0; i -= 4, j++) { unsigned digit; digit = ((val >> i) & 0xf) + '0'; if (digit > '9') digit += 39; serial_tx_byte(digit); } } static void serial_nl(void) { serial_tx_byte('\r'); serial_tx_byte('\n'); } static void debug(unsigned byte) { serial_tx_byte(byte); serial_nl(); }
static void debug_hex(unsigned byte, unsigned long val) { serial_tx_byte(byte); serial_tx_byte(' '); serial_tx_hex(val); serial_nl(); }
#endif
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
On Thursday, May 20, 2010 03:32:36 pm you wrote:
Ugh.
I can think of two things that might be useful.
Add a print statement into mkelfImage that prints the value of kernel_alignment Most of the fields are already printed so this just requires tweaking linux-i386/convert_params.c
Where you still have a reboot in the kexec case I am a little curious if everything applied ok.
I'm more curious, myself, at what happened in the past couple of hours to the hard drive... I've literally done __NOTHING__ to the binary generated, and nothing to the script I used (the script removes the old .ebi, uses mkelfImage to generate a new one, then kexecs it).
Three hours ago, it behaved exactly as I said. I moved on to an entirely different task, and decided to revisit it after your reply.
Now it is working, and its behavior is consistent between kexec and etherboot. I'm a bit WTF'd out about that... but I'll take the victory where I can get it.
That being said, the program that calls mkelfImage (which you knew as cwx), runs the following command: mkelfImage --command-line="some stuff here" --kernel=kernelBinary --ramdisk- base=20971520 --ramdisk=ramDiskPath --output=file
The .ebi files generated are the ones that are returning:
Loading x-slam://10.0.10.1:10006/239.192.0.131:10006 .....(ELF)... done Firmware type: LinuxBIOS
(and then does nothing)
And that appears to be due to the --ramdisk-base= argument. Simply increasing the size allows the kernel to start - but then fails as it can't load the ramdisk.
I'm a bit unclear on what --ramdisk-base actually does; so I'm willing to venture that it may be the source of our problem. I'll see what else I can figure out tomorrow. If you can enlighten me for the purpose of ramdisk-base, I'd appreciate it. (What an initrd load address is/means isn't something I know offhand). I'm going to look that up as well, but for now, I have to call it a night.
Troy Telford ttelford.groups@gmail.com writes:
On Thursday, May 20, 2010 03:32:36 pm you wrote:
Ugh.
I can think of two things that might be useful.
Add a print statement into mkelfImage that prints the value of kernel_alignment Most of the fields are already printed so this just requires tweaking linux-i386/convert_params.c
Where you still have a reboot in the kexec case I am a little curious if everything applied ok.
I'm more curious, myself, at what happened in the past couple of hours to the hard drive... I've literally done __NOTHING__ to the binary generated, and nothing to the script I used (the script removes the old .ebi, uses mkelfImage to generate a new one, then kexecs it).
Three hours ago, it behaved exactly as I said. I moved on to an entirely different task, and decided to revisit it after your reply.
Now it is working, and its behavior is consistent between kexec and etherboot. I'm a bit WTF'd out about that... but I'll take the victory where I can get it.
That being said, the program that calls mkelfImage (which you knew as cwx), runs the following command: mkelfImage --command-line="some stuff here" --kernel=kernelBinary --ramdisk- base=20971520 --ramdisk=ramDiskPath --output=file
The .ebi files generated are the ones that are returning:
Loading x-slam://10.0.10.1:10006/239.192.0.131:10006 .....(ELF)... done Firmware type: LinuxBIOS
(and then does nothing)
And that appears to be due to the --ramdisk-base= argument. Simply increasing the size allows the kernel to start - but then fails as it can't load the ramdisk.
I'm a bit unclear on what --ramdisk-base actually does; so I'm willing to venture that it may be the source of our problem. I'll see what else I can figure out tomorrow. If you can enlighten me for the purpose of ramdisk-base, I'd appreciate it. (What an initrd load address is/means isn't something I know offhand). I'm going to look that up as well, but for now, I have to call it a night.
ramdisk-base is just where in ram to load the ramdisk. mkelfImage defaults to 8M. You are setting it to 20M. With the change to kernels to default them to running at 16M that only leaves 4M for the kernel which I expect is to little. Because mkelfImage is old and the hack is crude I don't mkelfImage is to stupid to realize that we have a problem.
Eric
On May 20, 2010, at 6:48 PM, Eric W. Biederman wrote:
ramdisk-base is just where in ram to load the ramdisk. mkelfImage defaults to 8M. You are setting it to 20M. With the change to kernels to default them to running at 16M that only leaves 4M for the kernel which I expect is to little. Because mkelfImage is old and the hack is crude I don't mkelfImage is to stupid to realize that we have a problem.
20M is indeed to small. The ramdisk (incl. kernel modules) is on the order of 26M; I've tried setting it to 32M - this setting is what allows the kernel to actually start; however (as previously mentioned), the kernel is unable to mount the ramdisk. -- Troy Telford ttelford.groups@gmail.com
ramdisk-base is just where in ram to load the ramdisk. mkelfImage
defaults
to 8M. You are setting it to 20M. With the change to kernels to
default
them to running at 16M that only leaves 4M for the kernel which I expect
is
to little. Because mkelfImage is old and the hack is crude I don't mkelfImage is to stupid to realize that we have a problem.
20M is indeed to small.
My understanding is that 20M is a location, not a size.
The ramdisk (incl. kernel modules) is on the order of 26M; I've tried setting it to 32M - this setting is what allows the kernel to actually start; however (as previously mentioned), the kernel is unable to mount the ramdisk.
Because the kernel is looking at 20M and you moved it to 32M?
It seems like you need to adjust something else in your process to move the location of the kernel or initrd, or make the kernel smaller so that 16M + kernel < 20M.
Thanks, Myles
"Myles Watson" mylesgw@gmail.com writes:
ramdisk-base is just where in ram to load the ramdisk. mkelfImage
defaults
to 8M. You are setting it to 20M. With the change to kernels to
default
them to running at 16M that only leaves 4M for the kernel which I expect
is
to little. Because mkelfImage is old and the hack is crude I don't mkelfImage is to stupid to realize that we have a problem.
20M is indeed to small.
My understanding is that 20M is a location, not a size.
Yes.
The ramdisk (incl. kernel modules) is on the order of 26M; I've tried setting it to 32M - this setting is what allows the kernel to actually start; however (as previously mentioned), the kernel is unable to mount the ramdisk.
Because the kernel is looking at 20M and you moved it to 32M?
No. These are the parameters passed to the kernel. What I have seen in the past is the ramdisk being loaded close enough to the kernel that the kernel stomps it, and corrupts it in early startup. This should be diagnosable by looking at the boot up messages from the kernel startup.
Eric
20M is indeed to small.
My understanding is that 20M is a location, not a size.
Yes.
The ramdisk (incl. kernel modules) is on the order of 26M; I've tried setting it to 32M - this setting is what
allows
the kernel to actually start; however (as previously mentioned), the kernel is unable to mount the ramdisk.
Because the kernel is looking at 20M and you moved it to 32M?
No. These are the parameters passed to the kernel. What I have seen in the past is the ramdisk being loaded close enough to the kernel that the kernel stomps it, and corrupts it in early startup. This should be diagnosable by looking at the boot up messages from the kernel startup.
Sorry I misunderstood. I'm surprised that 16M wasn't enough room to keep the kernel from overwriting the initrd.
Thanks, Myles
"Myles Watson" mylesgw@gmail.com writes:
20M is indeed to small.
My understanding is that 20M is a location, not a size.
Yes.
The ramdisk (incl. kernel modules) is on the order of 26M; I've tried setting it to 32M - this setting is what
allows
the kernel to actually start; however (as previously mentioned), the kernel is unable to mount the ramdisk.
Because the kernel is looking at 20M and you moved it to 32M?
No. These are the parameters passed to the kernel. What I have seen in the past is the ramdisk being loaded close enough to the kernel that the kernel stomps it, and corrupts it in early startup. This should be diagnosable by looking at the boot up messages from the kernel startup.
Sorry I misunderstood. I'm surprised that 16M wasn't enough room to keep the kernel from overwriting the initrd.
I am a bit surprised as well. It smells a bit like a kernel bug.
To the wider audience I have a question. How do most folks making coreboot images use mkelfImage? With an uncompressed vmlinux? With a bzImage?
At the moment I want to mandate a bzImage for x86, but I'm not certain if that is practical the way we build images for coreboot.
Eric
On Fri, May 21, 2010 at 1:22 PM, Eric W. Biederman ebiederm@xmission.com wrote:
"Myles Watson" mylesgw@gmail.com writes:
At the moment I want to mandate a bzImage for x86, but I'm not certain if that is practical the way we build images for coreboot.
The last time I used it I used vmlinux, because we can lzma compress the whole elfimage when done merging in the other its (initrd etc.). I can't see any reason that your mandate would cause trouble, but it might slow things down a bit with two uncompress steps, one not needed.
thanks
ron
ron minnich rminnich@gmail.com writes:
On Fri, May 21, 2010 at 1:22 PM, Eric W. Biederman ebiederm@xmission.com wrote:
"Myles Watson" mylesgw@gmail.com writes:
At the moment I want to mandate a bzImage for x86, but I'm not certain if that is practical the way we build images for coreboot.
The last time I used it I used vmlinux, because we can lzma compress the whole elfimage when done merging in the other its (initrd etc.). I can't see any reason that your mandate would cause trouble, but it might slow things down a bit with two uncompress steps, one not needed.
There are also size issues. I think I need to ensure that linux builds a bImage. So that you can have an uncompress bzImage. For this embedded case.
Eric
Stefan Reinauer wrote:
On 19.05.2010, at 13:42, ebiederm@xmission.com (Eric W. Biederman) wrote:
The kernel initialization code as of boot protocol 2.10 is now reading the kernel_alignment field. With the field left the kernel attempts to align things to 4GB which is unlikely to work, so change the alignment to the kernels normal value of 16MB so newer kernels process by mkelfImage will boot.
Signed-off-by: "Eric W. Biederman" ebiederm@xmission.com
..
Awesome!
Acked-by: Stefan Reinauer stepan@coresystems.de
Acked-by: Peter Stuge peter@stuge.se
r5914
Eric W. Biederman wrote:
At the moment I want to mandate a bzImage for x86, but I'm not certain if that is practical the way we build images for coreboot.
..
I think I need to ensure that linux builds a bImage. So that you can have an uncompress bzImage. For this embedded case.
bImage would help make mkelfImage's life easier staying forward compatible?
//Peter
Peter Stuge peter@stuge.se writes:
Eric W. Biederman wrote:
At the moment I want to mandate a bzImage for x86, but I'm not certain if that is practical the way we build images for coreboot.
..
I think I need to ensure that linux builds a bImage. So that you can have an uncompress bzImage. For this embedded case.
bImage would help make mkelfImage's life easier staying forward compatible?
Wow. This project got paged out :(
Always working with a bzImage format would help with being compatible. Having an uncompressed kernel aka a bImage in that format would help having a smaller total size, by not needing to have a decompressor in both the kernel image and in coreboot.
Eric
On Wed, Oct 6, 2010 at 1:43 AM, Eric W. Biederman ebiederm@xmission.com wrote:
Peter Stuge peter@stuge.se writes:
Eric W. Biederman wrote:
At the moment I want to mandate a bzImage for x86, but I'm not certain if that is practical the way we build images for coreboot.
..
I think I need to ensure that linux builds a bImage. So that you can have an uncompress bzImage. For this embedded case.
bImage would help make mkelfImage's life easier staying forward compatible?
Wow. This project got paged out :(
Always working with a bzImage format would help with being compatible. Having an uncompressed kernel aka a bImage in that format would help having a smaller total size, by not needing to have a decompressor in both the kernel image and in coreboot.
Eric
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hello! I can see where this is traveling to. It is indeed taking a long time to get there.
However what about the kexec tools? I freely admit that the kernel function is now a part of the basic kernel configuration. But what about the tools themselves? As it happens my newer Slackware Linux system is running a 2.6.33.4-smp kernel. (Dual P4 system, with features that lend itself to Coreboot, if it wasn't for specialized functions that machine claims to need.)
----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again."
-
ebiederm＠xmission.com -
Gregg Levine -
Myles Watson -
Peter Stuge -
ron minnich -
Stefan Reinauer -
Troy Telford