2018-05-10 15:00 GMT+08:00 Rick Chen rickchen36@gmail.com:
2018-05-10 14:03 GMT+08:00 Alexander Graf agraf@suse.de:
Am 10.05.2018 um 05:27 schrieb Rick Chen rickchen36@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