[U-Boot] building u-boot x86 with device tree disabled , still refers to device tree function

[Simon Glass]

Hi,

On 17 August 2016 at 06:59, Ding, ChiX <chix.ding at intel.com> wrote:
> Hi Simon
> We have an older version u-boot code that is built without device tree.
> It works fine as coreboot payload on the target board with Denverton chipset.
> With the current u-boot code from git://git.denx.de/u-boot.git, I run coreboot-x86_defconfig,
> then make menuconfig, and by default qemu-x86 is the target board. I use device tree in the
> beginning which is enalbed by default, but I didn't see the dts file for my target board.
> Since I'm new to the bootloader world, I 'm not sure how to define it correctly for my target board.
> I did experiments of the dst file and menuconfig to use it, but the built u-boot file doesn't work
> properly as Coreboot payload when booting : it gets stuck when jumping into u-boot from coreboot.
>
> Jumping to boot code at 01110020(7f6ea000)
> CPU0: stack: 0012d000 - 0012e000, lowest used address 0012d9cc, stack used: 1588 bytes
> entry    = 0x01110020
> lb_start = 0x00100000
> lb_size  = 0x00036870
> buffer   = 0x7f67c000
>
> After that I tried to use the board configure file instead (taken from my older version u-boot code) of device tree, therefore I disabled device tree in menuconfig. That's how my question comes from.
>
> I also tried to make u-boot work as payload of coreboot on qemu-x86.
> I ran make dist clean, make coreboot-x86_defconfig and built uboot using the default menuconfig setting of device tree enabled, and embedded
> Then I built coreboot using u-boot as ELF payload. Somehow when I run it with qemu-86, it crashes inside uboot :
>
>
> [root at localhost cid_iafw_opensource-coreboot]# qemu-system-x86_64 --nographic -bios build/coreboot.rom
>
>
> U-Boot 2016.09-rc1-00324-g2863a9b-dirty (Aug 12 2016 - 11:13:50 +0100)
>
> CPU: x86_64, vendor AMD, device 663h
> DRAM:  127.6 MiB
> Using default environment
>
> Video: No video mode configured in coreboot!
> Model: QEMU x86 (I440FX)
> Net:   General Protection
> EIP: 0010:[<07f1440a>] EFLAGS: 00000002
> Original EIP :[<0111040a>]
> EAX: 00000002 EBX: 07d15668 ECX: 00000001 EDX: c0020000
> ESI: 00000041 EDI: 000000c8 EBP: 00010001 ESP: 07d129d4
> DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018
> CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000000
> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> DR6: ffff0ff0 DR7: 00000400
> Stack:
>    0x07d12a14 : 0x00000001
>     0x07d12a10 : 0x00000000
>     0x07d12a0c : 0x07d15668
>     0x07d12a08 : 0x00000000
>     0x07d12a04 : 0x159dc191
>     0x07d12a00 : 0x00000000
>     0x07d129fc : 0x00000000
>     0x07d129f8 : 0x00001800
>     0x07d129f4 : 0x00000001
>     0x07d129f0 : 0x07d12a5c
>     0x07d129ec : 0x07f35f29
>     0x07d129e8 : 0x07d15668
>     0x07d129e4 : 0x00000001
>     0x07d129e0 : 0x00000001
>     0x07d129dc : 0x00000202
>     0x07d129d8 : 0x00000010
> --->0x07d129d4 : 0x07f35efc
>     0x07d129d0 : 0x00000002
>     0x07d129cc : 0x00000010
>     0x07d129c8 : 0x07f1440a
> ### ERROR ### Please RESET the board ###
>
> When looking at the code, I see it crashes here
> /* IRQ Low-Level Service Routine */
> void irq_llsr(struct irq_regs *regs)
> {
>         /*
>          * For detailed description of each exception, refer to:
>          * Intel® 64 and IA-32 Architectures Software Developer's Manual
>          * Volume 1: Basic Architecture
>          * Order Number: 253665-029US, November 2008
>          * Table 6-1. Exceptions and Interrupts
>          */
>         if (regs->irq_id < 32) {
>                 /* Architecture defined exception */
>                 do_exception(regs);
>
> Any suggestion on this issue?

Are you using a recent-enough version of qemu? I think you need 2.3 or later.

Regards,
Simon


>
> Thanks a lot,
> Chi
>
>
>
>
>
> -----Original Message-----
> From: sjg at google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
> Sent: Friday, August 12, 2016 7:21 PM
> To: Ding, ChiX
> Cc: u-boot at lists.denx.de; Bin Meng
> Subject: Re: [U-Boot] building u-boot x86 with device tree disabled , still refers to device tree function
>
> +Bin
>
> Hi,
>
>
>
> On 11 August 2016 at 08:36, Ding, ChiX <chix.ding at intel.com> wrote:
>> Hi there
>> I'm building u-boot as payload for x86 platform. I didn't enable
>> device tree in menuconfig (CONFIG_OF_CONTROL is not set) because I use
>> a board config file coreboot.h. When I built u-boot, it reports error
>> during linking stage : undefined reference to dm_scan_fdt_dev
>>
>> arch/x86/lib/built-in.o:(.u_boot_list_2_uclass_2_lpc+0x8): undefined reference to `dm_scan_fdt_dev'
>> common/built-in.o:(.u_boot_list_2_uclass_2_usb_hub+0x8): undefined reference to `dm_scan_fdt_dev'
>> drivers/built-in.o:(.u_boot_list_2_uclass_2_pch+0x8): undefined reference to `dm_scan_fdt_dev'
>> drivers/pci/built-in.o:(.u_boot_list_2_uclass_2_pci+0x8): undefined reference to `dm_scan_fdt_dev'
>> drivers/spi/built-in.o:(.u_boot_list_2_uclass_2_spi+0x8): undefined reference to `dm_scan_fdt_dev'
>> drivers/usb/host/built-in.o:(.u_boot_list_2_uclass_2_usb+0x8): more
>> undefined references to `dm_scan_fdt_dev' follow
>> Makefile:1189: recipe for target 'u-boot' failed
>>
>> I looked at the code and see arch/x86/lib/lpc-uclass.c refers to a
>> function "dm_scan_fdt_dev " which is defined in drivers/core/root.c
>> and it looks like a device tree function
>>
>>
>> UCLASS_DRIVER(lpc) = {
>>         .id             = UCLASS_LPC,
>>         .name           = "lpc",
>>         .post_bind      = dm_scan_fdt_dev,
>> };
>>
>> Because device tree isn't enabled, the function isn't compiled and causes the problem while linking.
>> It's only compiled when the following is true #if
>> CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA) If I
>> comment out the line, it would compile and build. But I'm not sure if it's the right way to do it.
>>
>> Is it normal behavior? I thought that when not enabling device tree, the code shouldn't use device tree function?
>> Can anyone help on this please?
>
> Even when running as a coreboot payload you should use DT. As Bin says, this is described in README.x86 so you should be able to follow along there.
>
> If there is a specific reason for disabling the DT, can you explain it a bit?
>
> Regards,
> Simon
> --------------------------------------------------------------
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
>
> This e-mail and any attachments may contain confidential material for the sole
> use of the intended recipient(s). Any review or distribution by others is
> strictly prohibited. If you are not the intended recipient, please contact the
> sender and delete all copies.