* [U-Boot] u-boot on x86 reloaded @ 2011-05-04 8:54 Rudolf Marek 2011-05-04 11:35 ` Graeme Russ 0 siblings, 1 reply; 5+ messages in thread From: Rudolf Marek @ 2011-05-04 8:54 UTC (permalink / raw) To: u-boot Hello, I was asked to post it here too. I would like to announce that I was able to boot Linux using u-boot on AMD64 motherboard Asrock 939A785G. The development was done on QEMU. How does it work? Coreboot does the complete HW init including memory setup PCI etc. When finishes it loads u-boot. Coreboot is free software replacement for BIOS, but unlike BIOS it only does the hardware init (and ACPI). A payload needs to be executed which does something useful for the user (like a linux kernel, SeaBIOS, FILO, grub etc) You can read more about coreboot on http://coreboot.org How the porting was done is described here: http://blogs.coreboot.org/blog/2011/04/30/u-boot-as-coreboot-payload/ http://www.coreboot.org/pipermail/coreboot/2011-April/064877.html http://www.coreboot.org/pipermail/coreboot/2011-May/064914.html http://www.coreboot.org/pipermail/coreboot/2011-May/064915.html And boot log http://assembler.cz/minicom42.txt This project started "just for fun" or "because I can". Maybe there are some real uses. If you can think of some, please let me know. Anyone with more free time could work on this? I'm not subscribed, please cc me. I'm ccing coreboot mailing list too. Thanks, Rudolf ^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] u-boot on x86 reloaded 2011-05-04 8:54 [U-Boot] u-boot on x86 reloaded Rudolf Marek @ 2011-05-04 11:35 ` Graeme Russ 2011-05-04 12:37 ` Rudolf Marek 2011-05-07 17:14 ` [U-Boot] [coreboot] " Kevin O'Connor 0 siblings, 2 replies; 5+ messages in thread From: Graeme Russ @ 2011-05-04 11:35 UTC (permalink / raw) To: u-boot On 04/05/11 18:54, Rudolf Marek wrote: > Hello, > > I was asked to post it here too. > > I would like to announce that I was able to boot Linux using u-boot on AMD64 > motherboard Asrock 939A785G. The development was done on QEMU. Excellent - U-Boot on a new x86 board > > How does it work? > > Coreboot does the complete HW init including memory setup PCI etc. When finishes > it loads u-boot. This is one of the ways I was thinking of getting U-Boot running on mainstream PC boards. The other is to create U-Boot as a GRUB payload. Either way, it's all about getting the SDRAM initialised [Snip] > How the porting was done is described here: > > http://blogs.coreboot.org/blog/2011/04/30/u-boot-as-coreboot-payload/ Excellent write-up - Thanks! > > http://www.coreboot.org/pipermail/coreboot/2011-April/064877.html > http://www.coreboot.org/pipermail/coreboot/2011-May/064914.html > http://www.coreboot.org/pipermail/coreboot/2011-May/064915.html > > And boot log http://assembler.cz/minicom42.txt > > This project started "just for fun" or "because I can". Maybe there are some > real uses. If you can think of some, please let me know. Well, that's why I started too - kudos for the effort > > Anyone with more free time could work on this? Well I did have someone else contact me about doing exactly as you have done (I have Bcc'd him in case he is interested) As the U-Boot x86 maintainer, I am extremely interested in going further with this and am keen to help get your work mainlined > > I'm not subscribed, please cc me. I'm ccing coreboot mailing list too. > OK, a few little points which may help answer some questions you didn't realise you even had ;) - The build warnings and errors you incurred are probably fixed in mainline (x86 is a bit of a forgotten cousin which gets broken when global patches are made to Makefile, linker scripts etc). If you still have problems compiling the latest U-Boot git head, please post them to the mailing list and I'll sort them out ASAP - The x86 port of U-Boot was the first to implement the (now pretty much standard) relocation scheme. Understanding it is a Very Good Idea(tm) - SYS_TEXT_BASE=0?19000000 is very specific to the eNET - It is the start of non-volatile (battery backed) SRAM. We can run from SRAM prior to initialising SDRAM, so I use it as an alternative to Flash for testing new builds (reset -> TFTP new image to 0x19000000 -> go 19000000) - When launching U-Boot as a payload from Coreboot, you really don't need to worry about what is at the end of the image (reset vector and jump to protected mode). All the fun begins at the first byte of u-boot.bin which is the first line of code in start.S - CONFIG_SYS_INIT_SP_ADDR is a temporary stack pointer which is used during the relocation of U-Boot from ROM (Flash) into SDRAM. Typically the CPU's Cache-As-RAM (CAR) capability is used. However, if SDRAM is already initialised, you can set CONFIG_SYS_INIT_SP_ADDR to anywhere in SDRAM that will not get clobbered by the relocation - I'm in the middle of re-writing the entire real-mode switch code and real-mode support in U-Boot. The new code allows you to write real-mode code in C - I even have the Linux real-mode printf ported :) This will make writing your own 'BIOS' code for your board a lot easier - Ultimately, I would like to bypass Linux's real-mode stub (like GRUB) and ditch the real-mode code (for the purpose of booting Linux) I would really like to see some U-Boot patches on the mailing list - Technically U-Boot is meant to be a stand-alone and self-sufficient, but I think for x86 there is merit in creating board configuration that gets boot-strapped by Coreboot (we just need to make sure the documentation is up-to-scratch) Looking forward to moving this forward Regards, Graeme ^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] u-boot on x86 reloaded 2011-05-04 11:35 ` Graeme Russ @ 2011-05-04 12:37 ` Rudolf Marek 2011-05-07 12:39 ` Graeme Russ 2011-05-07 17:14 ` [U-Boot] [coreboot] " Kevin O'Connor 1 sibling, 1 reply; 5+ messages in thread From: Rudolf Marek @ 2011-05-04 12:37 UTC (permalink / raw) To: u-boot Hello all, > Excellent - U-Boot on a new x86 board Yes and in general any supported coreboot board. > This is one of the ways I was thinking of getting U-Boot running on > mainstream PC boards. The other is to create U-Boot as a GRUB payload. > Either way, it's all about getting the SDRAM initialised Not only, also HyperTransport, complex PCI stuff, power mngmt etc, lots of lots of stuff. > Well, that's why I started too - kudos for the effort Thanks. >> Anyone with more free time could work on this? > > Well I did have someone else contact me about doing exactly as you have > done (I have Bcc'd him in case he is interested) > > As the U-Boot x86 maintainer, I am extremely interested in going further > with this and am keen to help get your work mainlined Ok > OK, a few little points which may help answer some questions you didn't > realise you even had ;) > > - The build warnings and errors you incurred are probably fixed in > mainline (x86 is a bit of a forgotten cousin which gets broken when global > patches are made to Makefile, linker scripts etc). If you still have > problems compiling the latest U-Boot git head, please post them to the > mailing list and I'll sort them out ASAP The links to the coreboot mailing list contain some patches. > - The x86 port of U-Boot was the first to implement the (now pretty much > standard) relocation scheme. Understanding it is a Very Good Idea(tm) > - SYS_TEXT_BASE=0?19000000 is very specific to the eNET - It is the start > of non-volatile (battery backed) SRAM. We can run from SRAM prior to > initialising SDRAM, so I use it as an alternative to Flash for testing new > builds (reset -> TFTP new image to 0x19000000 -> go 19000000) Yes I move that to 16MB boundary to load it just into RAM. u-boot ELF can be loaded from coreboot, where it is stored compressed. > - When launching U-Boot as a payload from Coreboot, you really don't need > to worry about what is at the end of the image (reset vector and jump to > protected mode). All the fun begins at the first byte of u-boot.bin which > is the first line of code in start.S I think it jumps to _start which is 32 bit entry point. The coreboot is in flat mode 32bit. > - CONFIG_SYS_INIT_SP_ADDR is a temporary stack pointer which is used > during the relocation of U-Boot from ROM (Flash) into SDRAM. Typically the > CPU's Cache-As-RAM (CAR) capability is used. However, if SDRAM is already > initialised, you can set CONFIG_SYS_INIT_SP_ADDR to anywhere in SDRAM that > will not get clobbered by the relocation Yes I set it to 256KB boundary. > - I'm in the middle of re-writing the entire real-mode switch code and > real-mode support in U-Boot. The new code allows you to write real-mode > code in C - I even have the Linux real-mode printf ported :) This will make > writing your own 'BIOS' code for your board a lot easier Well I liked here that there is no BIOS at all. The SeaBIOS is the layer used by coreboot to have full legacy BIOS stuff. This is used by KVM/Qenu too. The coreboot can do VGA init (it has kind of BIOS emulation stuff for this) so at the end VGA + keyboard could be possible. I guess if u-boot is for linux loading, then we need to add e820 stuff to have support for over 4GB of memory. > - Ultimately, I would like to bypass Linux's real-mode stub (like GRUB) > and ditch the real-mode code (for the purpose of booting Linux) This is done in FILO. Check http://www.coreboot.org/FILO I guess it can be just ported. The coreboot will provide the memory map and this is how the FILO is doing that, just transforming it and passing it directly to kernel. > I would really like to see some U-Boot patches on the mailing list - > Technically U-Boot is meant to be a stand-alone and self-sufficient, but I > think for x86 there is merit in creating board configuration that gets > boot-strapped by Coreboot (we just need to make sure the documentation is > up-to-scratch) The patches are just now on coreboot mailing list. It is just a hack, because there are places which needs to be fixed, the computation of place for the realmode and bios sections needs to be fixed. I added the coreboot as a board and subarchitecture. What is specific is that we will need to copy "MPtable" "PIR" and "RSDP" pointer to F-segment just after the bios section. The memory map can be read out of coreboot tables stored in high mem. Also a PCI mem stuff should be fixed in u-boot. Also if we get rid of the .bios and .realmode section then the problem that those two sections are not relocated to end of memory disappears. > Looking forward to moving this forward Good. Please check the patches on coreboot ml and feel free to join #coreboot channel. I'm in both now as "ruik". Thanks, Rudolf ^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] u-boot on x86 reloaded 2011-05-04 12:37 ` Rudolf Marek @ 2011-05-07 12:39 ` Graeme Russ 0 siblings, 0 replies; 5+ messages in thread From: Graeme Russ @ 2011-05-07 12:39 UTC (permalink / raw) To: u-boot Hi Rodulf, On 04/05/11 22:37, Rudolf Marek wrote: > Hello all, > [snip] >> - The build warnings and errors you incurred are probably fixed in >> mainline (x86 is a bit of a forgotten cousin which gets broken when global >> patches are made to Makefile, linker scripts etc). If you still have >> problems compiling the latest U-Boot git head, please post them to the >> mailing list and I'll sort them out ASAP > > The links to the coreboot mailing list contain some patches. > Ok - I see two fixes needed (one in bios_setup.c and one in realmode.c). These are both effectively in my realmode re-write, but if you can send through a patch to fix them in the meantime, that would be great >> - When launching U-Boot as a payload from Coreboot, you really don't need >> to worry about what is at the end of the image (reset vector and jump to >> protected mode). All the fun begins at the first byte of u-boot.bin which >> is the first line of code in start.S > > I think it jumps to _start which is 32 bit entry point. The coreboot is in > flat mode 32bit. > If you look at start.S, you will see a tiny bit of code before _start which is the 'warm boot' entry point: cli cld /* Turn of cache (this might require a 486-class CPU) */ movl %cr0, %eax orl $(X86_CR0_NW | X86_CR0_CD), %eax movl %eax, %cr0 wbinvd /* Tell 32-bit code it is being entered from an in-RAM copy */ movw $GD_FLG_WARM_BOOT, %bx Looking at coreboot in src/arch/x86/lib/c_start.S it appears coreboot and U-Boot use the same GDT for code (0x10) and data (0x18) in a flat protected mode configuration. We can probably make that a little more robust by jumping over the segment register loads during warm-boot and just use whatever coreboot gives us. U-Boot will wipe it all clean later anyway (see arch/x86/cpu/x86_cpu_init_r) - x86_cpu_init_r calls reload_gdt() after U-Boot has been relocated. So if you build u-boot.bin with TEXT_BASE set wherever it will end up in the coreboot image then you can just have coreboot jump to TEXT_BASE. Now as for booting an ELF image, maybe the linker script needs to be tweaked to set the entry point to _x86boot_start rather than _start >> - CONFIG_SYS_INIT_SP_ADDR is a temporary stack pointer which is used >> during the relocation of U-Boot from ROM (Flash) into SDRAM. Typically the >> CPU's Cache-As-RAM (CAR) capability is used. However, if SDRAM is already >> initialised, you can set CONFIG_SYS_INIT_SP_ADDR to anywhere in SDRAM that >> will not get clobbered by the relocation > > Yes I set it to 256KB boundary. Sounds reasonable - but you really need to set it to somewhere you know there is physical RAM. Maybe this could be passed in a register in the warm boot scenario and the address determined by coreboot [big snip - we'll deal with real-mode / BIOS later] >> I would really like to see some U-Boot patches on the mailing list - >> Technically U-Boot is meant to be a stand-alone and self-sufficient, but I >> think for x86 there is merit in creating board configuration that gets >> boot-strapped by Coreboot (we just need to make sure the documentation is >> up-to-scratch) > > The patches are just now on coreboot mailing list. It is just a hack, > because there are places which needs to be fixed, the computation of place > for the realmode and bios sections needs to be fixed. I added the coreboot > as a board and subarchitecture. I've had a chance to look at them, and the impact on U-Boot is surprisingly minimal. A few comments: -PLATFORM_CPPFLAGS += -DCONFIG_X86 -D__I386__ -march=i386 -Werror +PLATFORM_CPPFLAGS += -DCONFIG_X86 -D__I386__ -march=i386 NACK - Do not remove -Werror -LDPPFLAGS += -DRESET_SEG_START=0xffff0000 +LDPPFLAGS += -DRESET_SEG_START=0xFF0000 NACK - As mentioned above, I see no reason to mess with this. Set TEXT_BASE to be the location of U-Boot in the coreboot flash image and simply jump to it. In /arch/x86/cpu/interrupts.c you add setup_i8259() and call it in cpu_init_interrupts() which is called from cpu_init_r() - This is the wrong place to be setting up the PIC (this file initialises the CPU interrupt sub-system, not the external glue logic). And how is setup_i8259() different from interrupt_init() found in arch/x86/lib/pcat_interrupt.c? Now the problem could be that interrupt_init() is called after cpu_init_r() - i.e. the CPU interrupt sub-system is setup before the PIC has been configured. Maybe the PIC should be configured prior to relocation (and therefore prior to initialisation of the CPU interrupt sub-system). Lets look at moving that to board_early_init_f() Apart from that, the patches look 'promising' ;) Now, for me to officially consider them, they need to be posted to the U-Boot mailing list using git format-patch / git send-email AFTER they have been run through checkpatch (which can be found in the Linux source under scripts/). You patches will end up in patchwork where they will be managed > > What is specific is that we will need to copy "MPtable" "PIR" and "RSDP" > pointer to F-segment just after the bios section. The memory map can be > read out of coreboot tables stored in high mem. Also a PCI mem stuff should > be fixed in u-boot. > > Also if we get rid of the .bios and .realmode section then the problem that > those two sections are not relocated to end of memory disappears. I think these can be dealt with later > >> Looking forward to moving this forward > > Good. Please check the patches on coreboot ml and feel free to join > #coreboot channel. I'm in both now as "ruik". I've re-joined the coreboot ml. Any discussions on U-Boot patches need to be conducted on the U-Boot ml so we can all comment. > > Thanks, > Rudolf > Regards, Graeme ^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] [coreboot] u-boot on x86 reloaded 2011-05-04 11:35 ` Graeme Russ 2011-05-04 12:37 ` Rudolf Marek @ 2011-05-07 17:14 ` Kevin O'Connor 1 sibling, 0 replies; 5+ messages in thread From: Kevin O'Connor @ 2011-05-07 17:14 UTC (permalink / raw) To: u-boot On Wed, May 04, 2011 at 09:35:46PM +1000, Graeme Russ wrote: > - I'm in the middle of re-writing the entire real-mode switch code and > real-mode support in U-Boot. The new code allows you to write real-mode > code in C - I even have the Linux real-mode printf ported :) This will make > writing your own 'BIOS' code for your board a lot easier FYI - SeaBIOS ( http://seabios.org/ ) uses gcc for real-mode code. Indeed, the name "SeaBIOS" is a play on words - it's a BIOS written in C code. -Kevin ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-05-07 17:14 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-05-04 8:54 [U-Boot] u-boot on x86 reloaded Rudolf Marek 2011-05-04 11:35 ` Graeme Russ 2011-05-04 12:37 ` Rudolf Marek 2011-05-07 12:39 ` Graeme Russ 2011-05-07 17:14 ` [U-Boot] [coreboot] " Kevin O'Connor
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.