Mochabin NXP 9089

Ah Jeroslav beat me to it. That's the guide I used as well. Luci didn't install on the image they provided and when I tried some other snapshot build I got an issue where Luci just hung. If that's still an issue let me know and I'll see if I can share an image I did have Luci working on. Just checking as well, this got my Qualcomm WiFi card working, do you have that one or the NXP card in yours?

It is the Qualcomm WiFi card:
01:00.0 Unassigned class [ff00]: Qualcomm QCA6390 Wireless Network Adapter

I think all OpenWRT Mochabins have the Qualcomm adapter.

@jeroslav Thanks for sharing the files! Let me try them out. I will keep you updated.

This worked like a charm! I did not install the OpenWRT snapshot privded with the image but stopped after updating the recovery ramdisk (step 9) and continued using the ath11k enabled snapshot which I had already flashed and configured:

[    9.390540] ath11k_pci 0000:01:00.0: BAR 0: assigned [mem 0xc0000000-0xc0ffffff 64bit]
[    9.399106] ath11k_pci 0000:01:00.0: MSI vectors: 32
[    9.404120] ath11k_pci 0000:01:00.0: qca6390 hw2.0
[    9.408932] ath11k_pci 0000:01:00.0: FW memory mode: 0
[    9.571036] mhi mhi0: Requested to power ON
[    9.575511] mhi mhi0: Power on setup success
[   10.295940] mhi mhi0: Wait for device to enter SBL or Mission mode
[   10.394623] kmodloader: done loading kernel modules from /etc/modules.d/*
[   10.412064] ath11k_pci 0000:01:00.0: chip_id 0x0 chip_family 0xb board_id 0xff soc_id 0xffffffff
[   10.420910] ath11k_pci 0000:01:00.0: fw_version 0x10121492 fw_build_timestamp 2021-11-04 11:23 fw_build_id

The WiFi card is recognized now and works as expected. Thank you so much for your help!

Awesome, good to hear you got it working. I've ended up opting to stick with a stable build which doesn't allow me to use the built in WiFi card because I have a dumb ap configured anyways. Once there stable build is updated to a version that supports that WiFi card I'll revisit. I'm currently having a headache increasing the overlay size on my Mochabin. I've put a sata ssd in the device but have really struggled getting the overlay to switch to that device. Probably me being a bit of a biff, but I've also discovered that the image I've used only uses about 1GB of the built in eMMc, which is 16GB in total. I'm thinking of I can get the overlay to use 10GB I'll never fill that. Will try to work out out myself but likely end up opening another post to see if anyone knows how to do it. Ideally I'm hoping I'll be able to sort it with a script in image builder so that I can repeat it each time I do an upgrade.

Sorry, I digressed massively. Out of interest how stable are you finding the WiFi?

Brothers in thought! I have also installed a SATA SSD to have the overlay sourced from there. It did not work likely because of: https://github.com/openwrt/openwrt/issues/7352 however it seems this is being fixed currently.

For Mochabin WiFi it does not look like you can configure the ath11k card for both 2,4 GHz and 5 GHz. I have opted for 5 GHz and signal quality is not quite as good as from my old (dedicated) router. Perhaps I am holding it wrong :grinning:
Anyway I have increased Tx power which fixes this issue somewhat. Also ath11k crashes about once a week (not a real crash - the WiFi just seems to be down). Not a big issue as the WiFi only needs to be restarted. However compared to my old setup with no issues at all, i.e. rock-stable for months a step back.

Hi ChriZ

To save you some time on the extending overlay issue I managed to get that sorted over the weekend thanks mainly to another poster (when I say sorted I have a 10GB overlay that uses empty space on the built in eMMc). I'll hopefully get some time to double check the steps taken and then post that this evening or tomorrow. Off the top of my head is roughly 6 or 7 lines to copy into SSH and it's fairly straightforward (even I could do it). Will keep you posted.

Hi Chriz

I'm not going to have time to do a full write up of this tonight, but if you're anything like me you'll want to get your overlay sorted, so here's the untidy version of the full write up I'll do on this once I have time and have tested fully. Apologies if I put in stuff you already know, but just including roughly what I'll put together as a full guide. I'm wondering if the steps I'll detail below work out whether I'll be able to get this added to the device info page for the mochabin. For info, and I'll properly credit the genius of the people who people who's posts I used at a later date, the posts that I used were:

resizing the overlay when it is ext4 and not f2fs - interestingly the first time I managed to increase my overall, the instructions in here worked a bit better. However, when I did a new sysupgrade using the current stable image (which is squashfs) the steps that required you to be working on an ext4 filesystem didn't work, and after some head scratching I found the reason was that the partition my loop0 file was on was f2fs.

gl-mv1000 increasing_the_root_filesystem - from this I just took a couple of lines that allowed me to easily increase the partition size where loop0 resides. (only point 2 actually, and I used the resize option instead of creating and formatting a new partition)

So here goes:

  1. Do a df -h to check on the current partitions/system file sizes:
root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.5M      3.5M         0 100% /rom
tmpfs                     3.9G      1.1M      3.9G   0% /tmp
/dev/loop0               98.8M     61.5M     37.3M  62% /overlay
overlayfs:/overlay       98.8M     61.5M     37.3M  62% /
tmpfs                   512.0K         0    512.0K   0% /dev

Then install the packages you'll need by copying an pasting the following lines of code

opkg update
opkg install losetup e2fsprogs resize2fs block-mount kmod-fs-f2fs f2fs-tools cfdisk kmod-fs-ext4 parted rsync

You might not need all of these, it depends if you're running on ext4 or f2fs, but they all seem fairly small anyway.

Then confirm where the loop0 file resides using the following command. My results shown as well:

root@OpenWrt:~# losetup
NAME       SIZELIMIT  OFFSET AUTOCLEAR RO BACK-FILE  DIO LOG-SEC
/dev/loop0         0 3604480         1  0 /mmcblk0p2   0     512

I'm guessing you'll also have your loop0 on mmcblk0p2. If it's different though take note you'll need to change that in the next step.

root@OpenWrt:~# cfdisk /dev/mmcblk0

You can then use the down arrow key to select the second partition and left arrow key to go to “Resize” >> press return. Then use left arrow key to move cursor to new size entry, and change to the size you want, as below. Then press return, select “write” and yes to confirm. Then quit.

I chose not to use the full free space available, but that’s because I’m clueless and I don’t know if some free space is needed for the tmpfs to use, which was showing at 3.9GB. So I just chose to make mmcblk0p2 10GB in total because I can’t see myself ever needing that much anyway. If anyone who actually knows what they’re doing wants to correct me about whether I could use the whole of the free space please do.

I then just copied spence’s instructions as follows:

LOOP="$(losetup -n -O NAME | sort | sed -n -e "1p")"
ROOT="$(losetup -n -O BACK-FILE ${LOOP} | sed -e "s|^|/dev|")"
OFFS="$(losetup -n -O OFFSET ${LOOP})"

I then wanted to check it had done something so ran the following command with results shown (again something I picked up off Spence)

root@OpenWrt:~# echo ${OFFS} ${LOOP} ${ROOT}
3604480 /dev/loop0 /dev/mmcblk0p2

The next 2 lines then went fine as well:

LOOP="$(losetup -f)"
losetup -o ${OFFS} ${LOOP} ${ROOT}

But this is where things got a bit weird. From Spence's instructions, the next steps worked fine when I first ran them. It must be because somehow I had formatted my mmcblk0p2 partition as ext4 (no idea how I'd done that, or if it was because of using a different build image initially. But anyways, this initially worked.

fsck.ext4 -f ${LOOP}

If that command works for you, it may ask you to create a lost and found, just click yes or select whatever default options there are. Then you can run the next lines. If however you get an error, then skip to the lines a bit further down which work for the f2fs filesystem.
Final lines of code if running on ext4:

mount ${LOOP} /mnt
root@R4S-wrt:~# umount ${LOOP}
root@R4S-wrt:~# resize2fs ${LOOP}

If it tells you to "Please run 'e2fsck -f /dev/loop0' first.", then do that, and repeat the resize2fs ${LOOP} command.

Once that's done you might be tempted to do a df -h again and find to your dismay that the size of loop0 hasn't changed. Just do a:

reboot

And try your df -h again.

Different lines of code if you got an error after fsck.ext4 -f ${LOOP}. In my case, it was because I was on f2fs instead. So the lines of code to do are:

fsck.f2fs -f ${LOOP}  #and go for default options if given any
mount ${LOOP} /mnt
umount ${LOOP}
resize.f2fs ${LOOP}
reboot

C:\Users\happy>ssh root@192.168.1.1
root@192.168.21.1's password:


BusyBox v1.35.0 (2023-01-03 00:24:21 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 22.03.3, r20028-43d71ad93e
 -----------------------------------------------------
root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.5M      3.5M         0 100% /rom
tmpfs                     3.9G    276.0K      3.9G   0% /tmp
/dev/loop0               10.0G    495.2M      9.5G   5% /overlay
overlayfs:/overlay       10.0G    495.2M      9.5G   5% /
tmpfs                   512.0K         0    512.0K   0% /dev
root@OpenWrt:~#

One of the things I'm still scratching my head about it that doing this process seems to take up about 490M on the loop0 now, whereas before the resize only 61M was used? No idea why.

Hope that helps, and let me know if you have any suggestions for making my instructions clearer.

Ta

Happy

Thanks for the mention. :slight_smile:
90%+ of the info I shared came from other as linked to in my post.

I can also offer some potential help determining space usage of your overlay.

Oh, by the way, /tmp/ is normally using RAM and not any storage like an eMMC or an sd- card.
Look at the command mount to see some info.
In the output, You may see a line like:

...
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
...
tmpfs on /dev type tmpfs (rw,nosuid,noexec,noatime,size=512k,mode=755)`
...

If so, I suspect your device uses RAM for `/tmp/.

This leads to info for your overlay filesystem. There is a line in the mount output for it, Something like:
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
Notice that the writable area (called upperdir) is mounted on /overlay/upper.

Note that the higher used space might simply be filesystem overhead like a much larger directory structure and space reserved for file inodes and block usage etc.

Try using some more advanced options of du (disk usage), and ls to see more info.

Try du --help and ls --help to see a list of options available. Search the Internet or refer the the man pages on a linux system for more details.

Try du -chs /overlay/upper/ and compare output with that of adding 'x':
du -chsx /overlay/upper/
If without 'x' is close to the 490M but with 'x' is much smaller then df -h might be reporting info for a mounted or linked filesystem.

To see more details of space usage, look into sub-directories by adding a wildcard '*' and trailing '/' to indicate to show directories and not files. The 's' option controls some of this too:
du -chsx /overlay/upper/*/
Keep drilling down any path that is using a lot of space.
Command examples: ('s' option omitted)
du -chx /overlay/upper/usr/*
du -chx /overlay/upper/usr/bin/*

You could also show the full listing of files and look for what is using space.
To get an idea of how many files are on the writable area of /overlay/upper/, try using the line count utility:
ls -lARSh /overlay/upper/| wc -l
To see the list, sorted by size in each directory just take off the | wc -l:
ls -lARSh /overlay/upper/
...and scroll... lol.

find is another tool that can do this type of searching as well.

I hope this helps.