* Add board BananaPi M4 Zero
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
* HACK: wrong DRAM size: add extra barrier in mctl_mem_matches
People report that this is fixed by adding another "dsb();" at
the beginning of the mctl_mem_matches() function.
https://lore.kernel.org/all/ZWMv816r8YxPwsJO@BOB1/T/#mec26415158efa10e6f78c5c1a651bb834f8599c4
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
* v2 add barrier and udelay to mctl_mem_matches function
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
---------
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
Co-authored-by: Patrick Yavitz <pyavitz@xxxxx.com>
* 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
