* meson-s4t7: bump u-boot to khadas-vims-u-boot-2019.01-v1.6-release
* Use khadas default bootargs as much as possible
* Add new hook to allow copying code into kernel
* meson-s4t7: legacy: Switch to 5.15 kernel
* meson-s4t7: add kernel-config for 5.15 kernel
* device tree overlays for 5.15 kernel for vim1s and vim4
* restructure packaging of bsp files for vim1s/vim4
* silence vblank warning on boot
* Remove display workaround as it doesn't work with 5.15 kernel
* Remove 5.4 kernel patches
In my initial commit I assumed CONFIG_USE_PREBOOT=y was enabled
by default. I was wrong.
As reported by MicroLinux (Salva) on DISCORD the unit was still
having issues booting. I sent him a patch I use which enables
preboot and he reported back that "It boots fine now".
NOTES: The patch he tested also had boot logo support enabled. In
my testing boot logo support is not required. If for some reason
in the future there are still eMMC boot issues, than maybe adding
a slight delay "sleep 2" to preboot would suffice.
https://github.com/armbian/build/pull/5858
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
* rockchip64: Add board "ASUS Tinker-Edge-R"
* rockchip64: Add board "ASUS Tinker-Edge-R": hammer for 6.6 current & 6.7 edge
- cleanup
- squash dtsi and dt into a single thing, rename to dashes
- change dtb reference in board file
- drop the 6.1 patch that has junk in it
---------
Co-authored-by: Ricardo Pardini <ricardo@pardini.net>
This does not change the current boot order and requires specific
hardware.
Test-on: BananaPi BPI-CM4IO Baseboard with BPI-CM4 Module
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
Co-authored-by: Patrick Yavitz <pyavitz@xxxxx.com>
* CONFIG_SYS_SCSI_MAX_DEVICE was replaced by a macro in U-Boot v2022.04
* Fixes u-boot for rockchip64 derivatives
* Fix missing include for cli_simple_run_command
* Do not return value in a void function
Update Das U-Boot to v2023.07.02
Patch: HACK: mmc: meson-gx: limit to 24MHz
db6738fed9
In my testing the patch is required for stable boot on REV 1.51.
It is not required on REV 1.4, but has no ill effects on boot.
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
Co-authored-by: Patrick Yavitz <pyavitz@xxxxx.com>
HACK: BOOT ORDER: NVMe SDCARD eMMC.
NOTES:
In my testing there has been no false starts or hangs up. Meaning
the boot process has been stable.
The downside to this in my opinion is that if there is an OS on
the NVMe it will always take boot priority. The drive would need
to be pulled or DD'd in order for SD eMMC boot to kick in.
Tested-on: Waveshare CM4-IO-BASE-B
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
Co-authored-by: Patrick Yavitz <pyavitz@xxxxx.com>
In sunxi-6.1 and sunxi-6.5 kernel we have a patch that changes r_rsb to r_i2c. But same
change is not done for u-boot. Mixing use of r_rsb and r_i2c seems to cause issues if
its also something handled in crust. Hence making it consistent across u-boot and kernel
dts files
> Based on AmazingFate's kernel DT and Kwiboo's `rk3568-2023.10`
Tested with a OrangePi 3B 4GB v1.1:
- SD-card boot
- eMMC boot
- SPI Flash boot
- chip is XMC `XM25QU128CWIQ`, not `W25Q256JWEIQ` listed in schematics
- PCIe/NVMe
- Ethernet has stable MAC
- can boot both edge (mainline) and legacy (vendor rk 5.10) kernels
- USB in uboot is untested
- UMS untested (I lost my A-to-A otg cable)
