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

[Rick Chen]

2018-05-10 15:00 GMT+08:00 Rick Chen <rickchen36 at gmail.com>:
> 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

I just modify what I want base on your patch-sets and that will be fine.
I think too complicated. :)

Rick