[U-Boot] [PATCH v3 0/8] riscv: Enable efi_loader support

Rick Chen rickchen36 at gmail.com
Thu May 10 07:00:37 UTC 2018


2018-05-10 14:03 GMT+08:00 Alexander Graf <agraf at suse.de>:
>
>
> Am 10.05.2018 um 05:27 schrieb Rick Chen <rickchen36 at gmail.com>:
>
>>>>
>>>> Then I think if I don't want enter this auto flow, what can I do ?
>>>>
>>>> 1 Remove CONFIG_DISTRO_DEFAULTS=y from nx25-ae250_defconfig  But it
>>>> still enter auto flow.
>>>>
>>>> 2 Add #ifdef CONFIG_DISTRO_DEFAULTS to encapsulate the
>>>> CONFIG_EXTRA_ENV_SETTINGS in nx25-ae250.h  And Remove
>>>> CONFIG_DISTRO_DEFAULTS=y from nx25-ae250_defconfig  And it will NOT
>>>> enter auto flow
>>>>
>>>> #ifdef CONFIG_DISTRO_DEFAULTS
>>>> /* Enable distro boot */
>>>> #define BOOT_TARGET_DEVICES(func) \
>>>>        func(MMC, mmc, 0) \
>>>>        func(DHCP, dhcp, na)
>>>>
>>>> #include <config_distro_bootcmd.h>
>>>>
>>>> #define CONFIG_EXTRA_ENV_SETTINGS       \
>>>>                                "kernel_addr_r=0x00080000\0" \
>>>>                                "pxefile_addr_r=0x01f00000\0" \
>>>>                                "scriptaddr=0x01f00000\0" \
>>>>                                "fdt_addr_r=0x02000000\0" \
>>>>                                "ramdisk_addr_r=0x02800000\0" \
>>>>                                BOOTENV #endif
>>>>
>>>> 3 Add #ifdef CONFIG_DISTRO_DEFAULTS to encapsulate the
>>>> CONFIG_EXTRA_ENV_SETTINGS in nx25-ae250.h  And do NOT Remove
>>>> CONFIG_DISTRO_DEFAULTS=y from nx25-ae250_defconfig  But disable
>>> CONFIG_DISTRO_DEFAULTS from make menuconfig
>>>>   General setup  --->
>>>>     [ ] Select defaults suitable for booting general purpose Linux
>>>> distributions  And it still enter auto flow
>>>>
>>>> Offering this information for you.
>>>
>>> This is the same for all distro enabled boards. The basic idea is that U-Boot ships
>>> with something that "just boots" for simple use cases.
>>>
>>> If you want something more advanced, you usually want to put something very
>>> target specific in there anyway, such as "bootm $nor_flash". In that case, you
>>> adapt the CONFIG_BOOTCOMMAND parameter to whatever you want.
>>>
>>> The boot command can also be overridden using the environment. So if you have
>>> working environment store, you can change the U-Boot variable "bootcmd" and
>>> U-Boot will run that instead when it boots.
>>>
>>> The alternative to this default behavior would be no bootcmd at all which means
>>> you just get dropped into the U-Boot prompt. While that's reasonably useful for
>>> developers, it isn't for people deploying U-Boot on real target systems :).
>>>
>>>
>>> Alex
>>
>> Thanks for your advises.
>>
>> After you send those patchs into main trunk.
>> I will fetch and push them to u-boot-riscv.git :)
>
> The usual flow would be the other way around: You apply them to u-boot-riscv.git with your Signed-off-by and send a pull request for the current merge window :).
>
> Unless I misunderstood your earlier reply and you would prefer to have me propagate them to mainline via the efi-next tree?
>
>
> Alex
>

Yes. I prefer that you propagate them to mainline via the efi-next tree.
Then you can grasp the schedule by yourself.

When you ask "Via which tree do you want to push it? "
I misunderstood it and reply preferring to u-boot-nds32.git.
Sorry about that ~ ~

But maybe I need to send patch-sets to change cpu and board nane.
For example: rename nx25-ae250.h to ax25-ae350.h

Will it affect your submitting flow ?
I am wondering how to deal with the conflicts between the different patch-sets

Rick


More information about the U-Boot mailing list