gk7205v300: bootargs change requires reboot

[tinylabs]

Currently on gk7205v300 and other hisilicon targets (hi3516ev300), the first boot rewrites the u-boot bootargs variable to account for the selected contiguous memory allocator and totalmem vs osmem. This makes sense to move the logic into the kernel rather than force creating multiple versions of u-boot for chipsets in the same SoC family due to different amounts of available memory.

However, the initial boot cannot use the full amount of memory since it's not available to the kernel via cmdline, which causes issues such as majestic not fully starting on (gk7205v300 / ultimate) which leaves the web interface unavailable.

One fix would be to schedule a reboot after rewriting bootargs in set_allocator. That would be a one-time trigger after install. Unsure if rebooting right away would be the correct fix or deferring until boot has finished (if other one-time operations are required).

Thoughts?

[widgetii]

1. Kernel can determine the amount of physical memory available on the board by RAM testing algorithm (U-Boot already does it and passes the total memory amount through a bunch of variables, which is clunky from my perspective).
2. I would add sane mem allocator default settings to the kernel itself rather than passing them via U-Boot and let the end-user still override them if they will.

From this perspective, U-Boot can pass nothing to the kernel, and it should run using the sane default configuration for the chip.

[tinylabs]

Current u-boot for gk7205v300 seems to hard-code the memory size.

#define PHYS_SDRAM_1                0x40000000
#define PHYS_SDRAM_1_SIZE           0x08000000

I guess the core problem is u-boot doesn't (and shouldn't care) which mem allocator is selected although that also affects the total memory as seen by the kernel.

gk allocator => Only pass lower kernel memory. Kernel doesn't know about upper memory but goke specific driver does.
cma allocator => Kernel see entire memory and goke allocator works in conjunction with kernel to allocate the memory needed for media pipeline.

I think a safe patch based on the current behavior would be to reboot the target with a log message specifying the reason on the first boot. It would only be necessary if cma allocator was selected. That would maintain dynamic memory allocator selection.

Ultimately it would be nice to move to a unified u-boot binary (per family) with CONFIG_OF_CONTROL=y and specify the hardware config in a DTB passed to u-boot itself but that would be a large refactor and may not be easy with current reg_info_xxx.bin blobs.