Hi Simon,
On Wed, May 27, 2015 at 11:42 PM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 26 May 2015 at 22:06, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Wed, May 27, 2015 at 11:59 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 26 May 2015 at 21:55, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Wed, May 27, 2015 at 11:13 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 25 May 2015 at 08:36, Bin Meng bmeng.cn@gmail.com wrote:
Although the two qemu-x86 targets (i440fx and q35) share a lot in common, they still have something that cannot easily handled in one place (like different configurations, different properties in the device tree). Split to create two dedicated board configuration and device tree files and make the i440fx be the default build target.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/dts/Makefile | 3 +- arch/x86/dts/qemu-x86_i440fx.dts | 34 +++++++++++++++ arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} | 2 +- board/coreboot/coreboot/Kconfig | 4 +- board/emulation/qemu-x86/Kconfig | 19 +++++++-- configs/qemu-x86_defconfig | 1 - doc/README.x86 | 13 +++++- include/configs/{qemu-x86.h => qemu-x86_i440fx.h} | 20 ++------- include/configs/qemu-x86_q35.h | 52 +++++++++++++++++++++++ 9 files changed, 122 insertions(+), 26 deletions(-) create mode 100644 arch/x86/dts/qemu-x86_i440fx.dts rename arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} (95%) rename include/configs/{qemu-x86.h => qemu-x86_i440fx.h} (78%) create mode 100644 include/configs/qemu-x86_q35.h
Do we need a separate config file? It would be good if all the changes were in the device tree so that we don't need a separate config. Or at least that the configs are the same except for the device tree.
So far the only difference between two separate config files are the ATA/SATA settings. i440fx has legacy IDE support while q35 has the AHCI support. We can enable them both in just one config files, however turning on legacy IDE support on q35 causes significant boot delay as the legacy IDE driver has some big timeout in probing the attached devices. Do you think this is something we are tolerant of? If yes, I can just do separate device trees.
I think it is OK. But another option would be to add an IDE node to the device tree and check it when CONFIG_OF_CONTROL is defined...
I feel that we need convert all block drivers to driver model, so that the driver can probe and initialize IDE/AHCI based on device tree node. But I guess that's a long term goal?
Yes, perhaps latter in the year. I did create a simple MMC uclass that uses the block driver library just as now, and it seems easy enough. I suppose you could do the same with IDE. But in the meantime just some sort of DT config is good enough to avoid your device.
I am not sure I understand your point. Do you mean for now I need modify common/cmd_ide.c::ide_init() to probe the existence of an IDE node in the device tree? I am afraid that's a lot of work too since there are many boards use the IDE driver.
Regards, Bin