Jump to content

Jens J.

Members
  • Posts

    21
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. afaik, if your box had /dev/mmcblk1, assuming that's the internal storage (and not the sd card), then I believe it means your unit has emmc, not just raw nand. this has a nice explanation of emmc vs nand - TLDR: emmc has mmc controller on top of raw nand storage, making it easier to present the storage to the OS/kernel. With only raw nand, the kernel has to have the drivers in-tree to understand how to talk to the nand chip and handle all of the concerns to present it as a block device. https://www.toradex.com/blog/what-you-should-know-about-flash-storage regardless, glad you got it sorted out
  2. wifi can be a tricky thing you need to identify what wifi chip it's using you could open up the box and look at the wifi module on the board, or you could grab a boot log from serial console output from original android installation, or you could try to run `lsusb` to see if there are any obvious usb-based wifi adapter VID/PIDs there (e.g. realtek, etc) If it's not usb internally-connected wifi module, then likely the module may be connected to internal SDIO bus, which I think will require custom dts to modify and produce a dtb which tells the kernel where to find the wifi adapter. (This usually involves dumping/grabbing the original dtb on the box, which is usually flashed to a particular amlogic partition, and then inspecting it, and hand translating it to modern devicetree - as steeman mentioned, all the android-based images use an ancient 3.x custom, vendor provided kernel, with very vendor specific devicetree features. Modern kernels use a different set of devicetree syntaxes. Then you have to make sure you have the right wifi driver installed/available. Then you have to make sure you have the right firmware installed/available (as most of these wifi modules require soft-loading firmware at boot). root@onecloud:~# lsusb Bus 001 Device 003: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  3. Does that image contain an s805_autoscript and/or aml_autoscript file at the root of the sdcard? Here's a copy of mine for an MXQ model (note that in my uEnv.txt, it uses a custom m201 dtb) If that doesnt work, then you'll need to get access to serial console to see what the stock uboot is doing, and what sdcard (mmc) files it's looking for on boot. armbian_s805_boot_files.zip
  4. how exactly did you format the emmc? (what commands?) did you follow the install guide, and use `install-aml.sh` (which preserves the boot block on emmc, keeping the old uboot to chainload into new uboot with) ?
  5. correct, unfortunately, some tvbox manufacturers have opted to use cheaper nand flash, rather than emmc-compatible flash, which is supported. Using nand flash directly requires additional support in the bootloader and kernel, which do not currently exist. (There has been _some_ work in the kernel on this, but it's nowhere near finished.) TLDR, you only be able to install to internal flash if it's eMMC.
  6. How did you "install"? via armbian-config install (not for armbian tv boxes) or /root/install-aml.sh (specially made for board type "aml-s9xx-box") ? Did you try booting off of the armbian sd card again (holding the reset button for 7 seconds while powering up)? First thing to do when you think you might have "bricked" a board is to get serial console access on it so you can see what's actually going on, e.g. using a usb uart adapter connected to the serial port header (the four unpopulated pins, specifically: TX, RX, GND). With amlogic and the way armbian installs, the stock amlogic uboot is likely still there, and something else can be loaded from it (via usb, sd, etc).
  7. ok thanks @SteeMan I see armbian-firmware is around 16MB vs 300+MB of armbian-firmware-full. Luckily, I don't think the firmware has changed on the QCA9377 much since 2020's commit. I do see your point though. Is there some way to have the armbian-firmware build process dynamically pull the latest from upstream kernel for the selected drivers/sections, without doing the whole "kitchen sink" approach of armbian-firmware-full, which is a bit excessive for some devices with limited storage? Regarding learning, I'm using what you started with config/boards/aml-s9xx-box.tvb and adapting this to a new board type (mini-m8s-pro.tvb), along with adding dts at patch/kernel/meson64-edge/dt/meson-gxm-mini-m8s-pro.dts If there is further documentation on this process of adding new board support, especially around the amlogic flavors, to better guide me, I'd be happy to check that out
  8. ok the QCA9377/LTM8830 firmwares added to armbian-firmware https://github.com/armbian/firmware/pull/63 With this newer firmware package, the wifi should work. Bluetooth will need the change in the DTS. I'm working on a PR for armbian/build repo to add DTS for this variant, which I think is called "mini-m8s-pro" Basically a Beelink GT1 ultimate dts with LTM8830 (QCA9377) wifi/bluetooth, which will look like this: https://gist.github.com/zerog2k/a702a41fe91f52b07c2e53e4f359f580#file-meson-gxm-mini-m8s-pro-dts-L85-L86
  9. I think Meson8b is S805 (armhf, not arm64) try BOARD_TYPE=onecloud
  10. on the sdcard, did you copy /boot/u-boot-s905x-s912 to /boot/u-boot.ext, before running install-aml.sh? I think install-aml.sh will cause u-boot.ext to be copied to emmc /boot/u-boot.emmc - is that file there on emmc boot partition?
  11. @SteeMan yes I would love to do exactly that I figured out how to add new dts - cumbersome, but through "kernel patch" process. I'm still trying to wrap my head around a few other armbian things: As I understand it, armbian has it's own firmware package, which is probably some subset of normal linux-firmware packages. Is there some accepted way to extend this (to add the qca9377 firmwares?) such that the build process includes it - or is there some sort of install script I can invoke during build. (I was considering making this a special board type, basically Beelink GT1 w/ this QCA9377-compatible bt/wifi). Was trying to find out all the steps to add a new board support, but it's not really well documented from what I can tell. Is there any high-level outline of the steps?
  12. for a future self, my notes on making an image work fully with the wifi/bt: SD customization: to make uboot work: sd card bin, u-boot-p212.bin -> u-boot.ext # DTB: edit /boot/extlinux/extlinux.conf, uncomment line: FDT /dtb/amlogic/meson-gxm-gt1-ultimate.dtb (comment out all other FDT lines) apt update && apt install net-tools git vim ## wifi firmware mkdir -p /lib/firmware/ath10k/QCA9377/hw1.0/ download files from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0 copy them to /lib/firmware/ath10k/QCA9377/hw1.0/ # replace special firmware (which seems more stable) ln -sf /lib/firmware/ath10k/QCA9377/hw1.0/firmware-sdio-5.bin /lib/firmware/ath10k/QCA9377/hw1.0/firmware-5.bin # fix bt? fdtput -t s /boot/dtb/amlogic/meson-gxm-gt1-ultimate.dtb /soc/bus@c1100000/serial@84c0/bluetooth compatible "qcom,qca9377-bt" fdtget /boot/dtb/amlogic/meson-gxm-gt1-ultimate.dtb /soc/bus@c1100000/serial@84c0/bluetooth compatible # bt firmware mkdir /lib/firmware/qca download fw files to this dir: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/qca/rampatch_00230302.bin https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/qca/nvm_00230302.bin # figure out a way to cycle the bt uart power at startup on qca9377 # simply getting the state of the gpio pin seems to cause it to correct itself gpioget gpiochip1 96 # (maybe consider moving from shutdown-gpios to reset-gpios in device-tree?) ## fix cpu throttling https://forum.armbian.com/topic/18429-managing-cpufreq-on-biglittle/ # consider porting the remote-control map into device tree
  13. if you aren't sure you have the right DTB for the box, then it's just guessing as to why it's KP'ing you'll likely need to hookup usb ttl adapter and see what's happening on the serial console you may also want to put "ignore_loglevel" into your kernel command line options in extlinux.conf to get more output of what's going on
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines