This is on top of the patch I sent 50 minutes ago titled: "Re: [LinuxBIOS] patch: prepare v3 tree for new way of doing initram".
Convert stage2 handling from binary blob to multi-segment LAR which is created by parsing the ELF file linuxbios.stage2.o. That way, we avoid manual specification of the entry point for stage2 code. A few LAR functions are now unused and can be removed in a following cleanup session. Another suggested cleanup would be factoring out a load_all_segments function, resulting in less code duplication.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
diff -ur LinuxBIOSv3-testron/arch/x86/Makefile LinuxBIOSv3-testron-withstage2/arch/x86/Makefile --- LinuxBIOSv3-testron/arch/x86/Makefile 2007-11-27 02:44:39.000000000 +0100 +++ LinuxBIOSv3-testron-withstage2/arch/x86/Makefile 2007-11-27 03:24:21.000000000 +0100 @@ -36,7 +36,7 @@
ROM_SIZE := $(shell expr $(CONFIG_LINUXBIOS_ROMSIZE_KB) * 1024)
-LARFILES := nocompress:normal/initram.o normal/stage2 nocompress:normal/option_table +LARFILES := nocompress:normal/initram.o normal/stage2.o nocompress:normal/option_table ifneq ($(CONFIG_PAYLOAD_NONE),y) LARFILES += normal/payload endif @@ -57,12 +57,12 @@ COMPRESSFLAG := -C nrv2b endif
-$(obj)/linuxbios.rom $(obj)/linuxbios.map: $(obj)/linuxbios.bootblock $(obj)/util/lar/lar lzma nrv2b $(obj)/linuxbios.initram.o $(obj)/linuxbios.stage2 $(obj)/option_table +$(obj)/linuxbios.rom $(obj)/linuxbios.map: $(obj)/linuxbios.bootblock $(obj)/util/lar/lar lzma nrv2b $(obj)/linuxbios.initram.o $(obj)/linuxbios.stage2.o $(obj)/option_table $(Q)rm -rf $(obj)/lar.tmp $(Q)mkdir $(obj)/lar.tmp $(Q)mkdir $(obj)/lar.tmp/normal $(Q)cp $(obj)/linuxbios.initram.o $(obj)/lar.tmp/normal/initram.o - $(Q)cp $(obj)/linuxbios.stage2 $(obj)/lar.tmp/normal/stage2 + $(Q)cp $(obj)/linuxbios.stage2.o $(obj)/lar.tmp/normal/stage2.o $(Q)cp $(obj)/option_table $(obj)/lar.tmp/normal/option_table ifeq ($(CONFIG_PAYLOAD_NONE),y) $(Q)printf " PAYLOAD none (as specified by user)\n" @@ -198,13 +198,11 @@ STAGE2_OBJ += $(obj)/util/x86emu/libx86emu.a $(LIBGCC_FILE_NAME) endif
-$(obj)/linuxbios.stage2 $(obj)/linuxbios.stage2.map: $(obj)/stage0.init $(STAGE2_OBJ) +$(obj)/linuxbios.stage2.o $(obj)/linuxbios.stage2.map: $(obj)/stage0.init $(STAGE2_OBJ) $(Q)# leave a .o with full symbols in it for debugging. $(Q)printf " LD $(subst $(shell pwd)/,,$(@))\n" $(Q)$(LD) -R $(obj)/stage0.o -Ttext 0x1000 --entry=stage2 \ -o $(obj)/linuxbios.stage2.o $(STAGE2_OBJ) - $(Q)printf " OBJCOPY $(subst $(shell pwd)/,,$(@))\n" - $(Q)$(OBJCOPY) -O binary $(obj)/linuxbios.stage2.o $(obj)/linuxbios.stage2 $(Q)$(NM) $(obj)/linuxbios.stage2.o | sort -u > $(obj)/linuxbios.stage2.map
# diff -ur LinuxBIOSv3-testron/arch/x86/stage1.c LinuxBIOSv3-testron-withstage2/arch/x86/stage1.c --- LinuxBIOSv3-testron/arch/x86/stage1.c 2007-11-27 03:03:17.000000000 +0100 +++ LinuxBIOSv3-testron-withstage2/arch/x86/stage1.c 2007-11-27 03:41:08.000000000 +0100 @@ -161,7 +161,12 @@ /* Turn off Cache-As-Ram */ disable_car();
- ret = run_file(&archive, "normal/stage2", (void *)0x1000); + entry = load_file(&archive, "normal/stage2.o/segment0"); + if (entry == (void *)-1) + die("FATAL: Failed loading stage2 segment0."); + if (load_file(&archive, "normal/stage2.o/segment1") == (void *)-1) + die("FATAL: Failed loading stage2 segment1."); + ret = run_address(entry); if (ret) die("FATAL: Failed in stage2 code.");
On 27.11.2007 03:55, Carl-Daniel Hailfinger wrote:
This is on top of the patch I sent 50 minutes ago titled: "Re: [LinuxBIOS] patch: prepare v3 tree for new way of doing initram".
Convert stage2 handling from binary blob to multi-segment LAR which is created by parsing the ELF file linuxbios.stage2.o. That way, we avoid manual specification of the entry point for stage2 code. A few LAR functions are now unused and can be removed in a following cleanup session. Another suggested cleanup would be factoring out a load_all_segments function, resulting in less code duplication.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Qemu boot log for a tree with both patches attached so you can verify it works and looks nice.
Regards, Carl-Daniel
(qemu)
LinuxBIOS-3.0.0 Tue Nov 27 03:41:39 CET 2007 starting... Choosing fallback boot. LAR: Attempting to open 'fallback/initram.o/segment0'. LAR: Start 0xfffc0000 len 0x40000 LAR: seen member normal/option_table LAR: seen member normal/stage2.o/segment0 LAR: seen member normal/stage2.o/segment1 LAR: seen member normal/initram.o/segment0 LAR: seen member bootblock LAR: NO FILE FOUND! LAR: Run file fallback/initram.o/segment0 failed: No such file. Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram.o/segment0'. LAR: Start 0xfffc0000 len 0x40000 LAR: seen member normal/option_table LAR: seen member normal/stage2.o/segment0 LAR: seen member normal/stage2.o/segment1 LAR: seen member normal/initram.o/segment0 LAR: CHECK normal/initram.o/segment0 @ 0xfffc40d0 start 0xfffc4120 len 272 reallen 272 compression 0 entry 0x00000021 loadaddress 0x00000000 Entry point is 0xfffc4141 RAM init code started. Nothing to do. printktest1: If the immediately preceding line does not say "Nothing to do.", then execution did not start at main() run_file returns with 0 Done RAM init code LAR: Attempting to open 'normal/stage2.o/segment0'. LAR: Start 0xfffc0000 len 0x40000 LAR: seen member normal/option_table LAR: seen member normal/stage2.o/segment0 LAR: CHECK normal/stage2.o/segment0 @ 0xfffc0400 start 0xfffc0450 len 15078 reallen 27960 compression 1 entry 0x00001000 loadaddress 0x00001000 LAR: Compression algorithm #1 used LAR: Attempting to open 'normal/stage2.o/segment1'. LAR: Start 0xfffc0000 len 0x40000 LAR: seen member normal/option_table LAR: seen member normal/stage2.o/segment0 LAR: seen member normal/stage2.o/segment1 LAR: CHECK normal/stage2.o/segment1 @ 0xfffc3f40 start 0xfffc3f90 len 313 reallen 4300 compression 1 entry 0x00001000 loadaddress 0x00008ff4 LAR: Compression algorithm #1 used Phase 1: Very early setup... Phase 1: done Show all devs... root(Root Device): enabled 1 have_resources 0 initialized 0 cpus: Unknown device path type: 0 cpus(): enabled 1 have_resources 0 initialized 0 device0_0(PCI: 00:00.0): enabled 1 have_resources 0 initialized 0 southbridge_intel_i82371eb(PCI: 00:01.0): enabled 1 have_resources 0 initialized 0 domain0(PCI_DOMAIN: 0000): enabled 1 have_resources 0 initialized 0 Phase 2: Early setup... dev_phase2: dev root: dev_phase2: dev cpus: dev_phase2: dev device0_0: dev_phase2: dev southbridge_intel_i82371eb: dev_phase2: dev domain0: Phase 2: Done. Show all devs... root(Root Device): enabled 1 have_resources 0 initialized 0 cpus: Unknown device path type: 0 cpus(): enabled 1 have_resources 0 initialized 0 device0_0(PCI: 00:00.0): enabled 1 have_resources 0 initialized 0 southbridge_intel_i82371eb(PCI: 00:01.0): enabled 1 have_resources 0 initialized 0 domain0(PCI_DOMAIN: 0000): enabled 1 have_resources 0 initialized 0 Phase 3: Enumerating buses... dev_phase3_scan: scanning root(Root Device) scan_static_bus for root (Root Device) cpus: Unknown device path type: 0 cpus() enabled dev_phase5: device0_0(PCI: 00:00.0) missing ops dev_phase5: southbridge_intel_i82371eb(PCI: 00:01.0) missing ops domain0(PCI_DOMAIN: 0000) enabled domain0(PCI_DOMAIN: 0000) scanning... dev_phase3_scan: scanning domain0(PCI_DOMAIN: 0000) pci_scan_bus start bus 0x000098c0, bus->dev 0x00009688 PCI: pci_scan_bus for bus 00 pci_scan_bus: old_devices 0x0000996c, dev for this bus 0x00009688 (domain0) PCI: scan devfn 0x0 to 0xff PCI: devfn 0x0 pci_scan_get_dev: list is 0x0008fe78, *list is 0x0000996c pci_scan_get_dev: check dev device0_0 pci_scan_get_dev: check dev device0_0 it has devfn 0x00 PCI: pci_scan_bus pci_scan_get_dev returns dev device0_0 find_constructor: find PCI: 8086:1237 find_constructor: check all_constructors[i] 0x00007a4c find_constructor: cons 0x00007a4c, cons id PCI: 1013:00b8 find_constructor: check all_constructors[i] 0x00009f80 find_constructor: cons 0x00009f80, cons id PCI_DOMAIN: 8086:7190 find_constructor: cons 0x00009f94, cons id PCI: 8086:7190 find_constructor: check all_constructors[i] 0x00009fbc find_constructor: cons 0x00009fbc, cons id PCI: 8086:7000 find_constructor: cons 0x00009fd0, cons id PCI: 8086:7010 find_constructor: cons 0x00009fe4, cons id PCI: 8086:7113 set_pci_ops: dev 0x0000996c(device0_0) set ops to 0x00008ffc PCI: 00:00.0 [8086/1237] enabled PCI: pci_scan_bus pci_probe_dev returns dev 0x0000996c(device0_0) PCI: devfn 0x8 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00009c50 pci_scan_get_dev: check dev southbridge_intel_i82371eb pci_scan_get_dev: check dev southbridge_intel_i82371eb it has devfn 0x08 PCI: pci_scan_bus pci_scan_get_dev returns dev southbridge_intel_i82371eb find_constructor: find PCI: 8086:7000 find_constructor: check all_constructors[i] 0x00007a4c find_constructor: cons 0x00007a4c, cons id PCI: 1013:00b8 find_constructor: check all_constructors[i] 0x00009f80 find_constructor: cons 0x00009f80, cons id PCI_DOMAIN: 8086:7190 find_constructor: cons 0x00009f94, cons id PCI: 8086:7190 find_constructor: check all_constructors[i] 0x00009fbc find_constructor: cons 0x00009fbc, cons id PCI: 8086:7000 find_constructor: match PCI: 00:01.0 id PCI: 8086:7000 [8086/7000] ops PCI: 00:01.0 [8086/7000] enabled PCI: pci_scan_bus pci_probe_dev returns dev 0x00009c50(southbridge_intel_i82371eb) PCI: devfn 0x9 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) find_constructor: find PCI: 8086:7010 find_constructor: check all_constructors[i] 0x00007a4c find_constructor: cons 0x00007a4c, cons id PCI: 1013:00b8 find_constructor: check all_constructors[i] 0x00009f80 find_constructor: cons 0x00009f80, cons id PCI_DOMAIN: 8086:7190 find_constructor: cons 0x00009f94, cons id PCI: 8086:7190 find_constructor: check all_constructors[i] 0x00009fbc find_constructor: cons 0x00009fbc, cons id PCI: 8086:7000 find_constructor: cons 0x00009fd0, cons id PCI: 8086:7010 find_constructor: match constructor: constructor is 0x00009fd0 default device constructor called set_pci_ops: dev 0x0000a3b8(dynamic PCI: 00:01.1) already has ops 0x0000a048 PCI: 00:01.1 [8086/7010] enabled PCI: pci_scan_bus pci_probe_dev returns dev 0x0000a3b8(dynamic PCI: 00:01.1) PCI: devfn 0xa pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xa, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xb pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) find_constructor: find PCI: 8086:7113 find_constructor: check all_constructors[i] 0x00007a4c find_constructor: cons 0x00007a4c, cons id PCI: 1013:00b8 find_constructor: check all_constructors[i] 0x00009f80 find_constructor: cons 0x00009f80, cons id PCI_DOMAIN: 8086:7190 find_constructor: cons 0x00009f94, cons id PCI: 8086:7190 find_constructor: check all_constructors[i] 0x00009fbc find_constructor: cons 0x00009fbc, cons id PCI: 8086:7000 find_constructor: cons 0x00009fd0, cons id PCI: 8086:7010 find_constructor: cons 0x00009fe4, cons id PCI: 8086:7113 find_constructor: match constructor: constructor is 0x00009fe4 default device constructor called set_pci_ops: dev 0x0000a69c(dynamic PCI: 00:01.3) already has ops 0x0000a084 PCI: 00:01.3 [8086/7113] enabled PCI: pci_scan_bus pci_probe_dev returns dev 0x0000a69c(dynamic PCI: 00:01.3) PCI: devfn 0xc pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xc, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xd pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xd, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xe pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xe, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xf pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xf, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x10 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) find_constructor: find PCI: 1013:00b8 find_constructor: check all_constructors[i] 0x00007a4c find_constructor: cons 0x00007a4c, cons id PCI: 1013:00b8 find_constructor: match constructor: constructor is 0x00007a4c default device constructor called set_pci_ops: dev 0x0000a980(dynamic PCI: 00:02.0) already has ops 0x00007a74 Init VGA device PCI: 00:02.0 [1013/00b8] enabled PCI: pci_scan_bus pci_probe_dev returns dev 0x0000a980(dynamic PCI: 00:02.0) PCI: devfn 0x18 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) find_constructor: find PCI: 10ec:8029 find_constructor: check all_constructors[i] 0x00007a4c find_constructor: cons 0x00007a4c, cons id PCI: 1013:00b8 find_constructor: check all_constructors[i] 0x00009f80 find_constructor: cons 0x00009f80, cons id PCI_DOMAIN: 8086:7190 find_constructor: cons 0x00009f94, cons id PCI: 8086:7190 find_constructor: check all_constructors[i] 0x00009fbc find_constructor: cons 0x00009fbc, cons id PCI: 8086:7000 find_constructor: cons 0x00009fd0, cons id PCI: 8086:7010 find_constructor: cons 0x00009fe4, cons id PCI: 8086:7113 constructor: constructor is 0x00000000 No constructor called for <null>. find_constructor: find PCI: 10ec:8029 find_constructor: check all_constructors[i] 0x00007a4c find_constructor: cons 0x00007a4c, cons id PCI: 1013:00b8 find_constructor: check all_constructors[i] 0x00009f80 find_constructor: cons 0x00009f80, cons id PCI_DOMAIN: 8086:7190 find_constructor: cons 0x00009f94, cons id PCI: 8086:7190 find_constructor: check all_constructors[i] 0x00009fbc find_constructor: cons 0x00009fbc, cons id PCI: 8086:7000 find_constructor: cons 0x00009fd0, cons id PCI: 8086:7010 find_constructor: cons 0x00009fe4, cons id PCI: 8086:7113 set_pci_ops: dev 0x0000ac64(dynamic PCI: 00:03.0) set ops to 0x00008ffc PCI: 00:03.0 [10ec/8029] enabled PCI: pci_scan_bus pci_probe_dev returns dev 0x0000ac64(dynamic PCI: 00:03.0) PCI: devfn 0x20 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x20, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x28 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x28, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x30 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x30, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x38 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x38, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x40 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x40, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x48 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x48, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x50 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x50, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x58 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x58, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x60 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x60, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x68 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x68, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x70 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x70, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x78 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x78, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x80 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x80, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x88 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x88, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x90 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x90, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0x98 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x98, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xa0 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xa0, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xa8 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xa8, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xb0 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xb0, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xb8 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xb8, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xc0 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xc0, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xc8 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xc8, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xd0 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xd0, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xd8 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xd8, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xe0 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xe0, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xe8 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xe8, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xf0 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xf0, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: devfn 0xf8 pci_scan_get_dev: list is 0x0008fe78, *list is 0x00000000 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000() PCI: Done for loop dev_phase3_scan: device0_0: busdevice 0x0000996c enabled 1 ops 0x00008ffc dev_phase3_scan: can not scan from here, returning 0 dev_phase3_scan: southbridge_intel_i82371eb: busdevice 0x00009c50 enabled 1 ops 0x0000a00c dev_phase3_scan: can not scan from here, returning 0 dev_phase3_scan: dynamic PCI: 00:01.1: busdevice 0x0000a3b8 enabled 1 ops 0x0000a048 dev_phase3_scan: can not scan from here, returning 0 dev_phase3_scan: dynamic PCI: 00:01.3: busdevice 0x0000a69c enabled 1 ops 0x0000a084 dev_phase3_scan: can not scan from here, returning 0 dev_phase3_scan: dynamic PCI: 00:02.0: busdevice 0x0000a980 enabled 1 ops 0x00007a74 dev_phase3_scan: can not scan from here, returning 0 dev_phase3_scan: dynamic PCI: 00:03.0: busdevice 0x0000ac64 enabled 1 ops 0x00008ffc dev_phase3_scan: can not scan from here, returning 0 PCI: pci_scan_bus returning with max=000 dev_phase3_scan: returning 0 scan_static_bus for root(Root Device) done dev_phase3_scan: returning 0 Phase 3: Done. Show all devs... root(Root Device): enabled 1 have_resources 0 initialized 0 cpus: Unknown device path type: 0 cpus(): enabled 1 have_resources 0 initialized 0 device0_0(PCI: 00:00.0): enabled 1 have_resources 0 initialized 0 southbridge_intel_i82371eb(PCI: 00:01.0): enabled 1 have_resources 0 initialized 0 domain0(PCI_DOMAIN: 0000): enabled 1 have_resources 0 initialized 0 dynamic PCI: 00:01.1(PCI: 00:01.1): enabled 1 have_resources 0 initialized 0 dynamic PCI: 00:01.3(PCI: 00:01.3): enabled 1 have_resources 0 initialized 0 dynamic PCI: 00:02.0(PCI: 00:02.0): enabled 1 have_resources 0 initialized 0 dynamic PCI: 00:03.0(PCI: 00:03.0): enabled 1 have_resources 0 initialized 0 Phase 4: Allocating resources... Phase 4: Reading resources... Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0 read_resources: root(Root Device) read_resources bus 0 link: 0 read_resources: root(Root Device) dtsname cpus have_resources 0 enabled 1 cpus: Unknown device path type: 0 read_resources: cpus() missing phase4_read_resources read_resources: root(Root Device) dtsname domain0 have_resources 0 enabled 1 read_resources: domain0(PCI_DOMAIN: 0000) read_resources bus 0 link: 0 read_resources: domain0(PCI_DOMAIN: 0000) dtsname device0_0 have_resources 0 enabled 1 read_resources: domain0(PCI_DOMAIN: 0000) dtsname southbridge_intel_i82371eb have_resources 0 enabled 1 read_resources: domain0(PCI_DOMAIN: 0000) dtsname dynamic PCI: 00:01.1 have_resources 0 enabled 1 read_resources: domain0(PCI_DOMAIN: 0000) dtsname dynamic PCI: 00:01.3 have_resources 0 enabled 1 read_resources: domain0(PCI_DOMAIN: 0000) dtsname dynamic PCI: 00:02.0 have_resources 0 enabled 1 read_resources: domain0(PCI_DOMAIN: 0000) dtsname dynamic PCI: 00:03.0 have_resources 0 enabled 1 read_resources: domain0(PCI_DOMAIN: 0000) read_resources bus 0 link: 0 done read_resources: root(Root Device) read_resources bus 0 link: 0 done PCI: 00:03.0 10 * [0x00000400 - 0x000004ff] io PCI: 00:01.1 20 * [0x00000800 - 0x0000080f] io Root Device compute_allocate_io: base: 00000810 size: 00000410 align: 8 gran: 0 done Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0 gran: 0 read_resources: root(Root Device) read_resources bus 0 link: 0 read_resources: root(Root Device) dtsname cpus have_resources 0 enabled 1 cpus: Unknown device path type: 0 read_resources: cpus() missing phase4_read_resources read_resources: root(Root Device) dtsname domain0 have_resources 1 enabled 1 read_resources: root(Root Device) read_resources bus 0 link: 0 done PCI: 00:02.0 10 * [0x00000000 - 0x01ffffff] prefmem PCI: 00:02.0 14 * [0x02000000 - 0x02000fff] mem Root Device compute_allocate_mem: base: 02001000 size: 02001000 align: 25 gran: 0 done Phase 4: Done reading resources. Allocating VGA resource PCI: 00:02.0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000 Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Phase 4: Setting resources... Root Device compute_allocate_io: base: 00001000 size: 00000410 align: 8 gran: 0 read_resources: root(Root Device) read_resources bus 0 link: 0 read_resources: root(Root Device) dtsname cpus have_resources 0 enabled 1 cpus: Unknown device path type: 0 read_resources: cpus() missing phase4_read_resources read_resources: root(Root Device) dtsname domain0 have_resources 1 enabled 1 read_resources: root(Root Device) read_resources bus 0 link: 0 done PCI: 00:03.0 10 * [0x00001000 - 0x000010ff] io PCI: 00:01.1 20 * [0x00001400 - 0x0000140f] io Root Device compute_allocate_io: base: 00001410 size: 00000410 align: 8 gran: 0 done Root Device compute_allocate_mem: base: fc000000 size: 02001000 align: 25 gran: 0 read_resources: root(Root Device) read_resources bus 0 link: 0 read_resources: root(Root Device) dtsname cpus have_resources 0 enabled 1 cpus: Unknown device path type: 0 read_resources: cpus() missing phase4_read_resources read_resources: root(Root Device) dtsname domain0 have_resources 1 enabled 1 read_resources: root(Root Device) read_resources bus 0 link: 0 done PCI: 00:02.0 10 * [0xfc000000 - 0xfdffffff] prefmem PCI: 00:02.0 14 * [0xfe000000 - 0xfe000fff] mem Root Device compute_allocate_mem: base: fe001000 size: 02001000 align: 25 gran: 0 done root(Root Device) assign_resources, bus 0 link: 0 ram_resource: add ram resource 134217728 bytes domain0(PCI_DOMAIN: 0000) assign_resources, bus 0 link: 0 PCI: 00:01.1 20 <- [0x0000001400 - 0x000000140f] size 0x00000010 gran 0x04 io PCI: 00:02.0 10 <- [0x00fc000000 - 0x00fdffffff] size 0x02000000 gran 0x19 prefmem PCI: 00:02.0 14 <- [0x00fe000000 - 0x00fe000fff] size 0x00001000 gran 0x0c mem PCI: 00:02.0 30 <- [0x00000c0000 - 0x00000bffff] size 0x00000000 gran 0x00 romem PCI: 00:03.0 10 <- [0x0000001000 - 0x00000010ff] size 0x00000100 gran 0x08 io domain0(PCI_DOMAIN: 0000) assign_resources, bus 0 link: 0 root(Root Device) assign_resources, bus 0 link: 0 Phase 4: Done setting resources. Phase 4: Done allocating resources. Show all devs... root(Root Device): enabled 1 have_resources 0 initialized 0 cpus: Unknown device path type: 0 cpus(): enabled 1 have_resources 0 initialized 0 device0_0(PCI: 00:00.0): enabled 1 have_resources 1 initialized 0 southbridge_intel_i82371eb(PCI: 00:01.0): enabled 1 have_resources 1 initialized 0 domain0(PCI_DOMAIN: 0000): enabled 1 have_resources 1 initialized 0 dynamic PCI: 00:01.1(PCI: 00:01.1): enabled 1 have_resources 1 initialized 0 dynamic PCI: 00:01.3(PCI: 00:01.3): enabled 1 have_resources 1 initialized 0 dynamic PCI: 00:02.0(PCI: 00:02.0): enabled 1 have_resources 1 initialized 0 dynamic PCI: 00:03.0(PCI: 00:03.0): enabled 1 have_resources 1 initialized 0 Phase 5: Enabling resources... cpus: Unknown device path type: 0 dev_phase5: cpus() missing ops pci_dev_enable_resources: device0_0 (PCI: 00:00.0) cmd <- 140 pci_dev_enable_resources: southbridge_intel_i82371eb (PCI: 00:01.0) cmd <- 147 pci_dev_enable_resources: dynamic PCI: 00:01.1 (PCI: 00:01.1) cmd <- 141 pci_dev_enable_resources: dynamic PCI: 00:01.3 (PCI: 00:01.3) cmd <- 140 PCI: 00:02.0: Setting subsystem VID/DID to 15ad/1976 pci_dev_enable_resources: dynamic PCI: 00:02.0 (PCI: 00:02.0) cmd <- 143 pci_dev_enable_resources: dynamic PCI: 00:03.0 (PCI: 00:03.0) cmd <- 141 Phase 5: Done. Show all devs... root(Root Device): enabled 1 have_resources 0 initialized 0 cpus: Unknown device path type: 0 cpus(): enabled 1 have_resources 0 initialized 0 device0_0(PCI: 00:00.0): enabled 1 have_resources 1 initialized 0 southbridge_intel_i82371eb(PCI: 00:01.0): enabled 1 have_resources 1 initialized 0 domain0(PCI_DOMAIN: 0000): enabled 1 have_resources 1 initialized 0 dynamic PCI: 00:01.1(PCI: 00:01.1): enabled 1 have_resources 1 initialized 0 dynamic PCI: 00:01.3(PCI: 00:01.3): enabled 1 have_resources 1 initialized 0 dynamic PCI: 00:02.0(PCI: 00:02.0): enabled 1 have_resources 1 initialized 0 dynamic PCI: 00:03.0(PCI: 00:03.0): enabled 1 have_resources 1 initialized 0 Phase 6: Initializing devices... Phase 6: Root Device init. Phase 6: PCI: 00:00.0 init. PCI: pci_dev_init Probing for option ROM Phase 6: PCI: 00:01.0 init. Initializing realtime clock. RTC: Checksum invalid zeroing cmos Invalid LinuxBIOS CMOS checksum. Phase 6: PCI: 00:01.1 init. Enabling IDE channel 1 Enabling IDE channel 2 Enabling Legacy IDE Phase 6: PCI: 00:01.3 init. Enabling SMBus. Enable Power Management Functions Phase 6: PCI: 00:02.0 init. PCI: pci_dev_init Probing for option ROM ROM address for PCI: 00:02.0 = c0000 PCI Expansion ROM, signature 0x0000, INIT size 0x0000, data ptr 0x0000 Incorrect Expansion ROM Header Signature 0000 Phase 6: PCI: 00:03.0 init. PCI: pci_dev_init Probing for option ROM Phase 6: Devices initialized. Show all devs... root(Root Device): enabled 1 have_resources 0 initialized 1 cpus: Unknown device path type: 0 cpus(): enabled 1 have_resources 0 initialized 0 device0_0(PCI: 00:00.0): enabled 1 have_resources 1 initialized 1 southbridge_intel_i82371eb(PCI: 00:01.0): enabled 1 have_resources 1 initialized 1 domain0(PCI_DOMAIN: 0000): enabled 1 have_resources 1 initialized 0 dynamic PCI: 00:01.1(PCI: 00:01.1): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:01.3(PCI: 00:01.3): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:02.0(PCI: 00:02.0): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:03.0(PCI: 00:03.0): enabled 1 have_resources 1 initialized 1 LAR: Attempting to open 'normal/option_table'. LAR: Start 0xfffc0000 len 0x3c000 LAR: seen member normal/option_table LAR: CHECK normal/option_table @ 0xfffc0000 start 0xfffc0050 len 932 reallen 932 compression 0 entry 0x00000000 loadaddress 0x00000000 search_global_resources: mask 4200 type 4200 search_global_resources: dev root, have_resources 0 #resources 2 search_global_resources: dev cpus, have_resources 0 #resources 0 search_global_resources: dev device0_0, have_resources 1 #resources 0 search_global_resources: dev southbridge_intel_i82371eb, have_resources 1 #resources 0 search_global_resources: dev domain0, have_resources 1 #resources 3 search_global_resources: dev domain0, resource 0, flags 40040100 base 0x0 size 0x0 search_global_resources: dev domain0, resource 1, flags 40040200 base 0x0 size 0x0 search_global_resources: dev domain0, resource 2, flags e0004200 base 0x0 size 0x8000000 lb_memory_range: start 0x0 size 0x8000000 search_global_resources: dev dynamic PCI: 00:01.1, have_resources 1 #resources 1 search_global_resources: dev dynamic PCI: 00:01.1, resource 0, flags 60000100 base 0x1400 size 0x10 search_global_resources: dev dynamic PCI: 00:01.3, have_resources 1 #resources 0 search_global_resources: dev dynamic PCI: 00:02.0, have_resources 1 #resources 3 search_global_resources: dev dynamic PCI: 00:02.0, resource 0, flags 60001200 base 0xfc000000 size 0x2000000 search_global_resources: dev dynamic PCI: 00:02.0, resource 1, flags 60000200 base 0xfe000000 size 0x1000 search_global_resources: dev dynamic PCI: 00:02.0, resource 2, flags e0002200 base 0xc0000 size 0x0 search_global_resources: dev dynamic PCI: 00:03.0, have_resources 1 #resources 1 search_global_resources: dev dynamic PCI: 00:03.0, resource 0, flags 60000100 base 0x1000 size 0x100 lb_cleanup_memory_ranges: # entries 1 #0: base 0x00000000 size 0x8000000 lb_memory_range: start 0x0 size 0x500 lb_cleanup_memory_ranges: # entries 2 #0: base 0x00000500 size 0x7fffb00 #1: base 0x00000000 size 0x500 lb_memory_range: start 0xf0000 size 0x0 lb_cleanup_memory_ranges: # entries 4 #0: base 0x00000000 size 0x500 #1: base 0x00000500 size 0xefb00 #2: base 0x000f0000 size 0x7f10000 #3: base 0x000f0000 size 0x0 Wrote LinuxBIOS table at: 0x00000500 - 0x00000a84 checksum 2b77 Show all devs... root(Root Device): enabled 1 have_resources 0 initialized 1 cpus: Unknown device path type: 0 cpus(): enabled 1 have_resources 0 initialized 0 device0_0(PCI: 00:00.0): enabled 1 have_resources 1 initialized 1 southbridge_intel_i82371eb(PCI: 00:01.0): enabled 1 have_resources 1 initialized 1 domain0(PCI_DOMAIN: 0000): enabled 1 have_resources 1 initialized 0 dynamic PCI: 00:01.1(PCI: 00:01.1): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:01.3(PCI: 00:01.3): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:02.0(PCI: 00:02.0): enabled 1 have_resources 1 initialized 1 dynamic PCI: 00:03.0(PCI: 00:03.0): enabled 1 have_resources 1 initialized 1 Stage2 code done. LAR: Attempting to open 'normal/payload'. LAR: Start 0xfffc0000 len 0x40000 LAR: seen member normal/option_table LAR: seen member normal/stage2.o/segment0 LAR: seen member normal/stage2.o/segment1 LAR: seen member normal/initram.o/segment0 LAR: seen member bootblock LAR: NO FILE FOUND! LAR: Attempting to open 'normal/payload/segment0'. LAR: Start 0xfffc0000 len 0x40000 LAR: seen member normal/option_table LAR: seen member normal/stage2.o/segment0 LAR: seen member normal/stage2.o/segment1 LAR: seen member normal/initram.o/segment0 LAR: seen member bootblock LAR: NO FILE FOUND! LAR: load_file: No such file 'normal/payload/segment0' newentry is 0xffffffff all loaded, entry 0x00000000 FATAL: No usable payload found.
Acked-by: Ronald G. Minnich rminnich@gmail.com
I'll wait on your patches to do my next bit of work on alix1c :-)
This is great. We killed the blob. In the movie, it was impossible.
ron
On Nov 26, 2007 7:42 PM, ron minnich rminnich@gmail.com wrote:
Acked-by: Ronald G. Minnich rminnich@gmail.com
I'll wait on your patches to do my next bit of work on alix1c :-)
This is great. We killed the blob. In the movie, it was impossible.
FYI, the new approach works on real hardware, I am getting nice printk messages from stage1!
We're on our way!
thanks
ron
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [071127 03:55]:
Convert stage2 handling from binary blob to multi-segment LAR which is created by parsing the ELF file linuxbios.stage2.o. That way, we avoid manual specification of the entry point for stage2 code. A few LAR functions are now unused and can be removed in a following cleanup session. Another suggested cleanup would be factoring out a load_all_segments function, resulting in less code duplication.
I can't believe this is the workaround for not being able to put a "jmp _entry" in front of the code.
It might be becoming just another "how do we explain _that_ to people now?" just like the v2 device tree.
my 2ct
Stefan
On 27.11.2007 06:36, ron minnich wrote:
On Nov 26, 2007 7:42 PM, ron minnich rminnich@gmail.com wrote:
Acked-by: Ronald G. Minnich rminnich@gmail.com
I'll wait on your patches to do my next bit of work on alix1c :-)
This is great. We killed the blob. In the movie, it was impossible.
FYI, the new approach works on real hardware, I am getting nice printk messages from stage1!
You may also need my "v3: fix SHARED macros in the non-_MAINOBJECT case" patch if you are calling stage1 functions (printk, post_code, ...) from any file linked into initram which has _MAINOBJECT not set. Besides that, there is a compiler bug in gcc 4.2.1 (possibly others) which will cause a crash on any call to stage1 functions under the above conditions. I think I can sort of workaround that bug with advanced linker trickery, but I'd rather resolve that bug in a clean way.
We're on our way!
Thanks, r524.
Regards, Carl-Daniel
On Tue, Nov 27, 2007 at 10:33:51AM +0100, Stefan Reinauer wrote:
Convert stage2 handling from binary blob to multi-segment LAR which is created by parsing the ELF file linuxbios.stage2.o.
I can't believe this is the workaround for not being able to put a "jmp _entry" in front of the code.
Come again?
By the way, have we asked gcc/binutils people about suggested ways to do what we want? Maybe they know something we don't?
//Peter
On Nov 27, 2007 1:33 AM, Stefan Reinauer stepan@coresystems.de wrote:
I can't believe this is the workaround for not being able to put a "jmp _entry" in front of the code.
It might be becoming just another "how do we explain _that_ to people now?" just like the v2 device tree.
my 2ct
I think it is ok. What we are doing is moving to a completely uniform way of handling files. They are always ELF, we always process them and produce LAR files. The special case for binary blobs is gone -- I think this is good. We actually use the LAR entry in all cases, since we got rid of binary blobs.
ron
On 27/11/07 10:33 +0100, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [071127 03:55]:
Convert stage2 handling from binary blob to multi-segment LAR which is created by parsing the ELF file linuxbios.stage2.o. That way, we avoid manual specification of the entry point for stage2 code. A few LAR functions are now unused and can be removed in a following cleanup session. Another suggested cleanup would be factoring out a load_all_segments function, resulting in less code duplication.
I can't believe this is the workaround for not being able to put a "jmp _entry" in front of the code.
It might be becoming just another "how do we explain _that_ to people now?" just like the v2 device tree.
I'm not saying that the new method isn't a good one, but Stefan has a point. This will be difficult to explain to people. I'll start with the most obvious question:
How many bytes is it costing me to have N elf files in the LAR instead of N blobs?
Jordan
On Nov 27, 2007 8:04 AM, Jordan Crouse jordan.crouse@amd.com wrote:
I'm not saying that the new method isn't a good one, but Stefan has a point. This will be difficult to explain to people. I'll start with the most obvious question:
How many bytes is it costing me to have N elf files in the LAR instead of N blobs?
Remember, there are no ELF files in the lar. I removed those with the earlier fix when I put ELF processing into LAR for the payloads. Remember that before I made this change we took ELF files and, with no processing, put them in the LAR. That was a mess! Sometimes you'd flash and boot and find out the ELF files were no good.
Now there are only LAR files. And they're all the same thing: LAR header + name. All I did a a while ago was move ELF *payload* parsing out of linuxbios and into lar, so we would never again find out, after having flashed a new bios, that the ELF file we flashed was invalid ... we made a runtime check into a build time check. in the process, we removed a significant source of error, and made the startup way more efficient -- no need to create an intermediate copy of the data, no need for the horrible 'relocate my code' stuff from v2, remove one whole copy from the startup path. This change was good for data that got moved to memory.
But, ELF parsing in LAR applied to payload only. It did not apply to our own code segments, such as the initram binary blob. We still had a lot of weird processing for turning things from ELF files and binary blobs and then putting them into LAR, complete with a LAR header that was full of misinformation (like the entry point, which was '0'). Now why is this? It's historical. It's how we did it in V2. That's the only reason I can see.
There's no other reason for binary blobs that I can think of.
Result? We had two different ways of processing executable files, one in which we parsed ELF, and one in which we did not. In retrospect, that doesn't make a lot of sense.
So all the change is really saying is, "you have an elf parser in LAR, and it made life better for payloads, why not use it for your other .o stuff and get rid of binary blob processing? Just make everything done the same way?"
For the binary blob, the extra cost is 0 for the header and we grew the name by these bytes: ".o/segment0", so about 11 bytes. There was a LAR header already for the binary blob. It's just that the lar header was totally wrong, because you can't find the entry point from a binary blob.
I am worried that this seems to be confusing people. From my point of view we did the following: 1. removed the objcopy -o binary parts (and remember, we've had trouble with even objcopy over the years) 2. made the processing for all lar files identical -- always parse elf and produce lar entries 3. don't have to fight to try to make gcc order functions in a file correctly 4. don't have to add switches to lar to pass entry point information to it. 5. don't have to figure out how to add a 'jmp to main' instruction at the front of the binary blob
So it seems to me we've reduced the number of variables in the equation. To me it's less complex. I hope it seems that way once you look at it more, but we'll see ...
thanks, remember, this is v3, it's not out yet, nothing is cast in stone.
ron
On Nov 27, 2007 8:33 AM, Jordan Crouse jordan.crouse@amd.com wrote:
Also, I would abandon the use of .o naming in the LAR - that will drive others (like me) off course thinking an object file is living in the LAR, which is not the case.
your summary is correct. And, we should change the name. Carl-daniel, suggestions?
ron
Okay, let me see if I can make this clearer:
You are feeding ELF binaries into LAR instead of binary blobs.
So call it what it is - a useful option to LAR to cut out the objcopy middleman. Which is fine. I'm happy with that.
Also, I would abandon the use of .o naming in the LAR - that will drive others (like me) off course thinking an object file is living in the LAR, which is not the case.
JOrdan
On 27/11/07 08:18 -0800, ron minnich wrote:
On Nov 27, 2007 8:04 AM, Jordan Crouse jordan.crouse@amd.com wrote:
I'm not saying that the new method isn't a good one, but Stefan has a point. This will be difficult to explain to people. I'll start with the most obvious question:
How many bytes is it costing me to have N elf files in the LAR instead of N blobs?
Remember, there are no ELF files in the lar. I removed those with the earlier fix when I put ELF processing into LAR for the payloads. Remember that before I made this change we took ELF files and, with no processing, put them in the LAR. That was a mess! Sometimes you'd flash and boot and find out the ELF files were no good.
Now there are only LAR files. And they're all the same thing: LAR header + name. All I did a a while ago was move ELF *payload* parsing out of linuxbios and into lar, so we would never again find out, after having flashed a new bios, that the ELF file we flashed was invalid ... we made a runtime check into a build time check. in the process, we removed a significant source of error, and made the startup way more efficient -- no need to create an intermediate copy of the data, no need for the horrible 'relocate my code' stuff from v2, remove one whole copy from the startup path. This change was good for data that got moved to memory.
But, ELF parsing in LAR applied to payload only. It did not apply to our own code segments, such as the initram binary blob. We still had a lot of weird processing for turning things from ELF files and binary blobs and then putting them into LAR, complete with a LAR header that was full of misinformation (like the entry point, which was '0'). Now why is this? It's historical. It's how we did it in V2. That's the only reason I can see.
There's no other reason for binary blobs that I can think of.
Result? We had two different ways of processing executable files, one in which we parsed ELF, and one in which we did not. In retrospect, that doesn't make a lot of sense.
So all the change is really saying is, "you have an elf parser in LAR, and it made life better for payloads, why not use it for your other .o stuff and get rid of binary blob processing? Just make everything done the same way?"
For the binary blob, the extra cost is 0 for the header and we grew the name by these bytes: ".o/segment0", so about 11 bytes. There was a LAR header already for the binary blob. It's just that the lar header was totally wrong, because you can't find the entry point from a binary blob.
I am worried that this seems to be confusing people. From my point of view we did the following:
- removed the objcopy -o binary parts (and remember, we've had
trouble with even objcopy over the years) 2. made the processing for all lar files identical -- always parse elf and produce lar entries 3. don't have to fight to try to make gcc order functions in a file correctly 4. don't have to add switches to lar to pass entry point information to it. 5. don't have to figure out how to add a 'jmp to main' instruction at the front of the binary blob
So it seems to me we've reduced the number of variables in the equation. To me it's less complex. I hope it seems that way once you look at it more, but we'll see ...
thanks, remember, this is v3, it's not out yet, nothing is cast in stone.
ron
On Tue, Nov 27, 2007 at 09:33:29AM -0700, Jordan Crouse wrote:
So call it what it is - a useful option to LAR to cut out the objcopy middleman. Which is fine. I'm happy with that.
It's even a bit better since the objcopy would destroy the entry point.
Also, I would abandon the use of .o naming in the LAR - that will drive others (like me) off course thinking an object file is living in the LAR, which is not the case.
The "object file" is now a subdirectory in the lar - blah.o/segment0
Perhaps too subtle in a new archive format? I think it's OK as long as we have good docs for lar explaining why we've created it and how it is supposed to work.
//Peter
On 27.11.2007 17:04, Jordan Crouse wrote:
On 27/11/07 10:33 +0100, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [071127 03:55]:
Convert stage2 handling from binary blob to multi-segment LAR which is created by parsing the ELF file linuxbios.stage2.o. That way, we avoid manual specification of the entry point for stage2 code. A few LAR functions are now unused and can be removed in a following cleanup session. Another suggested cleanup would be factoring out a load_all_segments function, resulting in less code duplication.
I can't believe this is the workaround for not being able to put a "jmp _entry" in front of the code.
It might be becoming just another "how do we explain _that_ to people now?" just like the v2 device tree.
I'm not saying that the new method isn't a good one, but Stefan has a point. This will be difficult to explain to people. I'll start with the most obvious question:
How many bytes is it costing me to have N elf files in the LAR instead of N blobs?
Bytes in RAM: We save ~3000 bytes in qemu (subject to verification). Bytes in LAR: We lose 64 bytes per additional ELF section (that includes 7 bytes of filename).
But if we ever really want to save single bytes, attacking the wasted ~4000 bytes in the boot block is definitely the most promising route to go.
Oh, and applying my patch which eliminates dulicated functions from stage2 will also yield substantial savings.
Regards, Carl-Daniel
On 27/11/07 08:29 -0800, ron minnich wrote:
On Nov 27, 2007 8:33 AM, Jordan Crouse jordan.crouse@amd.com wrote:
Also, I would abandon the use of .o naming in the LAR - that will drive others (like me) off course thinking an object file is living in the LAR, which is not the case.
your summary is correct. And, we should change the name. Carl-daniel, suggestions?
I do want to emphasise that I really like this plan, it makes a lot of sense to me.
For the filename, we could figure out a good way to add it to the .comment section of the ELF - that could open up a new world of passing information to LAR via the .o without the command line. Or am I super double guilty for invoking black magic?
NetBSD has a tool called mcs that does something simlar.
Jordan
On 27.11.2007 17:18, ron minnich wrote:
On Nov 27, 2007 8:04 AM, Jordan Crouse jordan.crouse@amd.com wrote:
I'm not saying that the new method isn't a good one, but Stefan has a point. This will be difficult to explain to people. I'll start with the most obvious question:
How many bytes is it costing me to have N elf files in the LAR instead of N blobs?
Remember, there are no ELF files in the lar. I removed those with the earlier fix when I put ELF processing into LAR for the payloads. Remember that before I made this change we took ELF files and, with no processing, put them in the LAR. That was a mess! Sometimes you'd flash and boot and find out the ELF files were no good.
Now there are only LAR files. And they're all the same thing: LAR header + name. All I did a a while ago was move ELF *payload* parsing out of linuxbios and into lar, so we would never again find out, after having flashed a new bios, that the ELF file we flashed was invalid ... we made a runtime check into a build time check. in the process, we removed a significant source of error, and made the startup way more efficient -- no need to create an intermediate copy of the data, no need for the horrible 'relocate my code' stuff from v2, remove one whole copy from the startup path. This change was good for data that got moved to memory.
But, ELF parsing in LAR applied to payload only. It did not apply to our own code segments, such as the initram binary blob. We still had a lot of weird processing for turning things from ELF files and binary blobs and then putting them into LAR, complete with a LAR header that was full of misinformation (like the entry point, which was '0'). Now why is this? It's historical. It's how we did it in V2. That's the only reason I can see.
There's no other reason for binary blobs that I can think of.
Result? We had two different ways of processing executable files, one in which we parsed ELF, and one in which we did not. In retrospect, that doesn't make a lot of sense.
So all the change is really saying is, "you have an elf parser in LAR, and it made life better for payloads, why not use it for your other .o stuff and get rid of binary blob processing? Just make everything done the same way?"
For the binary blob, the extra cost is 0 for the header and we grew the name by these bytes: ".o/segment0", so about 11 bytes. There was a LAR header already for the binary blob. It's just that the lar header was totally wrong, because you can't find the entry point from a binary blob.
I am worried that this seems to be confusing people. From my point of view we did the following:
- removed the objcopy -o binary parts (and remember, we've had
trouble with even objcopy over the years) 2. made the processing for all lar files identical -- always parse elf and produce lar entries 3. don't have to fight to try to make gcc order functions in a file correctly 4. don't have to add switches to lar to pass entry point information to it. 5. don't have to figure out how to add a 'jmp to main' instruction at the front of the binary blob
So it seems to me we've reduced the number of variables in the equation. To me it's less complex. I hope it seems that way once you look at it more, but we'll see ...
thanks, remember, this is v3, it's not out yet, nothing is cast in stone.
Very well said. Can you stuff that complete e-mail into the design doc?
Regards, Carl-Daniel
On Tue, Nov 27, 2007 at 09:44:18AM -0700, Jordan Crouse wrote:
For the filename, we could figure out a good way to add it to the .comment section of the ELF - that could open up a new world of passing information to LAR via the .o without the command line. Or am I super double guilty for invoking black magic?
FILO explicitly gets rid of all ELF notes during build, except the name/version for elfboot, with a reference to gcc producing many junk notes.
Another thought:
While it's probably quite possible to send stuff from .c to larball - is this really something we want to do?
Should non-code information in .c really have to be in the larball?
Or, put a bit differently, should the file in the larball really need to have information from a .c that is not code?
//Peter
On 27.11.2007 10:33, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [071127 03:55]:
Convert stage2 handling from binary blob to multi-segment LAR which is created by parsing the ELF file linuxbios.stage2.o. That way, we avoid manual specification of the entry point for stage2 code. A few LAR functions are now unused and can be removed in a following cleanup session. Another suggested cleanup would be factoring out a load_all_segments function, resulting in less code duplication.
I can't believe this is the workaround for not being able to put a "jmp _entry" in front of the code.
It is certainly easier to understand than a linker script which tries to move a "jmp _entry" to the front of the blob.
It might be becoming just another "how do we explain _that_ to people now?" just like the v2 device tree.
See Ron's mail about that subject. He put it in a very elaborate way.
Regards, Carl-Daniel
On 27.11.2007 17:29, ron minnich wrote:
On Nov 27, 2007 8:33 AM, Jordan Crouse jordan.crouse@amd.com wrote:
Also, I would abandon the use of .o naming in the LAR - that will drive others (like me) off course thinking an object file is living in the LAR, which is not the case.
your summary is correct. And, we should change the name. Carl-daniel, suggestions?
Yes. How about: old way: normal/stage2.o/segment0 normal/stage2.o/segment1 new 1: normal/stage2/seg0 normal/stage2/seg1 new 2: normal/stage2/0 normal/stage2/1
I prefer having seg in the name to make it obvious that these are segments. Together with a function void *load_all_segments(struct mem_file *archive, char *filename) which returns the entry point and is called like this from stage1: entry = load_all_segments(&archive, "normal/stage2"); handling should get a lot easier. Basically, people should not have to care about segments.
Regards, Carl-Daniel
* ron minnich rminnich@gmail.com [071127 17:18]:
Remember, there are no ELF files in the lar. I removed those with the earlier fix when I put ELF processing into LAR for the payloads. Remember that before I made this change we took ELF files and, with no processing, put them in the LAR. That was a mess! Sometimes you'd flash and boot and find out the ELF files were no good.
With all this, if I unpack a LAR archive, and repack it again, will it still produce a working archive?
All I did a a while ago was move ELF *payload* parsing out of linuxbios and into lar, so we would never again find out, after having flashed a new bios, that the ELF file we flashed was invalid
.. I think this broke at least OFW as a payload. But that's a different story. In general I agree ELF parsing does not necessarily belong into the core firmware. Interesting to see how many broken ELF files are out there these days.
Result? We had two different ways of processing executable files, one in which we parsed ELF, and one in which we did not. In retrospect, that doesn't make a lot of sense.
agreed.
Stefan
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [071127 18:01]:
Yes. How about: old way: normal/stage2.o/segment0 normal/stage2.o/segment1 new 1: normal/stage2/seg0 normal/stage2/seg1 new 2: normal/stage2/0 normal/stage2/1
I prefer having seg in the name to make it obvious that these are segments.
Then just leave the name segment. It doesn't significantly safe space to abbreviate here. I like dropping .o in the name though.
Stefan
On Nov 27, 2007 9:22 AM, Stefan Reinauer stepan@coresystems.de wrote:
With all this, if I unpack a LAR archive, and repack it again, will it still produce a working archive?
No, it won't. You lose the entry point info. We would have to unpack LAR to ELF files. This is a limitation I had not thought of. Should I have an option to unpack to elf? It would not be hard.
.. I think this broke at least OFW as a payload. But that's a different story. In general I agree ELF parsing does not necessarily belong into the core firmware. Interesting to see how many broken ELF files are out there these days.
Sorry to hear about OFW, how do we fix it?
ron
* ron minnich rminnich@gmail.com [071127 18:27]:
On Nov 27, 2007 9:22 AM, Stefan Reinauer stepan@coresystems.de wrote:
With all this, if I unpack a LAR archive, and repack it again, will it still produce a working archive?
No, it won't. You lose the entry point info. We would have to unpack LAR to ELF files. This is a limitation I had not thought of. Should I have an option to unpack to elf? It would not be hard.
Hm.. either that, or we should go and write a "MANIFEST" file, containing the extra meta data. Or a combination?
Sorry to hear about OFW, how do we fix it?
It has a dummy ELF header and loads parts of itself later on. Easy way: copy it all to ram and work from there. There are better ways. We'll find out.
Stefan
On Tue, Nov 27, 2007 at 06:26:23PM +0100, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [071127 18:01]:
Yes. How about: old way: normal/stage2.o/segment0 normal/stage2.o/segment1 new 1: normal/stage2/seg0 normal/stage2/seg1 new 2: normal/stage2/0 normal/stage2/1
I prefer having seg in the name to make it obvious that these are segments.
Then just leave the name segment. It doesn't significantly safe space to abbreviate here. I like dropping .o in the name though.
ACK for both.
Uwe.
On 27/11/07 18:51 +0100, Stefan Reinauer wrote:
- ron minnich rminnich@gmail.com [071127 18:27]:
On Nov 27, 2007 9:22 AM, Stefan Reinauer stepan@coresystems.de wrote:
With all this, if I unpack a LAR archive, and repack it again, will it still produce a working archive?
No, it won't. You lose the entry point info. We would have to unpack LAR to ELF files. This is a limitation I had not thought of. Should I have an option to unpack to elf? It would not be hard.
Hm.. either that, or we should go and write a "MANIFEST" file, containing the extra meta data. Or a combination?
At some point, I predect we're going to end up needing a MANIFEST file, we might as well do it now. Then that covers us from all possible directions. Right now things work for ELF, but someday somebody will want COFF, or CE binary format or something like that and it will through the universe into flux. If we have the manifest file, then we are covered in all cases.
Jordan
Sorry to hear about OFW, how do we fix it?
It has a dummy ELF header and loads parts of itself later on. Easy way: copy it all to ram and work from there. There are better ways. We'll find out.
Stefan
-- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
On 27.11.2007 18:27, ron minnich wrote:
On Nov 27, 2007 9:22 AM, Stefan Reinauer stepan@coresystems.de wrote:
With all this, if I unpack a LAR archive, and repack it again, will it still produce a working archive?
No, it won't. You lose the entry point info. We would have to unpack LAR to ELF files. This is a limitation I had not thought of. Should I have an option to unpack to elf? It would not be hard.
I suggested that when you were introducing the ELF parsing to lar. So yes, I still think this si a good idea.
Regards, Carl-Daniel
On Nov 27, 2007 10:25 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
I suggested that when you were introducing the ELF parsing to lar. So yes, I still think this si a good idea.
the mindprobe must have wiped those neurons out. OK, I'll try to do this but not this week :-)
ron
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Peter Stuge -
ron minnich -
Stefan Reinauer -
Uwe Hermann