* 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)
After we bumped u-boot to version v2022.10, a couple of boards
stopped booting because the CONFIG_SPL_STACK value used in our
u-boot config was too low for that SOC. This change drops explicit
CONFIG_SPL_STACK defination from the affected boards.
The boards confirmed to have the issues were Orange Pi 3 LTS and
NanoPi Neo Black2 but I suspect that NanoPi K1 plus is also affected
hence similar change is done for that as well
- using Kwiboo's `rk3568-2023.10` branch with BINMAN-handled blobs
- patches (defconfig unless indicated):
- boot usb first (rockchip-common)
- blink leds & keep red one one on preboot; reset SPI env once after deinfesting from Petitboot
- change usb_host0_xhci to otg (u-boot dtsi)
- enable DM_GADGET, UMS 🔥 and RockUSB
- **usage instructions**:
- build & burn image to SD card
- insert SD card into board
- **hold the recovery (RCY) button** and power on the board
- watch board boot
- **de-infest Petitboot**: use `armbian-install` to install bootloader to MTD
- if you don't, you'll need to hold the recovery button every boot
- optionally: use `armbian-install` to install OS to eMMC/NVMe/USB
- power-off board
- remove SD card (new u-boot always boots SD first!)
- boot into your newly de-infested machine
- boot order: USB, SD, MMC, NVME, SCSI
- de-infested machine can now boot (directly) from USB/SATA/NVMe, possibly via EFI:
- Armbian UEFI-arm64
- Fedora 38 aarch64
- HASSOS for ODROID-M1
- Talos arm64
- others...
- extra: new u-boot by Kwiboo (with GMAC patches) gives us stable MAC address
- although it is based on cpuid#, doesn't match the HK sticker on the board
- run `fw_setenv ethaddr XX:XX:XX:XX:XX:XX` to change eth addr in SPI flash environment if needed
- `odroidm1`: update DDR/BL31 blobs (this depends on https://github.com/armbian/rkbin/pull/20)
Backport DTS/DTSI changes from linux-6.4.y to 6.1.y
Add meson64-reboot driver to all boards
Add board: ODROID N2L
Add uart_A uart_AO_B uart_B uart_C where appropriate
U-Boot v2023.07.02: ODROID N2/N2L/N2Plus/C4
Meson64-reboot driver: (source: tobetter)
While the current meson64-reboot driver is cleaner and doesn't
depend on modding other kernel sources, its functionality leaves
much to be desired. One example can be found in the ODROID C4.
Using the current driver, the board will not properly power off,
leaving the POWER LED still on. The new driver powers off the unit
completely.
Fan control: (ODROID N2L/N2PLus)
Added service and script for controlling the trip point.
fanctrl: arguments: 65 55 45 35 25 menu run
┌──┤ Fan Control ├──┐
│ │
│ 6) 65°C │
│ 5) 55°C │
│ 4) 45°C │
│ 3) 35°C │
│ 2) 25°C │
│ E) Exit .. │
│ │
│ │
│ <Ok> │
│ │
└───────────────────┘
NOTES: (N2L/HC4): I do not own the units so I can't run tests.
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
