Jump to content

c0rnelius

Members
  • Posts

    187
  • Joined

Other groups

Contributor/Maintainer

1 Follower

Profile Information

  • Gender
    Male
  • Location
    US

Contact Methods

  • IRC
    #arm-img-builder
  • Github
    https://github.com/pyavitz
  • Discord
    https://discord.gg/mypJ7NW8BG

Recent Profile Visitors

5294 profile views
  1. If it should get it accepted; https://github.com/armbian/build/pull/7900
  2. Yes. So instead of this patch; https://github.com/armbian/build/blob/main/patch/kernel/archive/meson64-6.12/board-odroidc4-reset.patch which only patches the C4 DTS, create a new patch, that patches against the "meson-sm1-odroid.dtsi". Problem solved. An example can be found in my personal repo; https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/6.12/007-ODROID-general-patch-set.patch#L281
  3. The solution here would be doing a PR and instead of adding the node to the DTS, it should be added to the DTSI "meson-sm1-odroid.dtsi" which both units "C4/HC4" would pick up. + reboot: meson64-reboot { + compatible = "meson64,reboot"; + sys_reset = <0x84000009>; + sys_poweroff = <0x84000008>; + + sd-vqen = <&gpio_ao GPIOE_2 GPIO_ACTIVE_HIGH>; + sd-vqsw = <&gpio_ao GPIOAO_6 GPIO_ACTIVE_HIGH>; + sd-vmmc = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>; + }; +
  4. Yes. The builds are identical, which is why the rpi5b conf was removed.
  5. https://github.com/armbian/build/pull/7845/files
  6. `sudo modprobe i2c-dev` ?
  7. @hvedemelsbof What the patch is doing is changing the boot targets. Normally SD/MMC would take priority and USB, NVMe and SCSI would be the fall back. With SPI onboard, you could still achieve USB boot by enabling PREBOOT in the u-boot defconfig, along with `usb start`. So in that case the patch wouldn't be required. Same goes for NVMe and SATA boot. In my testing, this also works if you treat the SD or MMC as just a boot mech. Flashing u-boot to it and installing the OS directly to the USB, NVMe or SATA drive. In my opinion those patches should no longer be used, as cleaner methods are available. But that's not my call. I've never messed with this boot_target variable. Looks to me, if you set that var in the boot.cmd/scr, you can change the hard coded targets. Whether or not it will work on AML units, I have no clue.
  8. My guess is, the bulk of the GUI issues stems from the version of Mesa being used. Try the one in their repo; https://gitee.com/bianbu-linux/mesa3d/tree/bl-v2.0.y/
  9. sudo groupadd gpio sudo adduser wollik gpio
  10. I rarely use an SBC with a head. I suspect packages need to be created to bring in proper GUI support.
  11. They were custom built. I suspect the issue is: https://github.com/armbian/build/blob/main/patch/u-boot/v2022.10/meson64-boot-usb-nvme-scsi-first.patch
  12. @dnwhoop02 sudo dd if=u-boot.bin of=/dev/mmcblk1 bs=512 seek=1
  13. Find the /dev/node `lsblk` Flashing options: eMMC: sudo dd if=u-boot.bin of=/dev/mmcblkX bs=512 seek=1 SDCARD: sudo dd if=u-boot.bin.sd.bin of=/dev/mmcblkX conv=fsync bs=1 count=442 sudo dd if=u-boot.bin.sd.bin of=/dev/mmcblkX conv=fsync bs=512 skip=1 seek=1 u-boot.bin u-boot.bin.sd.bin
  14. https://github.com/armbian/build/pull/7694 patrick@rpi4b:~$ dmesg | grep brcmfmac [ 3.443168] brcmfmac: F1 signature read @0x18000000=0x15264345 [ 3.444363] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 3.444650] usbcore: registered new interface driver brcmfmac [ 3.673499] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2) [ 3.673793] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2 [ 8.815477] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines