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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
