This patch adds ADLO to buildrom using the gcc ported BOCHS BIOS. It boots Windows XP in QEMU. It still needs as86 to be installed because I didn't port the loader yet. Other things like making the loader understand the coreboot information to get the RAM map would be nice too.
I'm attaching the ELF headers, since svn diff doesn't include binary files.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
I don't know what the history of the ADLO code is - any reason why we can't give it a home in payloads/ on SVN instead of living in the buildrom code?
Jordan
On 30/04/08 09:58 -0600, Myles Watson wrote:
This patch adds ADLO to buildrom using the gcc ported BOCHS BIOS. It boots Windows XP in QEMU. It still needs as86 to be installed because I didn't port the loader yet. Other things like making the loader understand the coreboot information to get the RAM map would be nice too.
I'm attaching the ELF headers, since svn diff doesn't include binary files.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
Index: config/payloads/payloads.conf
--- config/payloads/payloads.conf (revision 170) +++ config/payloads/payloads.conf (working copy) @@ -16,6 +16,7 @@ ### Include the correct payload configuration
PCONF-y= +PCONF-$(CONFIG_PAYLOAD_ADLO) = adlo.conf PCONF-$(CONFIG_PAYLOAD_LAB) = lab.conf PCONF-$(CONFIG_PAYLOAD_ETHERBOOT) = etherboot.conf PCONF-$(CONFIG_PAYLOAD_GPXE) = gpxe.conf @@ -28,6 +29,10 @@ PCONF-$(CONFIG_PAYLOAD_TINT) = tint.conf PCONF-$(CONFIG_PAYLOAD_GRUB2) = grub2.conf
+ifeq ($(PCONF-y),) +$(error No payload .conf file specified.) +endif
DEPENDS-y= include $(CONFIG_DIR)/payloads/$(PCONF-y)
Index: config/payloads/adlo.conf
--- config/payloads/adlo.conf (revision 0) +++ config/payloads/adlo.conf (revision 0) @@ -0,0 +1,15 @@ +# Configuration file for the ADLO payload
+# Common configuration options
+PAYLOAD_BUILD=scripts/Makefile.generic
+PAYLOAD_ELF=$(OUTPUT_DIR)/adlo-payload.elf +PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/adlo-payload.elf.lzma
+PAYLOAD=adlo +PAYLOAD-y=adlo
+# Add legacybios as a dependency +PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/legacybios/legacybios.mk $(PACKAGE_DIR)/adlo/adlo.mk +DEPENDS-y +=legacybios Index: config/payloads/Config.in =================================================================== --- config/payloads/Config.in (revision 170) +++ config/payloads/Config.in (working copy) @@ -9,6 +9,9 @@ help Buildrom can build a number of different payloads for the ROM
+config PAYLOAD_ADLO
- bool "ADLO (Bochs BIOS with a wrapper for Coreboot)"
config PAYLOAD_COREINFO bool "Coreinfo"
Index: packages/adlo/adlo/STATUS
--- packages/adlo/adlo/STATUS (revision 0) +++ packages/adlo/adlo/STATUS (revision 0) @@ -0,0 +1,154 @@ +$Id: STATUS,v 1.1 2002/11/25 02:07:53 rminnich Exp $ +========================================== +==========================================
STATUS+========================================== +==========================================
+LILO
- fully supported
- ==========================================
+GRUB
- fully supported
- notes
int15/eAX=00C0 - not supportedint15/Eax=5300 - not supportedint 13 ; fn 41 -> dev 81int 13 ; fn 08 -> dev 81- ==========================================
+LINUX
- fully supported
- notes
won't rebootfix fb?- ==========================================
+openbsd
- fully supported
- notes
won't reboot- ==========================================
+Win2k
- fully supported
- notes
network?better gfx?- ==========================================
+freebsd
- somewhat supported
- notes
won't rebootright now it hangs somewhere around fsck/net startupprobably due to bad PIRQ table,it probably switches to polled IO and is dog slow.- ==========================================
+Win98
- somewhat supported
- lots of ata issues, but if get past
- ata hurdles, desktop will show up
- press F8 for safe mode.
the desktop comes up(can see "safe mode")- int 15 D8 (?) not supporte
- int 15 ?? not supported
- int 15 fn 24 (set A20 gate) not suported)
- ==========================================
+winXP
- no go
+safe/normal boot
- progress bar finishes, switches to gfx mode
- and immediatelly STOP 7B, no sub error.
+more timing problems!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
- more likely "unexpected previous state" problems.
+cold reboot, normal boot and safe mode
- missing hal
\system32\hal.dll- missing system
+------------------- +no lba - ie none
- function 02, error 11 - drv not ready.
- ==========================================
- ==========================================
+syslinux +netbsd +hurd +dos +other applications
- not supported/tested at present time
- ==========================================
+TODO:
+timing in ide read code (int13) [WIP]
- grub boot
sometimes it work, sometimes it doesn't- openbsd boot /WinXP boot.
(AH=0x02) misreads sometimes.+fix int15 memory functions. (E820, etc)
- so that mem size is not hard coded.
- (see prep "fixup" section in loader.s)
+fix bios to properly handle reboot
+setup PIRQ table for P6STMT mbo.
- have it extract from coreboot somehow..
find it in ram and copy...+hack gcc to support 16 bit real mode.
+port 80 card broken?
+hack dev86 to support rdmsr and wrmsr [done]
- ==========================================
+problems:
- -binary only video bios required
- -binary only bios required
- -warm reboot from pc bios is required
chipset timings or somethingP6STMT board only.- int 12 not stable, multiple reboot required
debug msg for slowing down required- ==========================================
Index: packages/adlo/adlo/README.1st
--- packages/adlo/adlo/README.1st (revision 0) +++ packages/adlo/adlo/README.1st (revision 0) @@ -0,0 +1,37 @@ +Date: Sat, 23 Nov 2002 22:20:57 -0500 +From: Adam Sulmicki adam@cfar.umd.edu +To: LinuxBIOS linuxbios@clustermatic.org +Cc: William Arbaugh waa@cs.umd.edu, Adam Agnew agnew@cs.umd.edu +Subject: [ANNOUNCE] LinuxBIOS boots Windows 2000, GRUB, and OpenBSD.
+We're happy to announce that we've been able to successfully boot +Windows 2000 without a legacy BIOS. We accomplished this by developing +software that combined elements from two very successful projects: +LinuxBIOS and BOCHS. The Etherboot project also helped in various ways.
+As a result now, we have a completely open source replacement for the +BIOS that can use (without modification) either LILO or GRUB as +bootloaders, and Linux, OpenBSD, and Windows 2000 as operating systems +(NOTE: We're still working on supporting FreeBSD and Windows XP. We +expect that improving ATA support will permit Win98 and WinXP to boot, +and finishing PIRQ support will permit FreeBSD to boot.) Motherboard +support is also limited at this time, but we hope to expand that along +with LinuxBIOS.
+More details can be found at:
+http://www.missl.cs.umd.edu/Projects/sebos/main.shtml
+and
+http://www.missl.cs.umd.edu/Projects/sebos/phase2.shtml
+Ironically, twenty years ago this month Compaq introduced their Compaq +portable computer with the first BIOS outside of IBM, see +http://www.old-computers.com/museum/computer.asp?st=1&c=547 .
+Adam Sulmicki +Adam Agnew +William Arbaugh
+This work has been funded by a grant from DARPA under the CHATS program. Index: packages/adlo/adlo/HACKING =================================================================== --- packages/adlo/adlo/HACKING (revision 0) +++ packages/adlo/adlo/HACKING (revision 0) @@ -0,0 +1,16 @@ +DEVELOPER/HACKING/DESIGN
+- bochs bios.
- we expect most of the bochs patches will be rolled back into
- the bochs mainline.
- thus when designing an patch for rombios.c both needs of
- coreboot as well as bochs needed to be taken into
- consideration.
+- there are motherboard specific code in loader.s. until this issue
- is fixed, you need to adjust various motherboard specific
- settings in loader.s In particular control of the
- shadow ram.
Index: packages/adlo/adlo/elf/elf-header-065kb.payload
Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream
Property changes on: packages/adlo/adlo/elf/elf-header-065kb.payload ___________________________________________________________________ Name: svn:executable
Name: svn:mime-type
- application/octet-stream
Index: packages/adlo/adlo/elf/elf-header-068kb.payload
Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream
Property changes on: packages/adlo/adlo/elf/elf-header-068kb.payload ___________________________________________________________________ Name: svn:executable
Name: svn:mime-type
- application/octet-stream
Index: packages/adlo/adlo/INSTALL
--- packages/adlo/adlo/INSTALL (revision 0) +++ packages/adlo/adlo/INSTALL (revision 0) @@ -0,0 +1,47 @@ +1) Are you familar with coreboot?
- no : abort
- yes: go to next step.
+2) do you have Matsonic 7308e motherboard?
- no : you are on your own (untested).
- yes: go to next step.
+3) do you have LiuxBIOS running on Matsonic 7308e motherboard?
- no : get it working first on your motherboard.
- yes: go to next step.
+4) Acquire copy of your VIDEO BIOS.
- -Put in your PC BIOS into the system,
- -Boot into linux.
- -as root run "make videobios" from ADLO's root dir.
- -copy the file to video directory
adjust make file as needed.+5) Acquire copy of your PIRQ table.
- At present time it is not necessary to do this
- and you can use supplied PIRQ table.
+6) Acquire copy of BOCHS bios.
- At present time it is not necessary to do this
- and you can use supplied rombios.c.
- In fact you should use supplied rombios.c
- file as the one used with BOCHS is not
- complete at the present time.
+7) Examine make file to see that it does what u want.
+8) compile
- make
+9) use the resulting elf "payload" file with coreboot as you would
- have used any other elf file. For example put it on the same
- EERPOM as coreboot is, or use EtherBOOT to load the payload
- file from hdd or network.
Index: packages/adlo/adlo/loader.s
--- packages/adlo/adlo/loader.s (revision 0) +++ packages/adlo/adlo/loader.s (revision 0) @@ -0,0 +1,467 @@ +;***************************************************** +; $Id: loader.s,v 1.1 2002/11/25 02:07:53 rminnich Exp $ +;***************************************************** +USE32 +; code it is loaded into memory at 0x7C00 +;***************************************************** +nop +nop +;***************************************************** +; A) setup GDT, so that we do not depend on program +; that loaded us for GDT. +; Ex: Coreboot and EtherBOOT use different GDT's.
+;----------------------------------------------------- +; 0)
+cli
+;----------------------------------------------------- +; I)
+lgdt [0x7C00+protected_gdt]
+;----------------------------------------------------- +; II) setup CS
+jmp 0x08:0x7C00+newpgdt
+newpgdt: nop
+;----------------------------------------------------- +; III) setup all other segments
+mov ax, #0x10 +mov ss, ax +mov ds, ax +mov es, ax +mov fs, ax +mov gs, ax
+;----------------------------------------------------- +; IV)
+; not now +;sti
+;***************************************************** +nop +nop +;***************************************************** +; B) shadow - ON (enable/read/write)
+mov eax, #0x80000070 +mov dx, #0x0cf8 +out dx, eax
+mov eax, #0xFFFFFFFF +mov dx, #0x0cfc +out dx, eax
+;***************************************************** +nop +nop +;***************************************************** +; C) copy -- boch bios
+; counter - 64kb. +mov ecx, #0x10000
+; source - 0x8000 ( 0x7C00+0x400 = 0x8000 ) +mov ax, #0x10 ; src-segment - 2nd entry in GDT +mov ds, ax +mov eax, #0x8000 ; src-offset - 0x8000 +mov esi, eax
+; destination - 0xF0000 +mov ax, #0x10 ; dst-segment - 2nd entry in GDT +mov es, ax +mov eax, #0xF0000 ; dst-offset - 0xF0000 +mov edi, eax
+; clear direction flag +cld
+; the copy +rep
- movsb
+;***************************************************** +nop +nop +;***************************************************** +; X) copy -- Coreboot table into safe place.
- ;; TODO.
- ;; Q1 : what is the size of table.
- ;; Q2 : where to copy?
+;***************************************************** +nop +nop +;***************************************************** +; E) shadow - OFF (write)
+mov eax, #0x80000070 +mov dx, #0x0cf8 +out dx, eax
+;mov eax, #0xFFFFFFFF +mov eax, #0x0000FFFF +mov dx, #0x0cfc +out dx, eax
+;***************************************************** +nop +nop +;***************************************************** +; F) do a little prep work.
+;----------------------------------------------------- +; I) disable cache
+; if you disable cache, GRUB's GFX mode will be VERY slow. +; so DO NOT DISABLE
+;mov eax, cr0 +;or eax, #0x60000000 +;wbinvd +;mov cr0, eax +;wbinvd
+;----------------------------------------------------- +; II) disable MTRR +; clear the "E" (0x800) and "FE" (0x400) flags in +; IA32_MTRRdefType register (0x2FF)
+;-----------------------
+;mov ECX,#0x2FF
+; select either of the two below +; depending on if your compiler suports +; {RD,WR}MSR or not +;rdmsr +; .byte 0x0F, 0x32
+;xor edx, edx +; xor eax, eax +;and eax, #0xFFFFF3FF
+; select either of the two below +; depending on if your compiler suports +; {RD,WR}MSR or not +;wrmsr +; .byte 0x0F, 0x30
+;----------------------- +;; This is what PC BIOS is setting. -- P6STMT. +; add VIDEO BIOS cacheable!!!! +;----------------------- +; Fixed Range C0--C8 +;mov ECX,#0x268 +;mov EDX,#0x05050505 +;mov EAX,#0x05050505 +;wrmsr +;----------------------- +; Fixed Range C8--CF +;mov ECX,#0x269 +;mov EDX,#0x0 +;mov EAX,#0x05050505 +;wrmsr +;-----------------------
+;----------------------------------------------------- +; III) tell BOCHS' BIOS we want to boot from hdd. +; 0x00 - floppy +; 0x02 - hdd +; It's changed now //With El Torito enabled +; 0x0 - none +; 0x1 - floppy +; 0x2 - hdd +; 0x3 - cdrom +; i.e., 0x23 means try the cdrom first, then the hdd +; In future there will be 'fd failover'option in bochs.
+mov al, #0x3d ;; cmos_reg +out 0x70, al +mov al, #0x23 ;; val (cd then hdd) +out 0x71, al
+;----------------------------------------------------- +; IV) tell BOCHS' BIOS length of our mem block @ 1mb. +; This is for Int 15 / EAX=E820 +; 119mb = 0x77 00 00 00 +; (this is for 128mb of ram) +; (FIXME: this value is currently hard coded) +; (it should be being passed from coreboot )
+; for WinFast 6300 +; 07 70 = 0770 +; 06 80 = 0770 - 00F0 << ALT (for unpatched bochs)
+; for P6STMT - 10kb less ram +; 077F - 10 = 07 6F +; 07 6F - 00 F0 = 06 7F
+mov al, #0x35 ;; cmos_reg +out 0x70, al +mov al, #0x06 ;; val +out 0x71, al
+mov al, #0x34 ;; cmos_reg +out 0x70, al +mov al, #0x7F ;; val +out 0x71, al
+mov al, #0x31 ;; cmos_reg +out 0x70, al +mov al, #0x00 ;; val +out 0x71, al
+mov al, #0x30 ;; cmos_reg +out 0x70, al +mov al, #0x00 ;; val +out 0x71, al
+;----------------------------------------------------- +; V) tell BOCHS' BIOS we want to have LBA translation. +; 0x00 - NONE +; 0x01 - LBA <<<< +; 0x02 - LARGE +; 0x03 - R-CHS +; In future there will be 'fd failover'option in bochs.
+mov al, #0x39 ;; cmos_reg +out 0x70, al +mov al, #0x05 ;; val 5 = (LBA and LBA) 0 = none +out 0x71, al
+;***************************************************** +nop +nop +;***************************************************** +; G) the switch -- protected to real mode
+; IASDM, Vol 3 +; (8-14) 8.8.2 Switching Back to Real-Address Mode
+;===================================================== +; 1) disable interrupts
+cli
+;===================================================== +nop +;===================================================== +; 2) paging
+;not enabled, so not applicable.
+;===================================================== +; 3) setup CS segment limit (64kb) +; I)
+lgdt [0x7C00+new_gdt]
+;----------------------------------------------------- +; II)
+jmp 0x08:0x7C00+new64lim
+new64lim: nop
+;===================================================== +nop +;===================================================== +; 4) setup all other segments
+mov ax, #0x10 +mov ss, ax +mov ds, ax +mov es, ax +mov fs, ax +mov gs, ax
+;===================================================== +nop +;===================================================== +; 5) LIDT +; I)
+; set up Real Mode IDT table (0...3FF)
+; for BOCH's BIOS the address 0xF000:0xFF53 +; cantains value 0xCF which is IRET opcode.
+; counter +mov cx, #0xFF ;1024 bytes(255 interrupts)(4*255=0x3FF)
+; destination - 0x00000 = ES:EDI +mov ax, #0x10 ; dst-segment - 2nd entry in GDT +mov es, ax +mov eax, #0x00000 ; dst-offset - 0x00000 +mov edi, eax
+; data to store -- 0xF000:FF53 +mov eax, #0xF000FF53
+; clear direction flag +cld
+; the store +rep
- stosd
+;----------------------------------------------------- +; II) +; load interrupt descriptor table
+lidt [0x7C00+new_idt]
+;===================================================== +nop +nop +;===================================================== +; 6) clear the PE flag in CR0 register. +; I)
+; switch to 16 bit segments +mov ax, #0x20 +mov ss, ax +mov ds, ax +mov es, ax +mov fs, ax +mov gs, ax
+;----------------------------------------------------- +; II)
+; switch to 16 bit CS
+jmp 0x018:0x7C00+new16bit
+USE16
+new16bit: nop
+;----------------------------------------------------- +; III) +; the switch
+;xor eax, eax
+mov eax, cr0 +and eax, #0xFFFFFFFE +mov cr0, eax ;switch to RM
+;===================================================== +nop +nop +;===================================================== +; 7) far jump -- (to real mode address)
+jmp 0x0:0x7C00+realcs
+realcs: nop
+;===================================================== +; 8) set all segment registers to 0's
+mov ax, #0x0 +mov ss, ax +mov ds, ax +mov es, ax +mov fs, ax +mov gs, ax
+;===================================================== +; 9) re-enable interrupts
+sti
+;***************************************************** +nop +nop +;***************************************************** +; H) jump to BIOS.
+jmp 0xFFFF:0x0000 +;jmp 0xF000:0xFFF0
+;***************************************************** +;***************************************************** +nop +nop +nop +nop +;***************************************************** +;*****************************************************
+USE32
+new_idt: +dw 0x03ff ;; limit 15:00 +dw 0x0000 ;; base 15:00 +dw 0x0000 ;; base 23:16
+new_gdt: +dw 0x0028 ;; limit 15:00 +dw 0x7C00+new_gdt_table ;; base 15:00 +dw 0x0000 ;; base 23:16
+protected_gdt: +dw 0x0018 ;; limit 15:00 +dw 0x7C00+pmode_gdt_table ;; base 15:00 +dw 0x0000 ;; base 23:16
+;-----------------------------------------------------
+new_gdt_table: +;// 1 2 3 4 +;//0 +dd 0x00000000 +dd 0x00000000
+;//8 +dd 0x0000ffff +dd 0x00409E00
+;//10 +dd 0x0000ffff +dd 0x00409200
+;//18 +dd 0x0000ffff +dd 0x00009a00
+;//20 +dd 0x0000ffff +dd 0x00009200
+;-------------------------
+pmode_gdt_table: +;// 1 2 3 4 +;//0 +dd 0x00000000 +dd 0x00000000
+;//8 +dd 0x0000ffff +dd 0x00CF9E00
+;//10 +dd 0x0000ffff +dd 0x00CF9200
+;***************************************************** +;***************************************************** +; the file size must be 1024 bytes.
+.org 0x400-1 +; dd 0xdeadbeef +db 0x0
+;***************************************************** Index: packages/adlo/adlo/align.patch =================================================================== --- packages/adlo/adlo/align.patch (revision 0) +++ packages/adlo/adlo/align.patch (revision 0) @@ -0,0 +1,105 @@ +--- loader.s 2008-02-13 12:12:04.000000000 -0700 ++++ loader_4K.s 2008-04-11 15:57:01.000000000 -0600 +@@ -2,7 +2,7 @@
- ; $Id: loader.s,v 1.1 2002/11/25 02:07:53 rminnich Exp $
- ;*****************************************************
- USE32
+-; code it is loaded into memory at 0x7C00 ++; code it is loaded into memory at 0x7000
- ;*****************************************************
- nop
- nop
+@@ -19,12 +19,12 @@
- ;-----------------------------------------------------
- ; I)
+-lgdt [0x7C00+protected_gdt] ++lgdt [0x7000+protected_gdt]
- ;-----------------------------------------------------
- ; II) setup CS
+-jmp 0x08:0x7C00+newpgdt ++jmp 0x08:0x7000+newpgdt
- newpgdt: nop
+@@ -67,7 +67,7 @@
- ; counter - 64kb.
- mov ecx, #0x10000
+-; source - 0x8000 ( 0x7C00+0x400 = 0x8000 ) ++; source - 0x8000 ( 0x7000+0x1000 = 0x8000 )
- mov ax, #0x10 ; src-segment - 2nd entry in GDT
- mov ds, ax
- mov eax, #0x8000 ; src-offset - 0x8000
+@@ -262,12 +262,12 @@
- ; 3) setup CS segment limit (64kb)
- ; I)
+-lgdt [0x7C00+new_gdt] ++lgdt [0x7000+new_gdt]
- ;-----------------------------------------------------
- ; II)
+-jmp 0x08:0x7C00+new64lim ++jmp 0x08:0x7000+new64lim
- new64lim: nop
+@@ -317,7 +317,7 @@
- ; II)
- ; load interrupt descriptor table
+-lidt [0x7C00+new_idt] ++lidt [0x7000+new_idt]
- ;=====================================================
- nop
+@@ -339,7 +339,7 @@
- ; switch to 16 bit CS
+-jmp 0x018:0x7C00+new16bit ++jmp 0x018:0x7000+new16bit
- USE16
+@@ -361,7 +361,7 @@
- ;=====================================================
- ; 7) far jump -- (to real mode address)
+-jmp 0x0:0x7C00+realcs ++jmp 0x0:0x7000+realcs
- realcs: nop
+@@ -407,12 +407,12 @@
- new_gdt:
- dw 0x0028 ;; limit 15:00
+-dw 0x7C00+new_gdt_table ;; base 15:00 ++dw 0x7000+new_gdt_table ;; base 15:00
- dw 0x0000 ;; base 23:16
- protected_gdt:
- dw 0x0018 ;; limit 15:00
+-dw 0x7C00+pmode_gdt_table ;; base 15:00 ++dw 0x7000+pmode_gdt_table ;; base 15:00
- dw 0x0000 ;; base 23:16
- ;-----------------------------------------------------
+@@ -457,10 +457,10 @@
- ;*****************************************************
- ;*****************************************************
+-; the file size must be 1024 bytes. ++; the file size must be 4096 bytes.
+-.org 0x400-1 ++.org 0x1000-1
- ; dd 0xdeadbeef
- db 0x0
Index: packages/adlo/adlo/COPYING
--- packages/adlo/adlo/COPYING (revision 0) +++ packages/adlo/adlo/COPYING (revision 0) @@ -0,0 +1,340 @@
GNU GENERAL PUBLIC LICENSEVersion 2, June 1991- Copyright (C) 1989, 1991 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
Preamble- The licenses for most software are designed to take away your
+freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Library General Public License instead.) You can apply it to +your programs, too.
- When we speak of free software, we are referring to freedom, not
+price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things.
- To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it.
- For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights.
- We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software.
- Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations.
- Finally, any free program is threatened constantly by software
+patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all.
- The precise terms and conditions for copying, distribution and
+modification follow. +
GNU GENERAL PUBLIC LICENSE- TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
- This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you".
+Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does.
- You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program.
+You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee.
- You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions:
- a) You must cause the modified files to carry prominent notices
- stating that you changed the files and the date of any change.
- b) You must cause any work that you distribute or publish, that in
- whole or in part contains or is derived from the Program or any
- part thereof, to be licensed as a whole at no charge to all third
- parties under the terms of this License.
- c) If the modified program normally reads commands interactively
- when run, you must cause it, when started running for such
- interactive use in the most ordinary way, to print or display an
- announcement including an appropriate copyright notice and a
- notice that there is no warranty (or else, saying that you provide
- a warranty) and that users may redistribute the program under
- these conditions, and telling the user how to view a copy of this
- License. (Exception: if the Program itself is interactive but
- does not normally print such an announcement, your work based on
- the Program is not required to print an announcement.)
+ +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it.
+Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program.
+In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License.
- You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following:
- a) Accompany it with the complete corresponding machine-readable
- source code, which must be distributed under the terms of Sections
- 1 and 2 above on a medium customarily used for software interchange; or,
- b) Accompany it with a written offer, valid for at least three
- years, to give any third party, for a charge no more than your
- cost of physically performing source distribution, a complete
- machine-readable copy of the corresponding source code, to be
- distributed under the terms of Sections 1 and 2 above on a medium
- customarily used for software interchange; or,
- c) Accompany it with the information you received as to the offer
- to distribute corresponding source code. (This alternative is
- allowed only for noncommercial distribution and only if you
- received the program in object code or executable form with such
- an offer, in accord with Subsection b above.)
+The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable.
+If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. +
- You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance.
- You are not required to accept this License, since you have not
+signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it.
- Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License.
- If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program.
+If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances.
+It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice.
+This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. +
- If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License.
- The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns.
+Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and "any +later version", you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Software +Foundation.
- If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally.
NO WARRANTY
- BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION.
- IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS+
How to Apply These Terms to Your New Programs- If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms.
- To do so, attach the following notices to the program. It is safest
+to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found.
- <one line to give the program's name and a brief idea of what it does.>
- Copyright (C) <year> <name of author>
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+Also add information on how to contact you by electronic and paper mail.
+If the program is interactive, make it output a short notice like this +when it starts in an interactive mode:
- Gnomovision version 69, Copyright (C) year name of author
- Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
- This is free software, and you are welcome to redistribute it
- under certain conditions; type `show c' for details.
+The hypothetical commands `show w' and `show c' should show the appropriate +parts of the General Public License. Of course, the commands you use may +be called something other than `show w' and `show c'; they could even be +mouse-clicks or menu items--whatever suits your program.
+You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the program, if +necessary. Here is a sample; alter the names:
- Yoyodyne, Inc., hereby disclaims all copyright interest in the program
- `Gnomovision' (which makes passes at compilers) written by James Hacker.
- <signature of Ty Coon>, 1 April 1989
- Ty Coon, President of Vice
+This General Public License does not permit incorporating your program into +proprietary programs. If your program is a subroutine library, you may +consider it more useful to permit linking proprietary applications with the +library. If this is what you want to do, use the GNU Library General +Public License instead of this License. Index: packages/adlo/adlo/CAST =================================================================== --- packages/adlo/adlo/CAST (revision 0) +++ packages/adlo/adlo/CAST (revision 0) @@ -0,0 +1,9 @@ +Most of the analysis, design and implementation of the project was done by +me, Adam Sulmicki. I have received invaluable help from Adam Agnew. Bill +Arbaugh was the person who made it all possible.
+I also received help from Christophe Bothamy, Bochs' developer, on all +Boch's bios related issues. Thanks!
+I also got tips from Eric W. Biederman, as well as other members of the +coreboot mailing list. Index: packages/adlo/adlo/NEWS =================================================================== --- packages/adlo/adlo/NEWS (revision 0) +++ packages/adlo/adlo/NEWS (revision 0) @@ -0,0 +1,38 @@ +initial release
- boots LILO
+"linux_alpha" release
- fixed keyboard in lilo
- boots linux
(must use "linux mem=100mb ro init=/bin/sh ")+"win2k" release
- lilo works
no restrictions- grub works
no restrictions- linux works
no restrictions- openbsd works
no restrictions- win2k
no restrictions- freebsd
hangs at /sbin/init- win98
sometimes boots up to desktop- winXP
finish text mode bar,switch to gfx modestop 7b+"public" release
- just bit of cleanups, other than that same as
- "win2k" release.
Index: packages/adlo/adlo/README
--- packages/adlo/adlo/README (revision 0) +++ packages/adlo/adlo/README (revision 0) @@ -0,0 +1,231 @@ +========================================== +$Id: README,v 1.1 2002/11/25 02:07:53 rminnich Exp $ +==========================================
+ADLO
- A project to combine coreboot and BOCHS BIOS to add support
- for booting legacy applications, such as Microsoft Windows.
+==========================================
+Boot Overvew:
- ADLO requires an boot loader with ELF support.
- In our case it is either coreboot or EtherBOOT.
- Sample execution paths:
+coreboot -> ADLO -> LILO -> LINUX
+coreboot -> EtherBOOT -> ADLO -> LILO -> LINUX
- Then it can start any real mode application.
- In our case it could be LILO or GRUB, but
- choices are not limited to this.
+==========================================
+ADLO overview:
- -Elf header
- -mainteance routines
- -bochs bios
- -vga bios
+------------------------------------------
+Elf header
- hand crafted binary. Currently there are 3 diff binaries
- for three different sizes of payload (65kb,113kb,129kb).
- they are catted at beginning of file
+------------------------------------------
+mainteance routines
- this is the loader.s file which gets compiled into loader.o binary
- it is catted 2nd right after elf header and it is where
- control is being transfered when the elf is executed.
- it consist of :
-tuneups:select device to bootset memory for Int15/EAX=E820enable LBAcopy coreboot table [TODO]-shadow :enable/write/read-copy:bochs @ 0xF00000video bios (binary only) @ 0xC00000-switchfrom Real to Protected Mode-jumpjmp to the bios at 0xFFFF:0x0000- we must have bios payload always at 1kb
- offset from start of ELF payload so loader.o
- must be always 1024 bytes.
+------------------------------------------
+BOCHS BIOS
- we have taken the boch's project and just extracted
- its bios from it only. it took us (so far) only
- minor modifications in order to make it work.
- basically it is the following directory in the
- bochs sources
bochs-cvs/bochs/bios- of all files there the rombios.c is the key file.
- Most of the times our patches are against current
- version of the rombios.c file. We try to feed back
- the patches to bochs maintainers so that's possible
- to use the bochs bios as is.
- the boch's related stuff are in bochs subdirectory.
- building boch's bios is as simple as
cd bochs/bochs-cvs/bochs/biosmake- the resulting file rombios.bin is our bios image.
------ At present time, it is recommended to use
- dev86-0.16.3 + my patch in order to compile
- bochs' bios. The dev86 package can be found
- at:
- http://www.cix.co.uk/~mayday/
- prepatched sources at:
- http://www.missl.cs.umd.edu/~adam/dev86-0.16.3-MSR.tgz
+------------------------------------------
+Video BIOS
- Video BIOS we use is binary only, so far.
- At the present time we are using the original
- Video BIOS as supplied from the system.
- To get the image simply type:
make makevideobios- The right thing will happen. For refernece the
- magic line in the Makefile is:
- videobios:
dd if=/proc/kcore \of=./video.bios.bin \bs=1 count=65536 skip=790528---------------- We assume it is located at 0xC00000-0xE00000
- and we use 'dd and /proc/kcore to extract it
- (obviously it works as root only).
- Obviously it needs to be done with original
- (as shipped by manufactuer bios) so it should
- be done as the first step of the ADLO setup.
---------------- The /proc/kcore is in ELF format (linux kernel
- 2.4.x and later) so if we want to get accurate
- image of ram we must skip the ELF header.
- The magic command is :
readelf -a /proc/kcore+Program Headers:
- Type Offset VirtAddr PhysAddr FileSiz MemSiz
- NOTE 0x0007d4 0x00000000 0x00000000 0x005b0 0x00000
- LOAD 0x001000 0xc0000000 0x00000000 0xff60000 0xff60000
^^^^^^^^- There we look for the first LOAD section, and see what
- is its offset (for us it is 0x1000)
---------------- 64KiB = 65536
- 0x0C 00 00 + 0x10 00 = 790528
---------------- On technical note in our case video bios
- is just 48kb, but for paranoia sake we copy
- 64kb.
+==========================================
+Environment overview
+ADLO is an ELF file and thus can be loaded either directly from 1) +coreboot, or 2) via EtherBOOT, or 3) via EtherBOOT+ AA patch for FS +support.
+1) +Both coreboot and ADLO are on the same EEPROM chip. From end-user +viewpoint it is probably the most similar to the bios classic. +(computer boots up and just loads whatever is in MBR).
+2) +Set it up in /tftpboot directory on dhcp/tftp server and have it served +from there. (this is how we did the development)
+3) +Use AA patch and put it as /kernel file and it will be then loaded by +etherboot from local hard disk.
+------------------------------------------
+Before ADLO starts.
- ADLO requires an boot loader with ELF support.
- In our case it is:
- -coreboot
- -coreboot and EtherBOOT
- -coreboot and EtherBOOT + AA polled I/O patch (w/ FS support).
- As little as coreboot only is required to get ADLO
- up and running.
- For development purposes it is recommended full set of
- coreboot + EtherBOOT and boot via DHCP/TFTP.
+------------------------------------------
+After ADLO finish.
- ADLO will attempt to locate the first hard disk
- and read MBR from it and execute.
- Then it can start any real mode application.
- In our case it could be LILO or GRUB
- but choices are not limited to this.
- In our case it would cause LILO to load
- (fully usable) and from there it was able to
- execute simple programs. so far the list
- of the program is limited to linux which
- runs somewhat. More to come in future.
+========================================== Index: packages/adlo/adlo/Makefile =================================================================== --- packages/adlo/adlo/Makefile (revision 0) +++ packages/adlo/adlo/Makefile (revision 0) @@ -0,0 +1,42 @@ +#------------------------------------------------- +# $Id: Makefile,v 1.2 2003/05/22 12:52:38 aip Exp $ +#-------------------------------------------------
+ELF065=elf/elf-header-065kb.payload +ELF068=elf/elf-header-068kb.payload
+LOADER=loader +LOADER_4K=loader_4K
+LOADERS= ${LOADER_4K}.o ${LOADER}.o
+BOCHS_PATH=legacybios
+BIOS=${BOCHS_PATH}/rom.bin
+PAYLOAD=adlo.elf +PAYLOAD_KEXEC=adlo.aligned.elf
+#-------------------------------------------------
+all: ${LOADERS} ${BIOS}
- cat ${ELF065} ${LOADER}.o ${BIOS} > ${PAYLOAD}
- cat ${ELF068} ${LOADER_4K}.o ${BIOS} > ${PAYLOAD_KEXEC}
+#-------------------------------------------------
+${LOADER}.o: ${LOADER}.s
- as86 $< -b $@
+${LOADER_4K}.s: ${LOADER}.s
- patch $< -o $@ < align.patch
+${LOADER_4K}.o: ${LOADER_4K}.s
- as86 $< -b $@
+#-------------------------------------------------
+clean:
- rm -rf *.o ${PAYLOAD} ${PAYLOAD_KEXEC}
- rm -rf ${LOADER_4K}.s
Index: packages/adlo/adlo.mk
--- packages/adlo/adlo.mk (revision 0) +++ packages/adlo/adlo.mk (revision 0) @@ -0,0 +1,54 @@ +ADLO_DIR=$(BUILD_DIR)/adlo +ADLO_SRC_DIR=$(ADLO_DIR)/adlo +ADLO_STAMP_DIR=$(ADLO_DIR)/stamps +ADLO_LOG_DIR=$(ADLO_DIR)/logs
+ADLO_PATCHES=
+ifeq ($(CONFIG_VERBOSE),y) +ADLO_FETCH_LOG=/dev/stdout +ADLO_BUILD_LOG=/dev/stdout +ADLO_INSTALL_LOG=/dev/stdout +else +ADLO_BUILD_LOG=$(ADLO_LOG_DIR)/build.log +ADLO_INSTALL_LOG=$(ADLO_LOG_DIR)/install.log +ADLO_FETCH_LOG=$(ADLO_LOG_DIR)/fetch.log +endif
+# Make sure we have the tools we need to accomplish this +HAVE_AS86:=$(call find-tool,as86)
+ifeq ($(HAVE_AS86),n) +$(error To build ADLO, you need to install as86, available in dev86) +endif
+$(ADLO_STAMP_DIR)/.unpacked: | $(ADLO_STAMP_DIR) $(ADLO_DIR) $(ADLO_LOG_DIR)
- @ echo "Unpacking adlo..."
- @ cp -r $(PACKAGE_DIR)/adlo/adlo $(ADLO_DIR)
- @ ln -s $(LEGACYBIOS_SRC_DIR)/out/ $(ADLO_DIR)/adlo/legacybios
- @ touch $@
+$(ADLO_SRC_DIR)/adlo.elf: $(ADLO_STAMP_DIR)/.unpacked $(LEGACYBIOS_SRC_DIR)/out/rom.bin
- @ echo "Building adlo..."
- @ make -C $(ADLO_SRC_DIR) > $(ADLO_BUILD_LOG) 2>&1
+$(ADLO_STAMP_DIR)/.copied: $(ADLO_SRC_DIR)/adlo.elf
- @ mkdir -p $(shell dirname $(PAYLOAD_ELF))
- @ cp $(ADLO_SRC_DIR)/adlo.elf $(PAYLOAD_ELF)
- @ touch $@
+$(ADLO_STAMP_DIR) $(ADLO_LOG_DIR):
- @ mkdir -p $@
+adlo: $(ADLO_STAMP_DIR)/.copied
+adlo-clean:
- @ echo "Cleaning adlo..."
- @ rm -f $(ADLO_STAMP_DIR)/.copied
+ifneq ($(wildcard $(ADLO_SRC_DIR)/Makefile),)
- @ $(MAKE) -C $(ADLO_SRC_DIR) clean > /dev/null 2>&1
+endif
+adlo-distclean:
- @ rm -rf $(ADLO_DIR)/*
Index: packages/legacybios/legacybios.mk
--- packages/legacybios/legacybios.mk (revision 0) +++ packages/legacybios/legacybios.mk (revision 0) @@ -0,0 +1,56 @@ +LEGACYBIOS_URL=http://linuxtogo.org/~kevin/legacybios/ +LEGACYBIOS_TAG=0.2.0
+LEGACYBIOS_DIR=$(BUILD_DIR)/legacybios +LEGACYBIOS_SRC_DIR=$(LEGACYBIOS_DIR)/legacybios-$(LEGACYBIOS_TAG) +LEGACYBIOS_STAMP_DIR=$(LEGACYBIOS_DIR)/stamps +LEGACYBIOS_LOG_DIR=$(LEGACYBIOS_DIR)/logs
+LEGACYBIOS_PATCHES=
+ifeq ($(CONFIG_VERBOSE),y) +LEGACYBIOS_FETCH_LOG=/dev/stdout +LEGACYBIOS_BUILD_LOG=/dev/stdout +LEGACYBIOS_INSTALL_LOG=/dev/stdout +else +LEGACYBIOS_BUILD_LOG=$(LEGACYBIOS_LOG_DIR)/build.log +LEGACYBIOS_INSTALL_LOG=$(LEGACYBIOS_LOG_DIR)/install.log +LEGACYBIOS_FETCH_LOG=$(LEGACYBIOS_LOG_DIR)/fetch.log +endif
+LEGACYBIOS_TARBALL=legacybios-$(LEGACYBIOS_TAG).tar.gz +LEGACYBIOS_SOURCE=legacybios-$(LEGACYBIOS_TAG).tar.gz
+ifeq ($(shell if [ -f $(PACKAGE_DIR)/legacybios/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1)
- LEGACYBIOS_CONFIG = customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)
+endif
+$(SOURCE_DIR)/$(LEGACYBIOS_TARBALL):
- @ mkdir -p $(SOURCE_DIR)
- @ wget $(WGET_Q) -P $(SOURCE_DIR) $(LEGACYBIOS_URL)/$(LEGACYBIOS_SOURCE) --output-document=$(SOURCE_DIR)/$(LEGACYBIOS_TARBALL)
+$(LEGACYBIOS_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LEGACYBIOS_TARBALL) | $(LEGACYBIOS_STAMP_DIR) $(LEGACYBIOS_DIR) $(LEGACYBIOS_LOG_DIR)
- @ echo "Unpacking legacybios..."
- @ tar -C $(LEGACYBIOS_DIR) -zxf $(SOURCE_DIR)/$(LEGACYBIOS_TARBALL)
- @ touch $@
+$(LEGACYBIOS_SRC_DIR)/out/rom.bin: $(LEGACYBIOS_STAMP_DIR)/.unpacked
- @ echo "Building legacybios..."
- @ echo $(LEGACYBIOS_SRC_DIR)
- @ make -C $(LEGACYBIOS_SRC_DIR) > $(LEGACYBIOS_BUILD_LOG) 2>&1
+$(LEGACYBIOS_STAMP_DIR) $(LEGACYBIOS_LOG_DIR):
- @ mkdir -p $@
+legacybios: $(LEGACYBIOS_SRC_DIR)/out/rom.bin
+legacybios-clean:
- @ echo "Cleaning legacybios..."
- @ rm -f $(LEGACYBIOS_STAMP_DIR)/.copied
+ifneq ($(wildcard $(LEGACYBIOS_SRC_DIR)/Makefile),)
- @ $(MAKE) -C $(LEGACYBIOS_SRC_DIR) clean > /dev/null 2>&1
+endif
+legacybios-distclean:
- @ rm -rf $(LEGACYBIOS_DIR)/*
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-----Original Message----- From: Jordan Crouse [mailto:jordan.crouse@amd.com] Sent: Wednesday, April 30, 2008 10:08 AM To: Myles Watson Cc: Coreboot Subject: Re: ADLO for buildrom
I don't know what the history of the ADLO code is - any reason why we can't give it a home in payloads/ on SVN instead of living in the buildrom code?
I don't think so. The old code was in v2's tree under utils/
I didn't think it was too big of a deal, since it's only one assembly file, a make file, and two elf headers. I admit it looks like a lot with all the documentation.
I'm happy to have it live wherever's best. Who has to set that up?
Thanks, Myles
On 30/04/08 10:16 -0600, Myles Watson wrote:
-----Original Message----- From: Jordan Crouse [mailto:jordan.crouse@amd.com] Sent: Wednesday, April 30, 2008 10:08 AM To: Myles Watson Cc: Coreboot Subject: Re: ADLO for buildrom
I don't know what the history of the ADLO code is - any reason why we can't give it a home in payloads/ on SVN instead of living in the buildrom code?
I don't think so. The old code was in v2's tree under utils/
I didn't think it was too big of a deal, since it's only one assembly file, a make file, and two elf headers. I admit it looks like a lot with all the documentation.
I'm happy to have it live wherever's best. Who has to set that up?
Its all set up - just push - I recommend payloads/adlo.
Thanks, Myles
On Wed, Apr 30, 2008 at 10:18 AM, Jordan Crouse jordan.crouse@amd.com wrote:
On 30/04/08 10:16 -0600, Myles Watson wrote:
-----Original Message----- From: Jordan Crouse [mailto:jordan.crouse@amd.com] Sent: Wednesday, April 30, 2008 10:08 AM To: Myles Watson Cc: Coreboot Subject: Re: ADLO for buildrom
I don't know what the history of the ADLO code is - any reason why we can't give it a home in payloads/ on SVN instead of living in the buildrom code?
I don't think so. The old code was in v2's tree under utils/
I didn't think it was too big of a deal, since it's only one assembly file, a make file, and two elf headers. I admit it looks like a lot with all the documentation.
I'm happy to have it live wherever's best. Who has to set that up?
Its all set up - just push - I recommend payloads/adlo.
Here are two patches. One adds a lightened ADLO to payloads/adlo. The other adds ADLO to buildrom.
The only non-specific change is an error if there is no payload selected, since it causes the build to fail.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
On 30/04/08 11:21 -0600, Myles Watson wrote:
On Wed, Apr 30, 2008 at 10:18 AM, Jordan Crouse jordan.crouse@amd.com wrote:
On 30/04/08 10:16 -0600, Myles Watson wrote:
-----Original Message----- From: Jordan Crouse [mailto:jordan.crouse@amd.com] Sent: Wednesday, April 30, 2008 10:08 AM To: Myles Watson Cc: Coreboot Subject: Re: ADLO for buildrom
I don't know what the history of the ADLO code is - any reason why we can't give it a home in payloads/ on SVN instead of living in the buildrom code?
I don't think so. The old code was in v2's tree under utils/
I didn't think it was too big of a deal, since it's only one assembly file, a make file, and two elf headers. I admit it looks like a lot with all the documentation.
I'm happy to have it live wherever's best. Who has to set that up?
Its all set up - just push - I recommend payloads/adlo.
Here are two patches. One adds a lightened ADLO to payloads/adlo. The other adds ADLO to buildrom.
The only non-specific change is an error if there is no payload selected, since it causes the build to fail.
Signed-off-by: Myles Watson mylesgw@gmail.com
Acked-by: Jordan Crouse jordan.crouse@amd.com x 2
Thanks, Myles
Index: adlo/elf/elf-header-065kb.payload
Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream
Property changes on: adlo/elf/elf-header-065kb.payload ___________________________________________________________________ Name: svn:executable
Name: svn:mime-type
- application/octet-stream
Index: adlo/elf/elf-header-068kb.payload
Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream
Property changes on: adlo/elf/elf-header-068kb.payload ___________________________________________________________________ Name: svn:executable
Name: svn:mime-type
- application/octet-stream
Index: adlo/loader.s
--- adlo/loader.s (revision 0) +++ adlo/loader.s (revision 0) @@ -0,0 +1,467 @@ +;***************************************************** +; $Id: loader.s,v 1.1 2002/11/25 02:07:53 rminnich Exp $ +;***************************************************** +USE32 +; code it is loaded into memory at 0x7C00 +;***************************************************** +nop +nop +;***************************************************** +; A) setup GDT, so that we do not depend on program +; that loaded us for GDT. +; Ex: Coreboot and EtherBOOT use different GDT's.
+;----------------------------------------------------- +; 0)
+cli
+;----------------------------------------------------- +; I)
+lgdt [0x7C00+protected_gdt]
+;----------------------------------------------------- +; II) setup CS
+jmp 0x08:0x7C00+newpgdt
+newpgdt: nop
+;----------------------------------------------------- +; III) setup all other segments
+mov ax, #0x10 +mov ss, ax +mov ds, ax +mov es, ax +mov fs, ax +mov gs, ax
+;----------------------------------------------------- +; IV)
+; not now +;sti
+;***************************************************** +nop +nop +;***************************************************** +; B) shadow - ON (enable/read/write)
+mov eax, #0x80000070 +mov dx, #0x0cf8 +out dx, eax
+mov eax, #0xFFFFFFFF +mov dx, #0x0cfc +out dx, eax
+;***************************************************** +nop +nop +;***************************************************** +; C) copy -- boch bios
+; counter - 64kb. +mov ecx, #0x10000
+; source - 0x8000 ( 0x7C00+0x400 = 0x8000 ) +mov ax, #0x10 ; src-segment - 2nd entry in GDT +mov ds, ax +mov eax, #0x8000 ; src-offset - 0x8000 +mov esi, eax
+; destination - 0xF0000 +mov ax, #0x10 ; dst-segment - 2nd entry in GDT +mov es, ax +mov eax, #0xF0000 ; dst-offset - 0xF0000 +mov edi, eax
+; clear direction flag +cld
+; the copy +rep
- movsb
+;***************************************************** +nop +nop +;***************************************************** +; X) copy -- Coreboot table into safe place.
- ;; TODO.
- ;; Q1 : what is the size of table.
- ;; Q2 : where to copy?
+;***************************************************** +nop +nop +;***************************************************** +; E) shadow - OFF (write)
+mov eax, #0x80000070 +mov dx, #0x0cf8 +out dx, eax
+;mov eax, #0xFFFFFFFF +mov eax, #0x0000FFFF +mov dx, #0x0cfc +out dx, eax
+;***************************************************** +nop +nop +;***************************************************** +; F) do a little prep work.
+;----------------------------------------------------- +; I) disable cache
+; if you disable cache, GRUB's GFX mode will be VERY slow. +; so DO NOT DISABLE
+;mov eax, cr0 +;or eax, #0x60000000 +;wbinvd +;mov cr0, eax +;wbinvd
+;----------------------------------------------------- +; II) disable MTRR +; clear the "E" (0x800) and "FE" (0x400) flags in +; IA32_MTRRdefType register (0x2FF)
+;-----------------------
+;mov ECX,#0x2FF
+; select either of the two below +; depending on if your compiler suports +; {RD,WR}MSR or not +;rdmsr +; .byte 0x0F, 0x32
+;xor edx, edx +; xor eax, eax +;and eax, #0xFFFFF3FF
+; select either of the two below +; depending on if your compiler suports +; {RD,WR}MSR or not +;wrmsr +; .byte 0x0F, 0x30
+;----------------------- +;; This is what PC BIOS is setting. -- P6STMT. +; add VIDEO BIOS cacheable!!!! +;----------------------- +; Fixed Range C0--C8 +;mov ECX,#0x268 +;mov EDX,#0x05050505 +;mov EAX,#0x05050505 +;wrmsr +;----------------------- +; Fixed Range C8--CF +;mov ECX,#0x269 +;mov EDX,#0x0 +;mov EAX,#0x05050505 +;wrmsr +;-----------------------
+;----------------------------------------------------- +; III) tell BOCHS' BIOS we want to boot from hdd. +; 0x00 - floppy +; 0x02 - hdd +; It's changed now //With El Torito enabled +; 0x0 - none +; 0x1 - floppy +; 0x2 - hdd +; 0x3 - cdrom +; i.e., 0x23 means try the cdrom first, then the hdd +; In future there will be 'fd failover'option in bochs.
+mov al, #0x3d ;; cmos_reg +out 0x70, al +mov al, #0x23 ;; val (cd then hdd) +out 0x71, al
+;----------------------------------------------------- +; IV) tell BOCHS' BIOS length of our mem block @ 1mb. +; This is for Int 15 / EAX=E820 +; 119mb = 0x77 00 00 00 +; (this is for 128mb of ram) +; (FIXME: this value is currently hard coded) +; (it should be being passed from coreboot )
+; for WinFast 6300 +; 07 70 = 0770 +; 06 80 = 0770 - 00F0 << ALT (for unpatched bochs)
+; for P6STMT - 10kb less ram +; 077F - 10 = 07 6F +; 07 6F - 00 F0 = 06 7F
+mov al, #0x35 ;; cmos_reg +out 0x70, al +mov al, #0x06 ;; val +out 0x71, al
+mov al, #0x34 ;; cmos_reg +out 0x70, al +mov al, #0x7F ;; val +out 0x71, al
+mov al, #0x31 ;; cmos_reg +out 0x70, al +mov al, #0x00 ;; val +out 0x71, al
+mov al, #0x30 ;; cmos_reg +out 0x70, al +mov al, #0x00 ;; val +out 0x71, al
+;----------------------------------------------------- +; V) tell BOCHS' BIOS we want to have LBA translation. +; 0x00 - NONE +; 0x01 - LBA <<<< +; 0x02 - LARGE +; 0x03 - R-CHS +; In future there will be 'fd failover'option in bochs.
+mov al, #0x39 ;; cmos_reg +out 0x70, al +mov al, #0x05 ;; val 5 = (LBA and LBA) 0 = none +out 0x71, al
+;***************************************************** +nop +nop +;***************************************************** +; G) the switch -- protected to real mode
+; IASDM, Vol 3 +; (8-14) 8.8.2 Switching Back to Real-Address Mode
+;===================================================== +; 1) disable interrupts
+cli
+;===================================================== +nop +;===================================================== +; 2) paging
+;not enabled, so not applicable.
+;===================================================== +; 3) setup CS segment limit (64kb) +; I)
+lgdt [0x7C00+new_gdt]
+;----------------------------------------------------- +; II)
+jmp 0x08:0x7C00+new64lim
+new64lim: nop
+;===================================================== +nop +;===================================================== +; 4) setup all other segments
+mov ax, #0x10 +mov ss, ax +mov ds, ax +mov es, ax +mov fs, ax +mov gs, ax
+;===================================================== +nop +;===================================================== +; 5) LIDT +; I)
+; set up Real Mode IDT table (0...3FF)
+; for BOCH's BIOS the address 0xF000:0xFF53 +; cantains value 0xCF which is IRET opcode.
+; counter +mov cx, #0xFF ;1024 bytes(255 interrupts)(4*255=0x3FF)
+; destination - 0x00000 = ES:EDI +mov ax, #0x10 ; dst-segment - 2nd entry in GDT +mov es, ax +mov eax, #0x00000 ; dst-offset - 0x00000 +mov edi, eax
+; data to store -- 0xF000:FF53 +mov eax, #0xF000FF53
+; clear direction flag +cld
+; the store +rep
- stosd
+;----------------------------------------------------- +; II) +; load interrupt descriptor table
+lidt [0x7C00+new_idt]
+;===================================================== +nop +nop +;===================================================== +; 6) clear the PE flag in CR0 register. +; I)
+; switch to 16 bit segments +mov ax, #0x20 +mov ss, ax +mov ds, ax +mov es, ax +mov fs, ax +mov gs, ax
+;----------------------------------------------------- +; II)
+; switch to 16 bit CS
+jmp 0x018:0x7C00+new16bit
+USE16
+new16bit: nop
+;----------------------------------------------------- +; III) +; the switch
+;xor eax, eax
+mov eax, cr0 +and eax, #0xFFFFFFFE +mov cr0, eax ;switch to RM
+;===================================================== +nop +nop +;===================================================== +; 7) far jump -- (to real mode address)
+jmp 0x0:0x7C00+realcs
+realcs: nop
+;===================================================== +; 8) set all segment registers to 0's
+mov ax, #0x0 +mov ss, ax +mov ds, ax +mov es, ax +mov fs, ax +mov gs, ax
+;===================================================== +; 9) re-enable interrupts
+sti
+;***************************************************** +nop +nop +;***************************************************** +; H) jump to BIOS.
+jmp 0xFFFF:0x0000 +;jmp 0xF000:0xFFF0
+;***************************************************** +;***************************************************** +nop +nop +nop +nop +;***************************************************** +;*****************************************************
+USE32
+new_idt: +dw 0x03ff ;; limit 15:00 +dw 0x0000 ;; base 15:00 +dw 0x0000 ;; base 23:16
+new_gdt: +dw 0x0028 ;; limit 15:00 +dw 0x7C00+new_gdt_table ;; base 15:00 +dw 0x0000 ;; base 23:16
+protected_gdt: +dw 0x0018 ;; limit 15:00 +dw 0x7C00+pmode_gdt_table ;; base 15:00 +dw 0x0000 ;; base 23:16
+;-----------------------------------------------------
+new_gdt_table: +;// 1 2 3 4 +;//0 +dd 0x00000000 +dd 0x00000000
+;//8 +dd 0x0000ffff +dd 0x00409E00
+;//10 +dd 0x0000ffff +dd 0x00409200
+;//18 +dd 0x0000ffff +dd 0x00009a00
+;//20 +dd 0x0000ffff +dd 0x00009200
+;-------------------------
+pmode_gdt_table: +;// 1 2 3 4 +;//0 +dd 0x00000000 +dd 0x00000000
+;//8 +dd 0x0000ffff +dd 0x00CF9E00
+;//10 +dd 0x0000ffff +dd 0x00CF9200
+;***************************************************** +;***************************************************** +; the file size must be 1024 bytes.
+.org 0x400-1 +; dd 0xdeadbeef +db 0x0
+;***************************************************** Index: adlo/align.patch =================================================================== --- adlo/align.patch (revision 0) +++ adlo/align.patch (revision 0) @@ -0,0 +1,105 @@ +--- loader.s 2008-02-13 12:12:04.000000000 -0700 ++++ loader_4K.s 2008-04-11 15:57:01.000000000 -0600 +@@ -2,7 +2,7 @@
- ; $Id: loader.s,v 1.1 2002/11/25 02:07:53 rminnich Exp $
- ;*****************************************************
- USE32
+-; code it is loaded into memory at 0x7C00 ++; code it is loaded into memory at 0x7000
- ;*****************************************************
- nop
- nop
+@@ -19,12 +19,12 @@
- ;-----------------------------------------------------
- ; I)
+-lgdt [0x7C00+protected_gdt] ++lgdt [0x7000+protected_gdt]
- ;-----------------------------------------------------
- ; II) setup CS
+-jmp 0x08:0x7C00+newpgdt ++jmp 0x08:0x7000+newpgdt
- newpgdt: nop
+@@ -67,7 +67,7 @@
- ; counter - 64kb.
- mov ecx, #0x10000
+-; source - 0x8000 ( 0x7C00+0x400 = 0x8000 ) ++; source - 0x8000 ( 0x7000+0x1000 = 0x8000 )
- mov ax, #0x10 ; src-segment - 2nd entry in GDT
- mov ds, ax
- mov eax, #0x8000 ; src-offset - 0x8000
+@@ -262,12 +262,12 @@
- ; 3) setup CS segment limit (64kb)
- ; I)
+-lgdt [0x7C00+new_gdt] ++lgdt [0x7000+new_gdt]
- ;-----------------------------------------------------
- ; II)
+-jmp 0x08:0x7C00+new64lim ++jmp 0x08:0x7000+new64lim
- new64lim: nop
+@@ -317,7 +317,7 @@
- ; II)
- ; load interrupt descriptor table
+-lidt [0x7C00+new_idt] ++lidt [0x7000+new_idt]
- ;=====================================================
- nop
+@@ -339,7 +339,7 @@
- ; switch to 16 bit CS
+-jmp 0x018:0x7C00+new16bit ++jmp 0x018:0x7000+new16bit
- USE16
+@@ -361,7 +361,7 @@
- ;=====================================================
- ; 7) far jump -- (to real mode address)
+-jmp 0x0:0x7C00+realcs ++jmp 0x0:0x7000+realcs
- realcs: nop
+@@ -407,12 +407,12 @@
- new_gdt:
- dw 0x0028 ;; limit 15:00
+-dw 0x7C00+new_gdt_table ;; base 15:00 ++dw 0x7000+new_gdt_table ;; base 15:00
- dw 0x0000 ;; base 23:16
- protected_gdt:
- dw 0x0018 ;; limit 15:00
+-dw 0x7C00+pmode_gdt_table ;; base 15:00 ++dw 0x7000+pmode_gdt_table ;; base 15:00
- dw 0x0000 ;; base 23:16
- ;-----------------------------------------------------
+@@ -457,10 +457,10 @@
- ;*****************************************************
- ;*****************************************************
+-; the file size must be 1024 bytes. ++; the file size must be 4096 bytes.
+-.org 0x400-1 ++.org 0x1000-1
- ; dd 0xdeadbeef
- db 0x0
Index: adlo/README
--- adlo/README (revision 0) +++ adlo/README (revision 0) @@ -0,0 +1,145 @@ +This README is based on the ADLO README from coreboot-v2/utils/ADLO/ +You can refer there for other documentation (from 2002) as well.
+ADLO
- A project to combine coreboot and BOCHS BIOS to add support
- for booting legacy applications, such as Microsoft Windows.
+==========================================
+Boot Overvew:
- ADLO requires an boot loader with ELF support.
- In our case it is either coreboot or EtherBOOT.
- Sample execution paths:
+coreboot -> ADLO -> LILO -> LINUX
+coreboot -> EtherBOOT -> ADLO -> LILO -> LINUX
- Then it can start any real mode application.
- In our case it could be LILO or GRUB, but
- choices are not limited to this.
+==========================================
+ADLO overview:
- -Elf header
- -mainteance routines
- -bochs bios
- -vga bios
+------------------------------------------
+Elf header
- hand crafted binary. Currently there are 2 different binaries
- for alignment reasons (kexec needs page alignment).
- they are catted at beginning of file
+------------------------------------------
+maintenance routines
- this is the loader.s file which gets compiled into loader.o binary
- it is catted 2nd right after elf header and it is where
- control is being transfered when the elf is executed.
- it consist of :
-tuneups:select device to bootset memory for Int15/EAX=E820enable LBAcopy coreboot table [TODO]-shadow :enable/write/read-copy:bochs @ 0xF00000video bios (binary only) @ 0xC00000-switchfrom Real to Protected Mode-jumpjmp to the bios at 0xFFFF:0x0000- we must have bios payload always at 1kB or 4kB
- offset from start of ELF payload so loader.o
- must be always 1024 or 4096 bytes.
+------------------------------------------
+BOCHS BIOS
- We have taken the Boch's project and just extracted
- its BIOS from it only. Kevin O'Connor ported it to gcc.
+------------------------------------------
+Video BIOS
- Video BIOS needs to be added to Coreboot. See build instructions there.
+==========================================
+Environment overview
+ADLO is an ELF file and thus can be loaded either directly from 1) +coreboot, or 2) via EtherBOOT, 3) via EtherBOOT+ AA patch for FS +support, or 4) via kexec from a Linux kernel.
+1) +Both coreboot and ADLO are on the same EEPROM chip. From end-user +viewpoint it is probably the most similar to the bios classic. +(computer boots up and just loads whatever is in MBR).
+2) +Set it up in /tftpboot directory on dhcp/tftp server and have it served +from there. (this is how we did the development)
+3) +Use AA patch and put it as /kernel file and it will be then loaded by +etherboot from local hard disk.
+3) +Put Coreboot + kernel in same BIOS image, put adlo.elf in an accessible +filesystem (either in the initrd-rootfs or on local storage.)
+------------------------------------------
+Before ADLO starts.
- ADLO requires an boot loader with ELF support.
- In our case it is:
- -coreboot
- -coreboot and EtherBOOT
- -coreboot and EtherBOOT + AA polled I/O patch (w/ FS support).
- As little as coreboot only is required to get ADLO
- up and running.
- For development purposes it is recommended full set of
- coreboot + EtherBOOT and boot via DHCP/TFTP.
+------------------------------------------
+After ADLO finish.
- ADLO will attempt to boot from the CD-ROM, then if that fails
- locate the first hard disk and read MBR from it and execute.
- Then it can start any real mode application.
- In our case it could be LILO or GRUB
- but choices are not limited to this.
- In our case it would cause LILO to load
- (fully usable) and from there it was able to
- execute simple programs. so far the list
- of the program is limited to linux which
- runs somewhat. More to come in future.
+========================================== Index: adlo/Makefile =================================================================== --- adlo/Makefile (revision 0) +++ adlo/Makefile (revision 0) @@ -0,0 +1,42 @@ +#------------------------------------------------- +# $Id: Makefile,v 1.2 2003/05/22 12:52:38 aip Exp $ +#-------------------------------------------------
+ELF065=elf/elf-header-065kb.payload +ELF068=elf/elf-header-068kb.payload
+LOADER=loader +LOADER_4K=loader_4K
+LOADERS= ${LOADER_4K}.o ${LOADER}.o
+BOCHS_PATH=legacybios
+BIOS=${BOCHS_PATH}/rom.bin
+PAYLOAD=adlo.elf +PAYLOAD_KEXEC=adlo.aligned.elf
+#-------------------------------------------------
+all: ${LOADERS} ${BIOS}
- cat ${ELF065} ${LOADER}.o ${BIOS} > ${PAYLOAD}
- cat ${ELF068} ${LOADER_4K}.o ${BIOS} > ${PAYLOAD_KEXEC}
+#-------------------------------------------------
+${LOADER}.o: ${LOADER}.s
- as86 $< -b $@
+${LOADER_4K}.s: ${LOADER}.s
- patch $< -o $@ < align.patch
+${LOADER_4K}.o: ${LOADER_4K}.s
- as86 $< -b $@
+#-------------------------------------------------
+clean:
- rm -rf *.o ${PAYLOAD} ${PAYLOAD_KEXEC}
- rm -rf ${LOADER_4K}.s
Index: packages/adlo/adlo.mk
--- packages/adlo/adlo.mk (revision 0) +++ packages/adlo/adlo.mk (revision 0) @@ -0,0 +1,65 @@ +ADLO_URL=svn://coreboot.org/repos/trunk/payloads/adlo +ADLO_TAG=3276
+ADLO_DIR=$(BUILD_DIR)/svn +ADLO_SRC_DIR=$(ADLO_DIR)/svn +ADLO_STAMP_DIR=$(ADLO_DIR)/stamps +ADLO_LOG_DIR=$(ADLO_DIR)/logs
+ifeq ($(CONFIG_VERBOSE),y) +ADLO_FETCH_LOG=/dev/stdout +ADLO_BUILD_LOG=/dev/stdout +else +ADLO_BUILD_LOG=$(ADLO_LOG_DIR)/build.log +ADLO_FETCH_LOG=$(ADLO_LOG_DIR)/fetch.log +endif
+# Make sure we have the tools we need to accomplish this +HAVE_AS86:=$(call find-tool,as86)
+ifeq ($(HAVE_AS86),n) +$(error To build ADLO, you need to install as86, available in dev86) +endif
+ADLO_CONFIG=$(PACKAGE_DIR)/adlo/conf/defconfig
+ADLO_TARBALL=adlo-svn-$(ADLO_TAG).tar.gz
+$(SOURCE_DIR)/$(ADLO_TARBALL): | $(ADLO_LOG_DIR)
- @ mkdir -p $(SOURCE_DIR)/adlo
- @ $(BIN_DIR)/fetchsvn.sh $(ADLO_URL) $(SOURCE_DIR)/adlo \
- $(ADLO_TAG) $(SOURCE_DIR)/$(ADLO_TARBALL) \
+$(ADLO_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(ADLO_TARBALL) | $(ADLO_STAMP_DIR) $(ADLO_LOG_DIR) $(ADLO_DIR)
- @ echo "Unpacking adlo..."
- @ tar -C $(ADLO_DIR) -zxf $(SOURCE_DIR)/$(ADLO_TARBALL)
- @ ln -s $(LEGACYBIOS_SRC_DIR)/out/ $(ADLO_DIR)/svn/legacybios
- @ touch $@
+$(ADLO_SRC_DIR)/adlo.elf: $(ADLO_STAMP_DIR)/.unpacked $(LEGACYBIOS_SRC_DIR)/out/rom.bin
- @ echo "Building adlo..."
- @ make -C $(ADLO_SRC_DIR) > $(ADLO_BUILD_LOG) 2>&1
+$(ADLO_STAMP_DIR)/.copied: $(ADLO_SRC_DIR)/adlo.elf
- @ mkdir -p $(shell dirname $(PAYLOAD_ELF))
- @ cp $(ADLO_SRC_DIR)/adlo.elf $(PAYLOAD_ELF)
- @ touch $@
+$(ADLO_STAMP_DIR) $(ADLO_LOG_DIR):
- @ mkdir -p $@
+adlo: $(ADLO_STAMP_DIR)/.copied
+adlo-clean:
- @ echo "Cleaning adlo..."
- @ rm -f $(ADLO_STAMP_DIR)/.copied
+ifneq ($(wildcard $(ADLO_SRC_DIR)/Makefile),)
- @ $(MAKE) -C $(ADLO_SRC_DIR) clean > /dev/null 2>&1
+endif
+adlo-distclean:
- @ rm -rf $(ADLO_DIR)/*
Index: packages/legacybios/legacybios.mk
--- packages/legacybios/legacybios.mk (revision 0) +++ packages/legacybios/legacybios.mk (revision 0) @@ -0,0 +1,56 @@ +LEGACYBIOS_URL=http://linuxtogo.org/~kevin/legacybios/ +LEGACYBIOS_TAG=0.2.0
+LEGACYBIOS_DIR=$(BUILD_DIR)/legacybios +LEGACYBIOS_SRC_DIR=$(LEGACYBIOS_DIR)/legacybios-$(LEGACYBIOS_TAG) +LEGACYBIOS_STAMP_DIR=$(LEGACYBIOS_DIR)/stamps +LEGACYBIOS_LOG_DIR=$(LEGACYBIOS_DIR)/logs
+LEGACYBIOS_PATCHES=
+ifeq ($(CONFIG_VERBOSE),y) +LEGACYBIOS_FETCH_LOG=/dev/stdout +LEGACYBIOS_BUILD_LOG=/dev/stdout +LEGACYBIOS_INSTALL_LOG=/dev/stdout +else +LEGACYBIOS_BUILD_LOG=$(LEGACYBIOS_LOG_DIR)/build.log +LEGACYBIOS_INSTALL_LOG=$(LEGACYBIOS_LOG_DIR)/install.log +LEGACYBIOS_FETCH_LOG=$(LEGACYBIOS_LOG_DIR)/fetch.log +endif
+LEGACYBIOS_TARBALL=legacybios-$(LEGACYBIOS_TAG).tar.gz +LEGACYBIOS_SOURCE=legacybios-$(LEGACYBIOS_TAG).tar.gz
+ifeq ($(shell if [ -f $(PACKAGE_DIR)/legacybios/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1)
- LEGACYBIOS_CONFIG = customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)
+endif
+$(SOURCE_DIR)/$(LEGACYBIOS_TARBALL):
- @ mkdir -p $(SOURCE_DIR)
- @ wget $(WGET_Q) -P $(SOURCE_DIR) $(LEGACYBIOS_URL)/$(LEGACYBIOS_SOURCE) --output-document=$(SOURCE_DIR)/$(LEGACYBIOS_TARBALL)
+$(LEGACYBIOS_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LEGACYBIOS_TARBALL) | $(LEGACYBIOS_STAMP_DIR) $(LEGACYBIOS_DIR) $(LEGACYBIOS_LOG_DIR)
- @ echo "Unpacking legacybios..."
- @ tar -C $(LEGACYBIOS_DIR) -zxf $(SOURCE_DIR)/$(LEGACYBIOS_TARBALL)
- @ touch $@
+$(LEGACYBIOS_SRC_DIR)/out/rom.bin: $(LEGACYBIOS_STAMP_DIR)/.unpacked
- @ echo "Building legacybios..."
- @ echo $(LEGACYBIOS_SRC_DIR)
- @ make -C $(LEGACYBIOS_SRC_DIR) > $(LEGACYBIOS_BUILD_LOG) 2>&1
+$(LEGACYBIOS_STAMP_DIR) $(LEGACYBIOS_LOG_DIR):
- @ mkdir -p $@
+legacybios: $(LEGACYBIOS_SRC_DIR)/out/rom.bin
+legacybios-clean:
- @ echo "Cleaning legacybios..."
- @ rm -f $(LEGACYBIOS_STAMP_DIR)/.copied
+ifneq ($(wildcard $(LEGACYBIOS_SRC_DIR)/Makefile),)
- @ $(MAKE) -C $(LEGACYBIOS_SRC_DIR) clean > /dev/null 2>&1
+endif
+legacybios-distclean:
- @ rm -rf $(LEGACYBIOS_DIR)/*
Index: config/payloads/payloads.conf
--- config/payloads/payloads.conf (revision 170) +++ config/payloads/payloads.conf (working copy) @@ -16,6 +16,7 @@ ### Include the correct payload configuration
PCONF-y= +PCONF-$(CONFIG_PAYLOAD_ADLO) = adlo.conf PCONF-$(CONFIG_PAYLOAD_LAB) = lab.conf PCONF-$(CONFIG_PAYLOAD_ETHERBOOT) = etherboot.conf PCONF-$(CONFIG_PAYLOAD_GPXE) = gpxe.conf @@ -28,6 +29,10 @@ PCONF-$(CONFIG_PAYLOAD_TINT) = tint.conf PCONF-$(CONFIG_PAYLOAD_GRUB2) = grub2.conf
+ifeq ($(PCONF-y),) +$(error No payload .conf file specified.) +endif
DEPENDS-y= include $(CONFIG_DIR)/payloads/$(PCONF-y)
Index: config/payloads/adlo.conf
--- config/payloads/adlo.conf (revision 0) +++ config/payloads/adlo.conf (revision 0) @@ -0,0 +1,15 @@ +# Configuration file for the ADLO payload
+# Common configuration options
+PAYLOAD_BUILD=scripts/Makefile.generic
+PAYLOAD_ELF=$(OUTPUT_DIR)/adlo-payload.elf +PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/adlo-payload.elf.lzma
+PAYLOAD=adlo +PAYLOAD-y=adlo
+# Add legacybios as a dependency +PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/legacybios/legacybios.mk $(PACKAGE_DIR)/adlo/adlo.mk +DEPENDS-y +=legacybios Index: config/payloads/Config.in =================================================================== --- config/payloads/Config.in (revision 170) +++ config/payloads/Config.in (working copy) @@ -9,6 +9,9 @@ help Buildrom can build a number of different payloads for the ROM
+config PAYLOAD_ADLO
- bool "ADLO (Bochs BIOS with a wrapper for Coreboot)"
config PAYLOAD_COREINFO bool "Coreinfo"
On Wed, Apr 30, 2008 at 12:18:38PM -0600, Jordan Crouse wrote:
On 30/04/08 11:21 -0600, Myles Watson wrote:
On Wed, Apr 30, 2008 at 10:18 AM, Jordan Crouse jordan.crouse@amd.com wrote:
On 30/04/08 10:16 -0600, Myles Watson wrote:
-----Original Message----- From: Jordan Crouse [mailto:jordan.crouse@amd.com] Sent: Wednesday, April 30, 2008 10:08 AM To: Myles Watson Cc: Coreboot Subject: Re: ADLO for buildrom
I don't know what the history of the ADLO code is - any reason why we can't give it a home in payloads/ on SVN instead of living in the buildrom code?
I don't think so. The old code was in v2's tree under utils/
I didn't think it was too big of a deal, since it's only one assembly file, a make file, and two elf headers. I admit it looks like a lot with all the documentation.
I'm happy to have it live wherever's best. Who has to set that up?
Its all set up - just push - I recommend payloads/adlo.
Here are two patches. One adds a lightened ADLO to payloads/adlo. The other adds ADLO to buildrom.
The only non-specific change is an error if there is no payload selected, since it causes the build to fail.
Signed-off-by: Myles Watson mylesgw@gmail.com
Acked-by: Jordan Crouse jordan.crouse@amd.com x 2
NACK for now. Let's wait a bit with the ADLO part at least. Why are we copying stuff around partially only? We have coreboot-v2/util/ADLO already. I agree that payloads/adlo/ is the better place for it, but we should simply 'svn mv' it there.
Uwe.
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Uwe Hermann Sent: Wednesday, April 30, 2008 12:32 PM To: Jordan Crouse Cc: Myles Watson; Coreboot Subject: Re: [coreboot] ADLO for buildrom
On Wed, Apr 30, 2008 at 12:18:38PM -0600, Jordan Crouse wrote:
On 30/04/08 11:21 -0600, Myles Watson wrote:
On Wed, Apr 30, 2008 at 10:18 AM, Jordan Crouse
jordan.crouse@amd.com wrote:
On 30/04/08 10:16 -0600, Myles Watson wrote:
-----Original Message----- From: Jordan Crouse [mailto:jordan.crouse@amd.com] Sent: Wednesday, April 30, 2008 10:08 AM To: Myles Watson Cc: Coreboot Subject: Re: ADLO for buildrom
I don't know what the history of the ADLO code is - any reason
why we
can't give it a home in payloads/ on SVN instead of living in the
buildrom
code?
I don't think so. The old code was in v2's tree under utils/
I didn't think it was too big of a deal, since it's only one
assembly file,
a make file, and two elf headers. I admit it looks like a lot
with all the
documentation.
I'm happy to have it live wherever's best. Who has to set that
up?
Its all set up - just push - I recommend payloads/adlo.
Here are two patches. One adds a lightened ADLO to payloads/adlo. The other adds ADLO to buildrom.
The only non-specific change is an error if there is no payload selected, since it causes the build to fail.
Signed-off-by: Myles Watson mylesgw@gmail.com
Acked-by: Jordan Crouse jordan.crouse@amd.com x 2
NACK for now. Let's wait a bit with the ADLO part at least. Why are we copying stuff around partially only? We have coreboot-v2/util/ADLO already. I agree that payloads/adlo/ is the better place for it, but we should simply 'svn mv' it there.
There is very little duplicated here. The ADLO in coreboot relies on building the BOCHS bios from source with dev86, but the payloads/adlo uses the new legacybios version. The only thing that is exactly the same is one of the elf headers.
I'll svn mv that one if you'd like.
Thanks, Myles
On Wed, Apr 30, 2008 at 01:31:33PM -0600, Myles Watson wrote:
There is very little duplicated here. The ADLO in coreboot relies on building the BOCHS bios from source with dev86, but the payloads/adlo uses the new legacybios version. The only thing that is exactly the same is one of the elf headers.
Can you elaborate? I think I never heard of legacybios so far. What's the purpose and history and relation to ADLO of that? Does it _replace_ ADLO completely or enhance it or... ? Also, from a quick glance it doesn't seem to be written specifically for coreboot, what's the original purpose (just curious)?
Do you have a comparison between ADLO as in v2 svn vs. legacybios?
Also note that legacybios is GPLv3, not sure if that's a problem for us. Do we link GPLv2 code against that?
Thanks, Uwe.
-----Original Message----- From: Uwe Hermann [mailto:uwe@hermann-uwe.de] Sent: Wednesday, April 30, 2008 1:49 PM To: Myles Watson Cc: 'Jordan Crouse'; 'Coreboot' Subject: Re: [coreboot] ADLO for buildrom
On Wed, Apr 30, 2008 at 01:31:33PM -0600, Myles Watson wrote:
There is very little duplicated here. The ADLO in coreboot relies on building the BOCHS bios from source with dev86, but the payloads/adlo
uses
the new legacybios version. The only thing that is exactly the same is
one
of the elf headers.
Can you elaborate? I think I never heard of legacybios so far. What's the purpose and history and relation to ADLO of that? Does it _replace_ ADLO completely or enhance it or... ?
I would hope that soon we'll replace the loader from ADLO with one that can be compiled with gcc as well. Then it would completely supersede ADLO.
Also, from a quick glance it doesn't seem to be written specifically for coreboot, what's the original purpose (just curious)?
Legacybios is the Bochs BIOS ported to compile on gcc instead of with the dev86 tools. Kevin's intent (I'm paraphrasing) was to make it easy to update the BIOS so that more developers would be able to fix/improve it. He hoped that the ability to boot operating systems with BIOS callbacks would make Coreboot more popular as well.
Do you have a comparison between ADLO as in v2 svn vs. legacybios?
ADLO in v2 is based on a very old version of Bochs' BIOS that has many timing problems (e.g., small loops that were supposed to wait until the CD spun up.) The new Bochs BIOS as compiled with dev86 is 128K, while Kevin's version is 64K. After compression with lzma this makes it very attractive for a fallback payload to be able to boot from a rescue CD.
Also note that legacybios is GPLv3, not sure if that's a problem for us. Do we link GPLv2 code against that?
I don't know very much about licensing issues. I've copied Kevin on this email. Maybe he'll chip in.
Thanks, Myles
Myles Watson wrote:
Legacybios is the Bochs BIOS ported to compile on gcc instead of with the dev86 tools. Kevin's intent (I'm paraphrasing) was to make it easy to update the BIOS so that more developers would be able to fix/improve it. He hoped that the ability to boot operating systems with BIOS callbacks would make Coreboot more popular as well.
Is it tested and reliable in depth anywhere close to Qemu/Bochs BIOS? Or are we exchanging a fragile piece of code with a fragile and untested one? The latest legacybios (0.2.0) was very bochs/qemu dependent, ie. it expected ram size reported in cmos instead of reading lbtable. We should definitely have a #define COMPILE_FOR_COREBOOT in either legacybios or bochs/qemu bios.
I am all for using legacybios with coreboot, and we should not only use it for ADLO but also for our vga init code (which implements half a legacy bios, too) And for loading blocks from SCSI controllers with int13.
Lets clean this up once and forever.
I am copying Zhang Rui on this mail. He is the guy who is going to work on booting from SCSI (or, more generically int13 callback based boot devices) for our GSoC project.
ADLO in v2 is based on a very old version of Bochs' BIOS that has many timing problems (e.g., small loops that were supposed to wait until the CD spun up.) The new Bochs BIOS as compiled with dev86 is 128K, while Kevin's version is 64K. After compression with lzma this makes it very attractive for a fallback payload to be able to boot from a rescue CD.
ADLO itself is just the assembler loader. It is not at all based on any legacy bios. Last years GSoC used ADLO with the latest BOCHS bios to boot more flavours of windows
On Thu, May 01, 2008 at 01:58:50AM +0200, Stefan Reinauer wrote:
Myles Watson wrote:
Legacybios is the Bochs BIOS ported to compile on gcc instead of with the dev86 tools. Kevin's intent (I'm paraphrasing) was to make it easy to update the BIOS so that more developers would be able to fix/improve it. He hoped that the ability to boot operating systems with BIOS callbacks would make Coreboot more popular as well.
Thanks Myles, that is a good summary.
Is it tested and reliable in depth anywhere close to Qemu/Bochs BIOS? Or are we exchanging a fragile piece of code with a fragile and untested one?
What I have tested: booting linux, freedos, netbsd from floppy, cdrom, and hard drives from qemu. I have reports of Windows XP working as well.
The latest legacybios (0.2.0) was very bochs/qemu dependent, ie. it expected ram size reported in cmos instead of reading lbtable. We should definitely have a #define COMPILE_FOR_COREBOOT in either legacybios or bochs/qemu bios.
The legacybios code is currently just a port of bochs bios to gcc. I know of no additional hardware restrictions that it imposes.
I'm working on going through all the external hardware dependencies that bochs bios/legacybios impose - I plan to send an email when I have the list completed.
Unfortunately, my home machine "blew up" some time back, and the headache of getting a replacement machine has set me back about a month. :-(
-Kevin
On Wed, Apr 30, 2008 at 09:53:43PM -0400, Kevin O'Connor wrote:
On Thu, May 01, 2008 at 01:58:50AM +0200, Stefan Reinauer wrote:
Myles Watson wrote:
Legacybios is the Bochs BIOS ported to compile on gcc instead of with the dev86 tools. Kevin's intent (I'm paraphrasing) was to make it easy to update the BIOS so that more developers would be able to fix/improve it. He
What's the long-term plan? Will legacybios replace the current BOCHS BIOS in bochs also?
hoped that the ability to boot operating systems with BIOS callbacks would make Coreboot more popular as well.
Definately!
Thanks Myles, that is a good summary.
Is it tested and reliable in depth anywhere close to Qemu/Bochs BIOS? Or are we exchanging a fragile piece of code with a fragile and untested one?
What I have tested: booting linux, freedos, netbsd from floppy, cdrom, and hard drives from qemu. I have reports of Windows XP working as well.
Testing should not be a problem, I think we can test lots of stuff in QEMU soonish. The really interesting issues will pop up when testing on actual hardware, though. I'll do that over the next few days with various payloads / OSes.
I'm working on going through all the external hardware dependencies that bochs bios/legacybios impose - I plan to send an email when I have the list completed.
Great, thanks!
Let us know if you need more info or some testing on coreboot-enabled hardware, many developers here may be able to help.
Uwe.
Hi Uwe,
Sorry, I missed this question.
On Thu, May 01, 2008 at 05:23:54PM +0200, Uwe Hermann wrote:
What's the long-term plan? Will legacybios replace the current BOCHS BIOS in bochs also?
The bochs developers are aware of my work. However, it seems as if there aren't that many developers working on bochs. As a guess, more developers have gravitated to qemu and kvm. Looking at mailing list traffic, one will note coreboot, kvm, and qemu all have significantly higher traffic than bochs does.
Further, I'm sure some emulator developers would question the risk involved in adopting a new bios. The existing bios works fine for them - why change it? The risks are different when trying to get the bios to work on real hardware - that requires the ability to enhance and debug the bios. New development is, in my opinion, impractical with the existing asm/bcc based code.
In any case, I will continue to keep both bochs and qemu working with the bios code. Having more users for a code base makes testing and overall maintenance easier.
-Kevin
Also note that legacybios is GPLv3, not sure if that's a problem for us. Do we link GPLv2 code against that?
I reread this part. Sorry I didn't answer it before.
There's no linking involved. All we do is load it into memory and jump to it.
Thanks, Myles
Uwe Hermann wrote:
On Wed, Apr 30, 2008 at 01:31:33PM -0600, Myles Watson wrote:
There is very little duplicated here. The ADLO in coreboot relies on building the BOCHS bios from source with dev86, but the payloads/adlo uses the new legacybios version. The only thing that is exactly the same is one of the elf headers.
Can you elaborate? I think I never heard of legacybios so far. What's the purpose and history and relation to ADLO of that? Does it _replace_ ADLO completely or enhance it or... ? Also, from a quick glance it doesn't seem to be written specifically for coreboot, what's the original purpose (just curious)?
Do you have a comparison between ADLO as in v2 svn vs. legacybios?
Please please please do not make 5 trees in 5 places with different copies of ADLO and its legacy bios. This is not the way to go.
1. if it needs to be moved to payloads/ lets move it. 2. if we should switch to legacybios from Kevin O'Connor let's do this too, or lets leave a choice.
Also note that legacybios is GPLv3, not sure if that's a problem for us. Do we link GPLv2 code against that?
It's not linked in at any point. It's loaded. Just like the linux kernel loads ELF files. At least for v3 we can say for sure.
Myles Watson wrote:
There is very little duplicated here. The ADLO in coreboot relies on building the BOCHS bios from source with dev86, but the payloads/adlo uses the new legacybios version. The only thing that is exactly the same is one of the elf headers.
please also note we have a gsoc student working on legacy bios integration again this summer. maybe we should stop the plenty discussion here and leave things as they are until that project is done?
Does legacybios from Kevin O'Connor boot Vista?
On Thu, May 01, 2008 at 01:47:17AM +0200, Stefan Reinauer wrote:
Does legacybios from Kevin O'Connor boot Vista?
I don't have any reports either way. I don't own Vista so can't test for myself. I do hope to get a copy to test with.
If Bochs Bios can boot Vista I would think legacybios could as well, and vice-versa.
-Kevin
-----Original Message----- From: Stefan Reinauer [mailto:stepan@coresystems.de] Sent: Wednesday, April 30, 2008 5:47 PM To: Myles Watson Cc: 'Uwe Hermann'; 'Jordan Crouse'; 'Coreboot' Subject: Re: [coreboot] ADLO for buildrom
Myles Watson wrote:
There is very little duplicated here. The ADLO in coreboot relies on building the BOCHS bios from source with dev86, but the payloads/adlo
uses
the new legacybios version. The only thing that is exactly the same is
one
of the elf headers.
please also note we have a gsoc student working on legacy bios integration again this summer. maybe we should stop the plenty discussion here and leave things as they are until that project is done?
It's not soon enough for me. It works now in QEMU, even though there is a lot to be improved. I'd like to put it into buildrom so that it is easy to hack on.
Does legacybios from Kevin O'Connor boot Vista?
It probably does in QEMU, but not the 64-bit version. The last I heard that was the status of the Bochs BIOS.
Thanks, Myles
Myles Watson wrote:
It's not soon enough for me. It works now in QEMU, even though there is a lot to be improved. I'd like to put it into buildrom so that it is easy to hack on.
"It"?
ADLO has been in our CVS/SVN repo since 2002. It should not be hard to hack on it...
Does legacybios from Kevin O'Connor boot Vista?
It probably does in QEMU, but not the 64-bit version. The last I heard that was the status of the Bochs BIOS.
When I booted vista, i could interestingly only boot the 64bit version in qemu but even that needed a bunch of patches.
I suggest we wait until legacybios becomes the standard bios of qemu before we try to replace a well tested implementation with it.
-----Original Message----- From: Stefan Reinauer [mailto:stepan@coresystems.de] Sent: Thursday, May 01, 2008 9:43 AM To: Myles Watson Cc: 'Jordan Crouse'; 'Coreboot' Subject: Re: [coreboot] ADLO for buildrom
Myles Watson wrote:
It's not soon enough for me. It works now in QEMU, even though there is
a
lot to be improved. I'd like to put it into buildrom so that it is easy
to
hack on.
"It"?
ADLO has been in our CVS/SVN repo since 2002. It should not be hard to hack on it...
The first thing I would do is remove all of the BIOS code since it's old and relies on the old toolchain. I thought it would be easier to add a couple of small files to payloads/ then to get approval to blow away the code in utils/ even though it is unused and outdated.
I never know what's going to be an easy/hard sell.
Does legacybios from Kevin O'Connor boot Vista?
It probably does in QEMU, but not the 64-bit version. The last I heard
that
was the status of the Bochs BIOS.
When I booted vista, i could interestingly only boot the 64bit version in qemu but even that needed a bunch of patches.
That's great that it boots 64-bit Vista, patches and all!
I suggest we wait until legacybios becomes the standard bios of qemu before we try to replace a well tested implementation with it.
The Bochs BIOS project is having a hard time finding anyone to review their patches because of the tool chain, but there is little impetus for them to switch to Kevin's port. We could be that impetus. Very few people have been using ADLO from Coreboot. When I fixed the delays and the ATA handling so that it worked in hardware, the response was "get it patched upstream." I've done that, but no one has cared enough to pull down the new version into our tree.
I think the only part that needs to live in our tree is the wrapper that passes information from Coreboot to the Bochs BIOS (however that's done.) We win by using a payload that is not special purpose just for us.
Thanks, Myles
Jordan Crouse wrote:
On 30/04/08 11:21 -0600, Myles Watson wrote:
On Wed, Apr 30, 2008 at 10:18 AM, Jordan Crouse jordan.crouse@amd.com wrote:
On 30/04/08 10:16 -0600, Myles Watson wrote:
-----Original Message----- From: Jordan Crouse [mailto:jordan.crouse@amd.com] Sent: Wednesday, April 30, 2008 10:08 AM To: Myles Watson Cc: Coreboot Subject: Re: ADLO for buildrom
I don't know what the history of the ADLO code is - any reason why we can't give it a home in payloads/ on SVN instead of living in the buildrom code?
I don't think so. The old code was in v2's tree under utils/
I didn't think it was too big of a deal, since it's only one assembly file, a make file, and two elf headers. I admit it looks like a lot with all the documentation.
I'm happy to have it live wherever's best. Who has to set that up?
Its all set up - just push - I recommend payloads/adlo.
Here are two patches. One adds a lightened ADLO to payloads/adlo. The other adds ADLO to buildrom.
The only non-specific change is an error if there is no payload selected, since it causes the build to fail.
Signed-off-by: Myles Watson mylesgw@gmail.com
Acked-by: Jordan Crouse jordan.crouse@amd.com x 2
If you're going to add it to payloads/ please remove it from utils/ - we don't need several copies floating around.
On Wed, Apr 30, 2008 at 11:21:48AM -0600, Myles Watson wrote:
Here are two patches. One adds a lightened ADLO to payloads/adlo. The other adds ADLO to buildrom.
The only non-specific change is an error if there is no payload selected, since it causes the build to fail.
Signed-off-by: Myles Watson mylesgw@gmail.com
Great work, thanks! Quick review below:
Index: adlo/elf/elf-header-065kb.payload Index: adlo/elf/elf-header-068kb.payload
Not sure I like storing blobs in svn. How were they generated? If possible we should store the "source" or some scripts which generates them on-the-fly in svn? This won't hold up a commit though, can be done later. Hm, seems they're hand-crafted, but I'd still like a small script which "crafts" them better than storing blobs nobody can read or understand.
Also, v2's ADLO has three of those, what's the difference to these?
Index: adlo/loader.s
--- adlo/loader.s (revision 0) +++ adlo/loader.s (revision 0) @@ -0,0 +1,467 @@ +;***************************************************** +; $Id: loader.s,v 1.1 2002/11/25 02:07:53 rminnich Exp $ +;*****************************************************
Hm, who wrote this code originally and what license applies?
Juding from http://tracker.coreboot.org/trac/coreboot/log/trunk/LinuxBIOSv1/util/ADLO?re... http://tracker.coreboot.org/trac/coreboot/browser/trunk/LinuxBIOSv1/util/ADL... http://tracker.coreboot.org/trac/coreboot/browser/trunk/LinuxBIOSv1/util/ADL... it seems the code was checked in by Ron, but actually implemented by Adam Sulmicki with the help of others:
"Most of the analysis, design and implementation of the project was done by me, Adam Sulmicki."
Is this correct?
There's a copy of the GPLv2 in the original ADLO directory, so I think we can safely assume the code to be GPLv2, right?
Index: adlo/align.patch
--- adlo/align.patch (revision 0) +++ adlo/align.patch (revision 0) @@ -0,0 +1,105 @@ +--- loader.s 2008-02-13 12:12:04.000000000 -0700 ++++ loader_4K.s 2008-04-11 15:57:01.000000000 -0600 +@@ -2,7 +2,7 @@
- ; $Id: loader.s,v 1.1 2002/11/25 02:07:53 rminnich Exp $
- ;*****************************************************
- USE32
+-; code it is loaded into memory at 0x7C00 ++; code it is loaded into memory at 0x7000
Why? Please explain. Is this board-specific or payload-specific? Can it be a variable, selectable in a config file later? Surely in buildrom, but also for manual builds...
Index: packages/adlo/adlo.mk
--- packages/adlo/adlo.mk (revision 0) +++ packages/adlo/adlo.mk (revision 0)
[...]
+ifeq ($(CONFIG_VERBOSE),y) +ADLO_FETCH_LOG=/dev/stdout +ADLO_BUILD_LOG=/dev/stdout +else +ADLO_BUILD_LOG=$(ADLO_LOG_DIR)/build.log +ADLO_FETCH_LOG=$(ADLO_LOG_DIR)/fetch.log +endif
Unrelated, but this stuff is pretty generic in all buildrom "packages", might be worth to move to a generic *.inc file later...
+# Make sure we have the tools we need to accomplish this +HAVE_AS86:=$(call find-tool,as86)
+ifeq ($(HAVE_AS86),n) +$(error To build ADLO, you need to install as86, available in dev86) +endif
This is needed for ADLO but not legacybios? Can we also change ADLO to not require it, or is that impossible?
+ADLO_CONFIG=$(PACKAGE_DIR)/adlo/conf/defconfig
There's no such file in your patch, unless I'm missing something.
+ADLO_TARBALL=adlo-svn-$(ADLO_TAG).tar.gz
+$(SOURCE_DIR)/$(ADLO_TARBALL): | $(ADLO_LOG_DIR)
- @ mkdir -p $(SOURCE_DIR)/adlo
- @ $(BIN_DIR)/fetchsvn.sh $(ADLO_URL) $(SOURCE_DIR)/adlo \
- $(ADLO_TAG) $(SOURCE_DIR)/$(ADLO_TARBALL) \
+$(ADLO_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(ADLO_TARBALL) | $(ADLO_STAMP_DIR) $(ADLO_LOG_DIR) $(ADLO_DIR)
- @ echo "Unpacking adlo..."
Let's use "ADLO" in strings everywhere, as that seems to be the "official" name.
- @ tar -C $(ADLO_DIR) -zxf $(SOURCE_DIR)/$(ADLO_TARBALL)
- @ ln -s $(LEGACYBIOS_SRC_DIR)/out/ $(ADLO_DIR)/svn/legacybios
- @ touch $@
+$(ADLO_SRC_DIR)/adlo.elf: $(ADLO_STAMP_DIR)/.unpacked $(LEGACYBIOS_SRC_DIR)/out/rom.bin
- @ echo "Building adlo..."
See above.
- @ make -C $(ADLO_SRC_DIR) > $(ADLO_BUILD_LOG) 2>&1
+$(ADLO_STAMP_DIR)/.copied: $(ADLO_SRC_DIR)/adlo.elf
- @ mkdir -p $(shell dirname $(PAYLOAD_ELF))
- @ cp $(ADLO_SRC_DIR)/adlo.elf $(PAYLOAD_ELF)
- @ touch $@
+$(ADLO_STAMP_DIR) $(ADLO_LOG_DIR):
- @ mkdir -p $@
+adlo: $(ADLO_STAMP_DIR)/.copied
+adlo-clean:
- @ echo "Cleaning adlo..."
Ditto.
- @ rm -f $(ADLO_STAMP_DIR)/.copied
+ifneq ($(wildcard $(ADLO_SRC_DIR)/Makefile),)
- @ $(MAKE) -C $(ADLO_SRC_DIR) clean > /dev/null 2>&1
+endif
+adlo-distclean:
- @ rm -rf $(ADLO_DIR)/*
Index: packages/legacybios/legacybios.mk
--- packages/legacybios/legacybios.mk (revision 0) +++ packages/legacybios/legacybios.mk (revision 0)
[...]
+LEGACYBIOS_TARBALL=legacybios-$(LEGACYBIOS_TAG).tar.gz +LEGACYBIOS_SOURCE=legacybios-$(LEGACYBIOS_TAG).tar.gz
Why are both needed?
+ifeq ($(shell if [ -f $(PACKAGE_DIR)/legacybios/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1)
- LEGACYBIOS_CONFIG = customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)
+endif
+$(SOURCE_DIR)/$(LEGACYBIOS_TARBALL):
- @ mkdir -p $(SOURCE_DIR)
- @ wget $(WGET_Q) -P $(SOURCE_DIR) $(LEGACYBIOS_URL)/$(LEGACYBIOS_SOURCE) --output-document=$(SOURCE_DIR)/$(LEGACYBIOS_TARBALL)
Not too important, but I'd use -O instead of --output-document, it's shorter and the rest of the code also uses -O.
+$(LEGACYBIOS_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LEGACYBIOS_TARBALL) | $(LEGACYBIOS_STAMP_DIR) $(LEGACYBIOS_DIR) $(LEGACYBIOS_LOG_DIR)
- @ echo "Unpacking legacybios..."
- @ tar -C $(LEGACYBIOS_DIR) -zxf $(SOURCE_DIR)/$(LEGACYBIOS_TARBALL)
- @ touch $@
+$(LEGACYBIOS_SRC_DIR)/out/rom.bin: $(LEGACYBIOS_STAMP_DIR)/.unpacked
- @ echo "Building legacybios..."
- @ echo $(LEGACYBIOS_SRC_DIR)
- @ make -C $(LEGACYBIOS_SRC_DIR) > $(LEGACYBIOS_BUILD_LOG) 2>&1
Doesn't work for me.
Adding 'AVOIDCOMBINE=1' as per legacybios README helps, but there are still build failures on my box (x86, Linux):
src/romlayout.S: Assembler messages: src/romlayout.S:427: Error: attempt to .org/.space backwards? (-1) src/romlayout.S:490: Fatal error: can't write out/romlayout16.o: Bad value make[1]: *** [out/romlayout16.o] Error 1
Any ideas?
+$(LEGACYBIOS_STAMP_DIR) $(LEGACYBIOS_LOG_DIR):
- @ mkdir -p $@
+legacybios: $(LEGACYBIOS_SRC_DIR)/out/rom.bin
+legacybios-clean:
- @ echo "Cleaning legacybios..."
- @ rm -f $(LEGACYBIOS_STAMP_DIR)/.copied
+ifneq ($(wildcard $(LEGACYBIOS_SRC_DIR)/Makefile),)
- @ $(MAKE) -C $(LEGACYBIOS_SRC_DIR) clean > /dev/null 2>&1
+endif
+legacybios-distclean:
- @ rm -rf $(LEGACYBIOS_DIR)/*
Index: config/payloads/Config.in
--- config/payloads/Config.in (revision 170) +++ config/payloads/Config.in (working copy) @@ -9,6 +9,9 @@ help Buildrom can build a number of different payloads for the ROM
+config PAYLOAD_ADLO
- bool "ADLO (Bochs BIOS with a wrapper for Coreboot)"
Maybe something like
bool "ADLO (x86 legacy BIOS on top of coreboot)"
Or just "ADLO" and add more info the kconfig help.
HTH, Uwe.
On Wed, Apr 30, 2008 at 11:01:24PM +0200, Uwe Hermann wrote:
+$(LEGACYBIOS_SRC_DIR)/out/rom.bin: $(LEGACYBIOS_STAMP_DIR)/.unpacked
- @ echo "Building legacybios..."
- @ echo $(LEGACYBIOS_SRC_DIR)
- @ make -C $(LEGACYBIOS_SRC_DIR) > $(LEGACYBIOS_BUILD_LOG) 2>&1
Doesn't work for me.
Adding 'AVOIDCOMBINE=1' as per legacybios README helps, but there are still build failures on my box (x86, Linux):
src/romlayout.S: Assembler messages: src/romlayout.S:427: Error: attempt to .org/.space backwards? (-1) src/romlayout.S:490: Fatal error: can't write out/romlayout16.o: Bad value make[1]: *** [out/romlayout16.o] Error 1
Any ideas?
OK, this is a solved problem.
The 0.2.0 version works with gcc 4.1 but not with 4.2 or 4.3. However, the current git version _does_ work fine with all of them, (well, with gcc >= 4.1 at least).
I think we should move to not wget the tarball but rather get specific git versions to make grabbing fixes from git easier (if no release happens early enough for our purposes).
http://linuxtogo.org/cgi-bin/gitweb.cgi http://linuxtogo.org/cgi-bin/gitweb.cgi?p=kevin/legacybios.git;a=summary
Uwe.
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Uwe Hermann Sent: Wednesday, April 30, 2008 4:09 PM To: Myles Watson; Jordan Crouse Cc: Coreboot Subject: Re: [coreboot] ADLO for buildrom
On Wed, Apr 30, 2008 at 11:01:24PM +0200, Uwe Hermann wrote:
+$(LEGACYBIOS_SRC_DIR)/out/rom.bin: $(LEGACYBIOS_STAMP_DIR)/.unpacked
- @ echo "Building legacybios..."
- @ echo $(LEGACYBIOS_SRC_DIR)
- @ make -C $(LEGACYBIOS_SRC_DIR) > $(LEGACYBIOS_BUILD_LOG) 2>&1
Doesn't work for me.
Adding 'AVOIDCOMBINE=1' as per legacybios README helps, but there are still build failures on my box (x86, Linux):
src/romlayout.S: Assembler messages: src/romlayout.S:427: Error: attempt to .org/.space backwards? (-1) src/romlayout.S:490: Fatal error: can't write out/romlayout16.o: Bad
value
make[1]: *** [out/romlayout16.o] Error 1
Any ideas?
OK, this is a solved problem.
The 0.2.0 version works with gcc 4.1 but not with 4.2 or 4.3. However, the current git version _does_ work fine with all of them, (well, with gcc >= 4.1 at least).
I think we should move to not wget the tarball but rather get specific git versions to make grabbing fixes from git easier (if no release happens early enough for our purposes).
I'd rather not live on the edge. Since it's a one-developer project we should be able to talk him into releases when there's a major change and it's stabilized, but if it's important to you we can change it.
Myles
On Wed, Apr 30, 2008 at 04:23:47PM -0600, Myles Watson wrote:
I think we should move to not wget the tarball but rather get specific git versions to make grabbing fixes from git easier (if no release happens early enough for our purposes).
I'd rather not live on the edge. Since it's a one-developer project we should be able to talk him into releases when there's a major change and it's stabilized, but if it's important to you we can change it.
Yes please, I'd really like to get the code via git. We don't _have_ to use HEAD or always update to the latest git version, but we have the _chance_ to easily update to a newer version, no matter if there's a tarball or not.
I'm fine using the git version which corresponds to a released tarball in the normal case, but for now (in order to get the fixes for gcc 4.2/4.3) I'd say we use the currently latest git.
Uwe.
On 01/05/08 01:27 +0200, Uwe Hermann wrote:
On Wed, Apr 30, 2008 at 04:23:47PM -0600, Myles Watson wrote:
I think we should move to not wget the tarball but rather get specific git versions to make grabbing fixes from git easier (if no release happens early enough for our purposes).
I'd rather not live on the edge. Since it's a one-developer project we should be able to talk him into releases when there's a major change and it's stabilized, but if it's important to you we can change it.
Yes please, I'd really like to get the code via git. We don't _have_ to use HEAD or always update to the latest git version, but we have the _chance_ to easily update to a newer version, no matter if there's a tarball or not.
I'm fine using the git version which corresponds to a released tarball in the normal case, but for now (in order to get the fixes for gcc 4.2/4.3) I'd say we use the currently latest git.
I just want to say - fear the git fetcher in buildrom. There be dragons.
Jordan
I'm fine using the git version which corresponds to a released tarball in the normal case, but for now (in order to get the fixes for gcc 4.2/4.3) I'd say we use the currently latest git.
This patch updates the legacybios version to 2.2 (the latest) and thus avoids git.
I just want to say - fear the git fetcher in buildrom. There be dragons.
Jordan
This patch addresses most concerns not related to the loader. I hope that it will be rewritten soon. The payloads.adlo.diff patch is the same as the last. I'm including it for completeness.
I think that committing this into the repository is worth the 20K. It has already generated more discussion than ADLO has for a long time. The ease of using it with buildrom should speed testing and bug fixing.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
On Thu, May 01, 2008 at 01:27:26AM +0200, Uwe Hermann wrote:
On Wed, Apr 30, 2008 at 04:23:47PM -0600, Myles Watson wrote:
I'd rather not live on the edge. Since it's a one-developer project we should be able to talk him into releases when there's a major change and it's stabilized, but if it's important to you we can change it.
Yes please, I'd really like to get the code via git. We don't _have_ to use HEAD or always update to the latest git version, but we have the _chance_ to easily update to a newer version, no matter if there's a tarball or not.
I'm fine using the git version which corresponds to a released tarball in the normal case, but for now (in order to get the fixes for gcc 4.2/4.3) I'd say we use the currently latest git.
I tagged 'rel-0.2.2' today. I also uploaded tar files and compiled binaries to:
http://linuxtogo.org/~kevin/legacybios/
-Kevin
-----Original Message----- From: Uwe Hermann [mailto:uwe@hermann-uwe.de] Sent: Wednesday, April 30, 2008 3:01 PM To: Myles Watson Cc: Jordan Crouse; Coreboot Subject: Re: [coreboot] ADLO for buildrom
On Wed, Apr 30, 2008 at 11:21:48AM -0600, Myles Watson wrote:
Here are two patches. One adds a lightened ADLO to payloads/adlo. The other adds ADLO to buildrom.
The only non-specific change is an error if there is no payload selected, since it causes the build to fail.
Signed-off-by: Myles Watson mylesgw@gmail.com
Great work, thanks! Quick review below:
Sure. Thanks for the comments.
Index: adlo/elf/elf-header-065kb.payload Index: adlo/elf/elf-header-068kb.payload
Not sure I like storing blobs in svn. How were they generated?
By hand with a hex editor.
If
possible we should store the "source" or some scripts which generates them on-the-fly in svn? This won't hold up a commit though, can be done later. Hm, seems they're hand-crafted, but I'd still like a small script which "crafts" them better than storing blobs nobody can read or understand.
I'd love a script that crafts them. Using readelf -a and trial and error gets old.
Also, v2's ADLO has three of those, what's the difference to these?
There used to be a 64K payload for the 16-bit BIOS and a 128K payload for the 32-bit BIOS that added other features like ACPI. Now the 32-bit BIOS fits into 64K, so no need for the 128-bit ELF headers. The reason there are two is that I hope to be able to use kexec to load ADLO so that the kernel can initialize all the hardware on the motherboard correctly. Kexec can't handle ELFs that have data that isn't page-aligned. The 68K payload has that 4K-aligned loader.
Index: adlo/loader.s
--- adlo/loader.s (revision 0) +++ adlo/loader.s (revision 0) @@ -0,0 +1,467 @@ +;***************************************************** +; $Id: loader.s,v 1.1 2002/11/25 02:07:53 rminnich Exp $ +;*****************************************************
Hm, who wrote this code originally and what license applies?
Juding from
http://tracker.coreboot.org/trac/coreboot/log/trunk/LinuxBIOSv1/util/ADLO? rev=702
http://tracker.coreboot.org/trac/coreboot/browser/trunk/LinuxBIOSv1/util/A DLO/README.1st?rev=702
http://tracker.coreboot.org/trac/coreboot/browser/trunk/LinuxBIOSv1/util/A DLO/CAST?rev=702 it seems the code was checked in by Ron, but actually implemented by Adam Sulmicki with the help of others:
"Most of the analysis, design and implementation of the project was done by me, Adam Sulmicki."
Is this correct?
Good question. I haven't been around this project that long. Ron?
I'm hoping we'll replace it very soon, though.
There's a copy of the GPLv2 in the original ADLO directory, so I think we can safely assume the code to be GPLv2, right?
I would assume that too.
Index: adlo/align.patch
--- adlo/align.patch (revision 0) +++ adlo/align.patch (revision 0) @@ -0,0 +1,105 @@ +--- loader.s 2008-02-13 12:12:04.000000000 -0700 ++++ loader_4K.s 2008-04-11 15:57:01.000000000 -0600 +@@ -2,7 +2,7 @@
- ; $Id: loader.s,v 1.1 2002/11/25 02:07:53 rminnich Exp $
- ;*****************************************************
- USE32
+-; code it is loaded into memory at 0x7C00 ++; code it is loaded into memory at 0x7000
Why? Please explain. Is this board-specific or payload-specific? Can it be a variable, selectable in a config file later? Surely in buildrom, but also for manual builds...
This is part of what should go away. The BIOS has to get loaded at the correct address for callbacks to work. This loader needs to get loaded somewhere else, then copy its payload to the right spot. I'd love for the loading part to get taken over by Coreboot. Then we could just set up the CMOS values separately and not depend on being loaded into a hard-coded location in RAM.
Index: packages/adlo/adlo.mk
--- packages/adlo/adlo.mk (revision 0) +++ packages/adlo/adlo.mk (revision 0)
[...]
+ifeq ($(CONFIG_VERBOSE),y) +ADLO_FETCH_LOG=/dev/stdout +ADLO_BUILD_LOG=/dev/stdout +else +ADLO_BUILD_LOG=$(ADLO_LOG_DIR)/build.log +ADLO_FETCH_LOG=$(ADLO_LOG_DIR)/fetch.log +endif
Unrelated, but this stuff is pretty generic in all buildrom "packages", might be worth to move to a generic *.inc file later...
I agree.
+# Make sure we have the tools we need to accomplish this +HAVE_AS86:=$(call find-tool,as86)
+ifeq ($(HAVE_AS86),n) +$(error To build ADLO, you need to install as86, available in dev86) +endif
This is needed for ADLO but not legacybios? Can we also change ADLO to not require it, or is that impossible?
I hope someone will do it soon. It would take me some time, since I'm not really familiar with assembly, but it really isn't too much code.
+ADLO_CONFIG=$(PACKAGE_DIR)/adlo/conf/defconfig
There's no such file in your patch, unless I'm missing something.
Yep. I'll remove that line.
+ADLO_TARBALL=adlo-svn-$(ADLO_TAG).tar.gz
+$(SOURCE_DIR)/$(ADLO_TARBALL): | $(ADLO_LOG_DIR)
- @ mkdir -p $(SOURCE_DIR)/adlo
- @ $(BIN_DIR)/fetchsvn.sh $(ADLO_URL) $(SOURCE_DIR)/adlo \
- $(ADLO_TAG) $(SOURCE_DIR)/$(ADLO_TARBALL) \
+$(ADLO_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(ADLO_TARBALL) |
$(ADLO_STAMP_DIR) $(ADLO_LOG_DIR) $(ADLO_DIR)
- @ echo "Unpacking adlo..."
Let's use "ADLO" in strings everywhere, as that seems to be the "official" name.
Sure. Once we replace the loader there will be nothing left of the original but the name, but the name's fine.
- @ tar -C $(ADLO_DIR) -zxf $(SOURCE_DIR)/$(ADLO_TARBALL)
- @ ln -s $(LEGACYBIOS_SRC_DIR)/out/ $(ADLO_DIR)/svn/legacybios
- @ touch $@
+$(ADLO_SRC_DIR)/adlo.elf: $(ADLO_STAMP_DIR)/.unpacked
$(LEGACYBIOS_SRC_DIR)/out/rom.bin
- @ echo "Building adlo..."
See above.
- @ make -C $(ADLO_SRC_DIR) > $(ADLO_BUILD_LOG) 2>&1
+$(ADLO_STAMP_DIR)/.copied: $(ADLO_SRC_DIR)/adlo.elf
- @ mkdir -p $(shell dirname $(PAYLOAD_ELF))
- @ cp $(ADLO_SRC_DIR)/adlo.elf $(PAYLOAD_ELF)
- @ touch $@
+$(ADLO_STAMP_DIR) $(ADLO_LOG_DIR):
- @ mkdir -p $@
+adlo: $(ADLO_STAMP_DIR)/.copied
+adlo-clean:
- @ echo "Cleaning adlo..."
Ditto.
- @ rm -f $(ADLO_STAMP_DIR)/.copied
+ifneq ($(wildcard $(ADLO_SRC_DIR)/Makefile),)
- @ $(MAKE) -C $(ADLO_SRC_DIR) clean > /dev/null 2>&1
+endif
+adlo-distclean:
- @ rm -rf $(ADLO_DIR)/*
Index: packages/legacybios/legacybios.mk
--- packages/legacybios/legacybios.mk (revision 0) +++ packages/legacybios/legacybios.mk (revision 0)
[...]
+LEGACYBIOS_TARBALL=legacybios-$(LEGACYBIOS_TAG).tar.gz +LEGACYBIOS_SOURCE=legacybios-$(LEGACYBIOS_TAG).tar.gz
Why are both needed?
+ifeq ($(shell if [ -f $(PACKAGE_DIR)/legacybios/conf/customconfig--
$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1)
- LEGACYBIOS_CONFIG = customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-
$(COREBOOT_BOARD)
+endif
+$(SOURCE_DIR)/$(LEGACYBIOS_TARBALL):
- @ mkdir -p $(SOURCE_DIR)
- @ wget $(WGET_Q) -P $(SOURCE_DIR)
$(LEGACYBIOS_URL)/$(LEGACYBIOS_SOURCE) --output- document=$(SOURCE_DIR)/$(LEGACYBIOS_TARBALL)
Not too important, but I'd use -O instead of --output-document, it's shorter and the rest of the code also uses -O.
I'll change it.
+$(LEGACYBIOS_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LEGACYBIOS_TARBALL)
| $(LEGACYBIOS_STAMP_DIR) $(LEGACYBIOS_DIR) $(LEGACYBIOS_LOG_DIR)
- @ echo "Unpacking legacybios..."
- @ tar -C $(LEGACYBIOS_DIR) -zxf $(SOURCE_DIR)/$(LEGACYBIOS_TARBALL)
- @ touch $@
+$(LEGACYBIOS_SRC_DIR)/out/rom.bin: $(LEGACYBIOS_STAMP_DIR)/.unpacked
- @ echo "Building legacybios..."
- @ echo $(LEGACYBIOS_SRC_DIR)
- @ make -C $(LEGACYBIOS_SRC_DIR) > $(LEGACYBIOS_BUILD_LOG) 2>&1
Doesn't work for me.
Adding 'AVOIDCOMBINE=1' as per legacybios README helps, but there are still build failures on my box (x86, Linux):
src/romlayout.S: Assembler messages: src/romlayout.S:427: Error: attempt to .org/.space backwards? (-1) src/romlayout.S:490: Fatal error: can't write out/romlayout16.o: Bad value make[1]: *** [out/romlayout16.o] Error 1
Any ideas?
+$(LEGACYBIOS_STAMP_DIR) $(LEGACYBIOS_LOG_DIR):
- @ mkdir -p $@
+legacybios: $(LEGACYBIOS_SRC_DIR)/out/rom.bin
+legacybios-clean:
- @ echo "Cleaning legacybios..."
- @ rm -f $(LEGACYBIOS_STAMP_DIR)/.copied
+ifneq ($(wildcard $(LEGACYBIOS_SRC_DIR)/Makefile),)
- @ $(MAKE) -C $(LEGACYBIOS_SRC_DIR) clean > /dev/null 2>&1
+endif
+legacybios-distclean:
- @ rm -rf $(LEGACYBIOS_DIR)/*
Index: config/payloads/Config.in
--- config/payloads/Config.in (revision 170) +++ config/payloads/Config.in (working copy) @@ -9,6 +9,9 @@ help Buildrom can build a number of different payloads for the ROM
+config PAYLOAD_ADLO
- bool "ADLO (Bochs BIOS with a wrapper for Coreboot)"
Maybe something like
bool "ADLO (x86 legacy BIOS on top of coreboot)"Or just "ADLO" and add more info the kconfig help.
ADLO is fine. There wasn't help for any of the other payloads, so I didn't add it for this one.
New patch attached.
Thanks, Myles
HTH, Uwe.
http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
On Wed, Apr 30, 2008 at 04:24:47PM -0600, Myles Watson wrote:
Index: adlo/elf/elf-header-065kb.payload Index: adlo/elf/elf-header-068kb.payload
Not sure I like storing blobs in svn. How were they generated?
By hand with a hex editor.
If
possible we should store the "source" or some scripts which generates them on-the-fly in svn? This won't hold up a commit though, can be done later. Hm, seems they're hand-crafted, but I'd still like a small script which "crafts" them better than storing blobs nobody can read or understand.
I'd love a script that crafts them. Using readelf -a and trial and error gets old.
Yep, we should put this on a TODO list (trac).
Also, v2's ADLO has three of those, what's the difference to these?
There used to be a 64K payload for the 16-bit BIOS and a 128K payload for the 32-bit BIOS that added other features like ACPI. Now the 32-bit BIOS fits into 64K, so no need for the 128-bit ELF headers. The reason there are two is that I hope to be able to use kexec to load ADLO so that the kernel can initialize all the hardware on the motherboard correctly. Kexec can't handle ELFs that have data that isn't page-aligned. The 68K payload has that 4K-aligned loader.
OK, fine. Would it hurt to use the aligned version for non-kexec too? Any drawbacks?
Index: adlo/loader.s
--- adlo/loader.s (revision 0) +++ adlo/loader.s (revision 0) @@ -0,0 +1,467 @@ +;***************************************************** +; $Id: loader.s,v 1.1 2002/11/25 02:07:53 rminnich Exp $ +;*****************************************************
Hm, who wrote this code originally and what license applies?
Juding from
http://tracker.coreboot.org/trac/coreboot/log/trunk/LinuxBIOSv1/util/ADLO? rev=702
http://tracker.coreboot.org/trac/coreboot/browser/trunk/LinuxBIOSv1/util/A DLO/README.1st?rev=702
http://tracker.coreboot.org/trac/coreboot/browser/trunk/LinuxBIOSv1/util/A DLO/CAST?rev=702 it seems the code was checked in by Ron, but actually implemented by Adam Sulmicki with the help of others:
"Most of the analysis, design and implementation of the project was done by me, Adam Sulmicki."
Is this correct?
Good question. I haven't been around this project that long. Ron?
I'm hoping we'll replace it very soon, though.
OK, then it probably doesn't matter much. If and how can the loader be integrated upstream? That's probably the best place to store it, correct?
+-; code it is loaded into memory at 0x7C00 ++; code it is loaded into memory at 0x7000
Why? Please explain. Is this board-specific or payload-specific? Can it be a variable, selectable in a config file later? Surely in buildrom, but also for manual builds...
This is part of what should go away. The BIOS has to get loaded at the correct address for callbacks to work. This loader needs to get loaded somewhere else, then copy its payload to the right spot. I'd love for the loading part to get taken over by Coreboot. Then we could just set up the CMOS values separately and not depend on being loaded into a hard-coded location in RAM.
Can you elaborate? What would coreboot need to do exactly (in addition what we already to for other payloads)? Is any of that board-specific?
What do you mean with CMOS values here? Where are they used in ADLO? Not yet, but you plan to do later?
This is needed for ADLO but not legacybios? Can we also change ADLO to not require it, or is that impossible?
I hope someone will do it soon. It would take me some time, since I'm not really familiar with assembly, but it really isn't too much code.
OK, sounds good. So there's not _real_ reason to continue using it.
Let's use "ADLO" in strings everywhere, as that seems to be the "official" name.
Sure. Once we replace the loader there will be nothing left of the original but the name, but the name's fine.
Hm, if it's completely gone later, I think we should also eliminate the ADLO name (but not just yet).
It's just coreboot+legacybios then, correct? So we'll probably call it legacybios (or BOCHS BIOS?). We'll see...
Index: packages/legacybios/legacybios.mk
--- packages/legacybios/legacybios.mk (revision 0) +++ packages/legacybios/legacybios.mk (revision 0)
[...]
+LEGACYBIOS_TARBALL=legacybios-$(LEGACYBIOS_TAG).tar.gz +LEGACYBIOS_SOURCE=legacybios-$(LEGACYBIOS_TAG).tar.gz
Why are both needed?
Is this required?
Testing the code now in QEMU and hardware, will report back.
Uwe.
OK, fine. Would it hurt to use the aligned version for non-kexec too? Any drawbacks?
The only drawback is size. It adds 3K of zeroes if you don't compress it.
OK, then it probably doesn't matter much. If and how can the loader be integrated upstream? That's probably the best place to store it, correct?
I don't think the loader should be integrated upstream. If we can get Bochs and QEMU to adopt the gcc port of the BIOS, it will have more testers and be more stable. They don't want the loader.
+-; code it is loaded into memory at 0x7C00 ++; code it is loaded into memory at 0x7000
Why? Please explain. Is this board-specific or payload-specific? Can it be a variable, selectable in a config file later? Surely in buildrom, but also for manual builds...
This is part of what should go away. The BIOS has to get loaded at the correct address for callbacks to work. This loader needs to get loaded somewhere else, then copy its payload to the right spot. I'd love for
the
loading part to get taken over by Coreboot. Then we could just set up
the
CMOS values separately and not depend on being loaded into a hard-coded location in RAM.
Can you elaborate? What would coreboot need to do exactly (in addition what we already to for other payloads)? Is any of that board-specific?
What do you mean with CMOS values here? Where are they used in ADLO? Not yet, but you plan to do later?
They are the way the Bochs BIOS knows what device to boot from, what the memory map is, etc.
This is needed for ADLO but not legacybios? Can we also change ADLO to not require it, or is that impossible?
I hope someone will do it soon. It would take me some time, since I'm
not
really familiar with assembly, but it really isn't too much code.
OK, sounds good. So there's not _real_ reason to continue using it.
Let's use "ADLO" in strings everywhere, as that seems to be the "official" name.
Sure. Once we replace the loader there will be nothing left of the
original
but the name, but the name's fine.
Hm, if it's completely gone later, I think we should also eliminate the ADLO name (but not just yet).
It's just coreboot+legacybios then, correct? So we'll probably call it legacybios (or BOCHS BIOS?). We'll see...
Index: packages/legacybios/legacybios.mk
--- packages/legacybios/legacybios.mk (revision 0) +++ packages/legacybios/legacybios.mk (revision 0)
[...]
+LEGACYBIOS_TARBALL=legacybios-$(LEGACYBIOS_TAG).tar.gz +LEGACYBIOS_SOURCE=legacybios-$(LEGACYBIOS_TAG).tar.gz
Why are both needed?
Is this required?
I took one out of the last patch
Testing the code now in QEMU and hardware, will report back.
Great. Thanks, Myles
On Wed, Apr 30, 2008 at 3:24 PM, Myles Watson mylesgw@gmail.com wrote:
"Most of the analysis, design and implementation of the project was done by me, Adam Sulmicki."
Is this correct?
Good question. I haven't been around this project that long. Ron?
Adam did all the work at U. MD. I guess I committed it? Memory fails.
ron
ADLO committed
Ronald G. Minnich Sun, 24 Nov 2002
http://www.mail-archive.com/linuxbios@clustermatic.org/msg01136.html
Hey, what's 5.5 years?
ron minnich wrote:
On Wed, Apr 30, 2008 at 3:24 PM, Myles Watson mylesgw@gmail.com wrote:
"Most of the analysis, design and implementation of the project was done by me, Adam Sulmicki."
Is this correct?
Good question. I haven't been around this project that long. Ron?
Adam did all the work at U. MD. I guess I committed it? Memory fails.
ron
Myles Watson wrote:
-----Original Message----- From: Jordan Crouse [mailto:jordan.crouse@amd.com] Sent: Wednesday, April 30, 2008 10:08 AM To: Myles Watson Cc: Coreboot Subject: Re: ADLO for buildrom
I don't know what the history of the ADLO code is - any reason why we can't give it a home in payloads/ on SVN instead of living in the buildrom code?
I don't think so. The old code was in v2's tree under utils/
I didn't think it was too big of a deal, since it's only one assembly file, a make file, and two elf headers. I admit it looks like a lot with all the documentation.
I'm happy to have it live wherever's best. Who has to set that up?
Thanks, Myles
For v3 we should really integrate the one assembly file rewritten in C as part of coreboot. It's a loader, just it doesnt load elf or self, but a rombios.bin...
-----Original Message----- From: Stefan Reinauer [mailto:stepan@coresystems.de] Sent: Wednesday, April 30, 2008 5:42 PM To: Myles Watson Cc: 'Jordan Crouse'; 'Coreboot' Subject: Re: [coreboot] ADLO for buildrom
Myles Watson wrote:
-----Original Message----- From: Jordan Crouse [mailto:jordan.crouse@amd.com] Sent: Wednesday, April 30, 2008 10:08 AM To: Myles Watson Cc: Coreboot Subject: Re: ADLO for buildrom
I don't know what the history of the ADLO code is - any reason why we can't give it a home in payloads/ on SVN instead of living in the buildrom code?
I don't think so. The old code was in v2's tree under utils/
I didn't think it was too big of a deal, since it's only one assembly
file,
a make file, and two elf headers. I admit it looks like a lot with all
the
documentation.
I'm happy to have it live wherever's best. Who has to set that up?
Thanks, Myles
For v3 we should really integrate the one assembly file rewritten in C as part of coreboot. It's a loader, just it doesnt load elf or self, but a rombios.bin...
I'd rather have it compiled and linked into an ELF, loaded in the normal way. I don't think there needs to be a special pathway for this one payload.
Thanks,
Myles
Myles Watson wrote:
For v3 we should really integrate the one assembly file rewritten in C as part of coreboot. It's a loader, just it doesnt load elf or self, but a rombios.bin...
I'd rather have it compiled and linked into an ELF, loaded in the normal way. I don't think there needs to be a special pathway for this one payload.
It is not a special pathway. It's just the normal lar loader, loading to a defined address.
We don't need the indirection of a loader of the loader for that...?
-----Original Message----- From: Stefan Reinauer [mailto:stepan@coresystems.de] Sent: Thursday, May 01, 2008 9:39 AM To: Myles Watson Cc: 'Jordan Crouse'; 'Coreboot' Subject: Re: [coreboot] ADLO for buildrom
Myles Watson wrote:
For v3 we should really integrate the one assembly file rewritten in C as part of coreboot. It's a loader, just it doesnt load elf or self,
but
a rombios.bin...
I'd rather have it compiled and linked into an ELF, loaded in the normal way. I don't think there needs to be a special pathway for this one payload.
It is not a special pathway. It's just the normal lar loader, loading to a defined address.
We don't need the indirection of a loader of the loader for that...?
I think we're in agreement. I'm talking about how it gets into the lar, and I think you're saying how it gets loaded into memory. We should either make an ELF and have lar put it in, or do the same thing that the Geode VSA does.
You're right, it should just get loaded into memory like any other binary.
Myles
On Wed, 30 Apr 2008 09:58:56 -0600, "Myles Watson" mylesgw@gmail.com wrote:
It boots Windows XP in QEMU.
Sweet:-)
What about booting XP on real hardware?
On Wed, 30 Apr 2008 09:58:56 -0600, "Myles Watson" mylesgw@gmail.com wrote:
It boots Windows XP in QEMU.
Sweet:-)
What about booting XP on real hardware?
The loader needs to be customized for each board, or we need to pass some information like RAM map from coreboot before that will work.
Thanks, Myles
On Wed, Apr 30, 2008 at 01:32:40PM -0600, Myles Watson wrote:
The loader needs to be customized for each board, or we need to pass some information like RAM map from coreboot before that will work.
Maybe libpayload can help there?
//Peter
Myles Watson wrote:
On Wed, 30 Apr 2008 09:58:56 -0600, "Myles Watson" mylesgw@gmail.com wrote:
It boots Windows XP in QEMU.
Sweet:-)
What about booting XP on real hardware?
The loader needs to be customized for each board, or we need to pass some information like RAM map from coreboot before that will work.
Which is why it really should, no, it has to be built into coreboot itself. coreboot already has all the knowledge required for this. Duplicating efforts that we did in C in another assembler chunk is plain b0rked.
On Thu, May 01, 2008 at 01:48:26AM +0200, Stefan Reinauer wrote:
Myles Watson wrote:
On Wed, 30 Apr 2008 09:58:56 -0600, "Myles Watson" mylesgw@gmail.com wrote:
It boots Windows XP in QEMU.
Sweet:-)
What about booting XP on real hardware?
The loader needs to be customized for each board, or we need to pass some information like RAM map from coreboot before that will work.
Which is why it really should, no, it has to be built into coreboot itself. coreboot already has all the knowledge required for this. Duplicating efforts that we did in C in another assembler chunk is plain b0rked.
Full ACK, if this could be a snippet of C code in coreboot that would be fantastic!
Uwe.
Uwe Hermann wrote:
On Thu, May 01, 2008 at 01:48:26AM +0200, Stefan Reinauer wrote:
Myles Watson wrote:
On Wed, 30 Apr 2008 09:58:56 -0600, "Myles Watson" mylesgw@gmail.com wrote:
It boots Windows XP in QEMU.
Sweet:-)
What about booting XP on real hardware?
The loader needs to be customized for each board, or we need to pass some information like RAM map from coreboot before that will work.
Which is why it really should, no, it has to be built into coreboot itself. coreboot already has all the knowledge required for this. Duplicating efforts that we did in C in another assembler chunk is plain b0rked.
Full ACK, if this could be a snippet of C code in coreboot that would be fantastic!
The main question is who holds the know how on how to enable/disable write protection and shadowing of the e and f segment.
And: Whether we need to care at all. Can't we just leave that space writable and rely on the OS not trying to overwrite the machine's BIOS? I would be surprised if any OS really tried that.
The main question is who holds the know how on how to enable/disable write protection and shadowing of the e and f segment.
Well this is chipset specific (memory controller).
And: Whether we need to care at all. Can't we just leave that space writable and rely on the OS not trying to overwrite the machine's BIOS? I would be surprised if any OS really tried that.
This is what I did exactly with the K8T890/VT8237. The chipset has the shadow ram prot bits even if the memory controller is in K8. But hey wrong setup of this caused DMA from HDD to fail if the physical memory target for DMA was in "shadow" memory range.
To sum it up. Coreboot should handle this. ADLO/LegacyBIOS whatever should not touch this. We can unprotect the shadows regions in coreboot. All we need is just sane memory map.
Rudolf
Rudolf Marek wrote:
The main question is who holds the know how on how to enable/disable write protection and shadowing of the e and f segment.
Well this is chipset specific (memory controller).
Exactly. Which is why I think it should not be part of a payload but part of coreboot.
And: Whether we need to care at all. Can't we just leave that space writable and rely on the OS not trying to overwrite the machine's BIOS? I would be surprised if any OS really tried that.
This is what I did exactly with the K8T890/VT8237. The chipset has the shadow ram prot bits even if the memory controller is in K8. But hey wrong setup of this caused DMA from HDD to fail if the physical memory target for DMA was in "shadow" memory range.
Ouch. Ok, then there is nasty stuff happening.
To sum it up. Coreboot should handle this. ADLO/LegacyBIOS whatever should not touch this. We can unprotect the shadows regions in coreboot. All we need is just sane memory map.
Absolutely.
On Thu, May 01, 2008 at 12:34:08PM +0200, Rudolf Marek wrote:
To sum it up. Coreboot should handle this. ADLO/LegacyBIOS whatever should not touch this. We can unprotect the shadows regions in coreboot. All we need is just sane memory map.
Is this designing in a callback from payload to coreboot?
Or would the shadowing be oneshot before the new biosloader runs?
//Peter
Or would the shadowing be oneshot before the new biosloader runs?
Definitely one shot. Like the rest of chipset initialization. No need to mess with legacy shadows.
Rudolf
Peter Stuge wrote:
On Thu, May 01, 2008 at 12:34:08PM +0200, Rudolf Marek wrote:
To sum it up. Coreboot should handle this. ADLO/LegacyBIOS whatever should not touch this. We can unprotect the shadows regions in coreboot. All we need is just sane memory map.
Is this designing in a callback from payload to coreboot?
To avoid this is the reason why the bios.bin _loader_ must be part of coreboot.
The alternative would be to pass a register write sequence description in lbtable. But this is pretty close to a virtual machine already, so we're almost re-inventing ACPI there. Not good.
Or would the shadowing be oneshot before the new biosloader runs?
The registers have to be changed _after_ bios.bin is copied to the E and F segment.
Just a side note. The ACPI tables needs to be writable by OS, because OS will store there waking vector. If you will protect the F segment where are the ACPI tables stores, suspend to RAM design/implementation would be complicated.
I really would go the way I suggested. Leave unprotected, OS should not overwrite parts of memory which are reserved/not reported.
Rudolf
On Thu, May 01, 2008 at 01:27:13PM +0200, Stefan Reinauer wrote:
To sum it up. Coreboot should handle this.
Is this designing in a callback from payload to coreboot?
To avoid this is the reason why the bios.bin _loader_ must be part of coreboot.
Yep. Sounds great.
The alternative would be to pass a register write sequence description in lbtable. .. Not good.
Agree.
Or would the shadowing be oneshot before the new biosloader runs?
The registers have to be changed _after_ bios.bin is copied to the E and F segment.
Doh. Yes. Oneshot _in_ the new biosloader, before bios.bin runs.
Should bios.bin run in x86emu or vm86 by the way?
//Peter
Or would the shadowing be oneshot before the new biosloader runs?
The registers have to be changed _after_ bios.bin is copied to the E and F segment.
Doh. Yes. Oneshot _in_ the new biosloader, before bios.bin runs.
Should bios.bin run in x86emu or vm86 by the way?
No x86emu here. Otherwise your OS will start up in x86emu, too... Might be an option for Carl-Daniel's upcoming MIPS port. ;-)
-----Original Message----- From: Stefan Reinauer [mailto:stepan@coresystems.de] Sent: Wednesday, April 30, 2008 5:48 PM To: Myles Watson Cc: joe@settoplinux.org; 'Coreboot' Subject: Re: [coreboot] ADLO for buildrom
Myles Watson wrote:
On Wed, 30 Apr 2008 09:58:56 -0600, "Myles Watson" mylesgw@gmail.com wrote:
It boots Windows XP in QEMU.
Sweet:-)
What about booting XP on real hardware?
The loader needs to be customized for each board, or we need to pass
some
information like RAM map from coreboot before that will work.
Which is why it really should, no, it has to be built into coreboot itself. coreboot already has all the knowledge required for this. Duplicating efforts that we did in C in another assembler chunk is plain b0rked.
I was hoping that we could pass it the same information we pass the Linux kernel. The e820 maps etc. I haven't looked into it too much, but ACPI tables for that information would be fine for me too.
Myles
Myles Watson wrote:
I was hoping that we could pass it the same information we pass the Linux kernel. The e820 maps etc. I haven't looked into it too much, but ACPI tables for that information would be fine for me too.
But there the cat bites its tail. legacybios is the one that produces e820. And so far it produces pirq and acpi, too. It just doesnt make sense like this on real hardware. bochs bios is sure not much better.
-----Original Message----- From: Stefan Reinauer [mailto:stepan@coresystems.de] Sent: Thursday, May 01, 2008 9:44 AM To: Myles Watson Cc: joe@settoplinux.org; 'Coreboot' Subject: Re: [coreboot] ADLO for buildrom
Myles Watson wrote:
I was hoping that we could pass it the same information we pass the
Linux
kernel. The e820 maps etc. I haven't looked into it too much, but ACPI tables for that information would be fine for me too.
But there the cat bites its tail. legacybios is the one that produces e820. And so far it produces pirq and acpi, too. It just doesnt make sense like this on real hardware. bochs bios is sure not much better.
So how does the kernel get an e820 map when you load it from filo? That was the pathway I meant.
Thanks, Myles
Myles Watson wrote:
-----Original Message----- From: Stefan Reinauer [mailto:stepan@coresystems.de] Sent: Thursday, May 01, 2008 9:44 AM To: Myles Watson Cc: joe@settoplinux.org; 'Coreboot' Subject: Re: [coreboot] ADLO for buildrom
Myles Watson wrote:
I was hoping that we could pass it the same information we pass the
Linux
kernel. The e820 maps etc. I haven't looked into it too much, but ACPI tables for that information would be fine for me too.
But there the cat bites its tail. legacybios is the one that produces e820. And so far it produces pirq and acpi, too. It just doesnt make sense like this on real hardware. bochs bios is sure not much better.
So how does the kernel get an e820 map when you load it from filo? That was the pathway I meant.
filo makes one from the coreboot table.
-----Original Message----- From: Stefan Reinauer [mailto:stepan@coresystems.de] Sent: Thursday, May 01, 2008 10:15 AM To: Myles Watson Cc: joe@settoplinux.org; 'Coreboot' Subject: Re: [coreboot] ADLO for buildrom
Myles Watson wrote:
-----Original Message----- From: Stefan Reinauer [mailto:stepan@coresystems.de] Sent: Thursday, May 01, 2008 9:44 AM To: Myles Watson Cc: joe@settoplinux.org; 'Coreboot' Subject: Re: [coreboot] ADLO for buildrom
Myles Watson wrote:
I was hoping that we could pass it the same information we pass the
Linux
kernel. The e820 maps etc. I haven't looked into it too much, but
ACPI
tables for that information would be fine for me too.
But there the cat bites its tail. legacybios is the one that produces e820. And so far it produces pirq and acpi, too. It just doesnt make sense like this on real hardware. bochs bios is sure not much better.
So how does the kernel get an e820 map when you load it from filo? That
was
the pathway I meant.
filo makes one from the coreboot table.
Great. That's what I think ADLO should do too.
Myles
On Thu, May 01, 2008 at 09:34:13AM -0600, Myles Watson wrote:
I'd rather have it compiled and linked into an ELF, loaded in the normal way.
On Thu, May 01, 2008 at 10:16:25AM -0600, Myles Watson wrote:
So how does the kernel get an e820 map when you load it from filo? That was the pathway I meant.
filo makes one from the coreboot table.
Great. That's what I think ADLO should do too.
It could use libpayload, right?
//Peter
On 01/05/08 20:27 +0200, Peter Stuge wrote:
On Thu, May 01, 2008 at 09:34:13AM -0600, Myles Watson wrote:
I'd rather have it compiled and linked into an ELF, loaded in the normal way.
On Thu, May 01, 2008 at 10:16:25AM -0600, Myles Watson wrote:
So how does the kernel get an e820 map when you load it from filo? That was the pathway I meant.
filo makes one from the coreboot table.
Great. That's what I think ADLO should do too.
It could use libpayload, right?
Is the e820 table generation generic and useful enough that it belongs in the library? I was going to suggest that before, but then I thought better of it.
Even if not, it can still use libpayload to walk the coreboot tables.
Jordan
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: Thursday, May 01, 2008 12:28 PM To: 'Coreboot' Subject: Re: [coreboot] ADLO for buildrom
On Thu, May 01, 2008 at 09:34:13AM -0600, Myles Watson wrote:
I'd rather have it compiled and linked into an ELF, loaded in the normal way.
On Thu, May 01, 2008 at 10:16:25AM -0600, Myles Watson wrote:
So how does the kernel get an e820 map when you load it from filo? That was the pathway I meant.
filo makes one from the coreboot table.
Great. That's what I think ADLO should do too.
It could use libpayload, right?
Sorry I didn't reply earlier to this comment. I don't know very much about libpayload. That would be fine with me if it works.
Thanks, Myles
On Wed, Apr 30, 2008 at 09:58:56AM -0600, Myles Watson wrote:
This patch adds ADLO to buildrom using the gcc ported BOCHS BIOS. It boots Windows XP in QEMU.
Thanks Myles!
It still needs as86 to be installed because I didn't port the loader yet.
Porting the loader from as86 style assembler to gas should be pretty simple. (In fact, I wonder if just telling gas to use intel syntax would make it work.)
However, ultimately I think the logic should just be ported to C code.
Other things like making the loader understand the coreboot information to get the RAM map would be nice too.
I think we're going to need to teach legacybios about coreboot (and maybe add some new things to coreboot). I'd prefer not require a special shim between the code just to pass the handful of parameters around.
Thanks again, -Kevin
-----Original Message----- From: Kevin O'Connor [mailto:kevin@koconnor.net] Sent: Wednesday, April 30, 2008 8:25 PM To: Myles Watson Cc: Coreboot Subject: Re: [coreboot] ADLO for buildrom
On Wed, Apr 30, 2008 at 09:58:56AM -0600, Myles Watson wrote:
This patch adds ADLO to buildrom using the gcc ported BOCHS BIOS. It boots Windows XP in QEMU.
Thanks Myles!
It still needs as86 to be installed because I didn't port the loader yet.
Porting the loader from as86 style assembler to gas should be pretty simple. (In fact, I wonder if just telling gas to use intel syntax would make it work.)
However, ultimately I think the logic should just be ported to C code.
Yes.
Other things like making the loader understand the coreboot information to get the RAM map would be nice too.
I think we're going to need to teach legacybios about coreboot (and maybe add some new things to coreboot). I'd prefer not require a special shim between the code just to pass the handful of parameters around.
I just want to keep the BIOS useful for QEMU and Bochs, because I think more users = more solid.
Thanks, Myles
-
bari -
Joe -
Jordan Crouse -
Kevin O'Connor -
Myles Watson -
Peter Stuge -
ron minnich -
Rudolf Marek -
Stefan Reinauer -
Uwe Hermann