All Activity

Tencent box Aurora 5 Pro was probably a better experience than H96MAX could give you H96MAX V58 = more expensive than an open source SBC H96MAX V58 = not reliable EMMC or RAM chips

Since last week the official image for Tanix TX1 has been available but the installation procedure is complex as I had already anticipated. I remember that the Miniarch project is not linked to the armbian project and with this post I would like to close this thread so as not to go off topic. It is possible to open issues on github of our friend Piotr who develops the project alone.

Since last week the official image for x96q 1.3 (and also for pcb 5.1) has been available. Unfortunately, the hardware of the x96q TV box suffers from the classic problems of Chinese TV boxes, that is, there are many fakes around, i.e. PCBs with other hardware (even a different processor) and continuous revisions of the board based on what the manufacturer finds cheapest. I remember that the Miniarch project is not linked to the armbian project and with this post I would like to close this thread so as not to go off topic. It is possible to open issues on github of our friend Piotr who develops the project alone.

But I already did it although with led7, that supposedly should be the right one for this board?

Hi How to disable HDMI audio and audiocodec 0 [audiocodec ]: audiocodec - audiocodec audiocodec 1 [SoundCard ]: USB-Audio - USB PnP Sound Device C-Media Electronics Inc. USB PnP Sound Device at usb-5200400.usb-1, full speed 2 [HDMI ]: HDMI - HDMI HDMI I don't need this because I use external sound card on USB and I would like prefer USB Sound card on index number 0 I try use /etc/modprobe.d/alsa.conf with options snd_usb_audio index=0 but don't work

The community images from June 7 have analog and HDMI sound. The analog sound needs to be unmuted which can be done with alsamixer.

BCM433x are normally good supported , do have rk322x-config and setup the right led config its help also with wifi enable signal

I'm not sure where to report this. I think this is a common problem across distros for arm. I had this same problem with manjaro arm a month ago. On a fresh install of armbian. 24.3 cli. Emacs 28.x is available. It is missing a lot of elpa packages because of out of date gpg keys. It cannot find elpa.gnu packages. It is, for me, completely unable to load and use my emacs configuration. Package-initialize and package-refresh-contents do not fix it. I built the current emacs from source, it's version 29.3 and that works much better.

hello No new you get response ?

@fabiobassa@jock

@Blyato take photos with good resolution with and without shield please

Hello, I wanted to install Linux on my TV box but I'm having problems First I tried to put an Android rom that said it was stock But it doesn't boot and the system doesn't start, it was in loader mode and after I did that it went into maskrom mode and it doesn't come out, everything I try to do gives me the download boot fail I don't know what to do to get out of this mode and install something, all the loader files don't work and the ones that say they work, the links are down

@jock at least I don't think it's a phone wifi module, you know a way I could check software wise? Or only way would be trying to remove the shield of the module to expose the chip? Would mean the world to me if I could make the wifi work, I have a USB wifi adapter but the problem is that I cant use antenna with it (would have to buy another one that does :/)

Yeah, don't know what Tencent is thinking, I don't like the experience at all, I reason I bought it simply because it's the most affordable and available hardware around at that point of time. I never notice this one coming --"RK3576", I'll keep my eye on this, thanks for sharing this, very interesting.

@Blyato that's very difficult wifi is getting working if it is yet another unkown chinese vendor chip. From the photo i can't identify it, but have never seen such silhouette

Sure. As a beginner, I just won't update it. Or trying to understand the MiniArch desktop-installing thing on another card, it had no problem with upgrade somehow, still works, but on command line only.

Hello ! I thought to have found a work around by doing a first access to by pass "the unexpected timing", but time to time it does not work ! See code of the work around tested: void spi_transfer(enum Chip chip, unsigned char* txBuffer, size_t len, bool with_rx) { int ret; int fd; uint8_t bits; uint32_t speed; uint8_t mode; unsigned short delay; char * tx = NULL; char * rx = NULL; char hex_dump_tx_prefix[9] = {0}; char hex_dump_rx_prefix[9] = {0}; switch(chip){ case RADIO: fd = st_spi.fd_radio; speed = st_spi.speed_radio; mode = st_spi.mode_radio; bits = st_spi.bits_radio; delay = st_spi.delay_radio; strcpy(hex_dump_tx_prefix,"tx_radio"); strcpy(hex_dump_rx_prefix,"rx_radio"); break; case RTC: fd = st_spi.fd_rtc; speed = st_spi.speed_rtc; mode = st_spi.mode_rtc; bits = st_spi.bits_rtc; delay = st_spi.delay_rtc; strcpy(hex_dump_tx_prefix,"tx___rtc"); strcpy(hex_dump_rx_prefix,"rx___rtc"); break; case FLASH: fd = st_spi.fd_flash; speed = st_spi.speed_flash; mode = st_spi.mode_flash; bits = st_spi.bits_flash; delay = st_spi.delay_flash; strcpy(hex_dump_tx_prefix,"tx_flash"); strcpy(hex_dump_rx_prefix,"rx_flash"); break; default: printf("Unexpected chip value !\n"); exit_with_trace(EXIT_STATUS_SPI_ERROR, ulTraceModule, __FUNCTION__, __FILE__, __LINE__); break; } tx = malloc(len); check_malloc(tx, ulTraceModule, __FILE__, __LINE__); rx = malloc(len); check_malloc(rx, ulTraceModule, __FILE__, __LINE__); memcpy (tx, txBuffer, len); unsigned char payload_wa_radio[2] = {0x20, 0x00}; struct spi_ioc_transfer tr_wa_radio = { .tx_buf = (unsigned long)payload_wa_radio, .rx_buf = (unsigned long)0, .len = 2, .delay_usecs = delay, .speed_hz = speed, .bits_per_word = bits, }; struct spi_ioc_transfer tr = { .tx_buf = (unsigned long)tx, .rx_buf = (unsigned long)rx, .len = len, .delay_usecs = delay, .speed_hz = speed, .bits_per_word = bits, }; if (mode & SPI_TX_QUAD) { tr.tx_nbits = 4; } else if (mode & SPI_TX_DUAL) { tr.tx_nbits = 2; } if (mode & SPI_RX_QUAD) { tr.rx_nbits = 4; } else if (mode & SPI_RX_DUAL) { tr.rx_nbits = 2; } if (!(mode & SPI_LOOP)) { if (mode & (SPI_TX_QUAD | SPI_TX_DUAL)) { tr.rx_buf = 0; } else if (mode & (SPI_RX_QUAD | SPI_RX_DUAL)) { tr.tx_buf = 0; } } #if DBG_SPI hex_dump(tx, len, 32, hex_dump_tx_prefix); #endif //toolMutexLock(&MutexSPI); if (chip == RADIO) { // This part of code is a workaround for the radio because the radio spi is touchy to the clock timing of // the first spi access as the mode is set during the first access. // The workaround consists in doing a first access without impact on the radio configuration to bypass the // issue, and then a second access to really execute the spi command. // For the first access, we send command "0x00, 0x20" which is interpreted by the radio "0x00, 0x10" due to the // the clock timing. So we only do a read access at the address 0 of the config register without impact on the radio configuration. // Let's see task #30190 for more details. ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr_wa_radio); if (ret < 1) { printf("can't send spi message\n"); exit_with_trace(EXIT_STATUS_SPI_ERROR, ulTraceModule, __FUNCTION__, __FILE__, __LINE__); } } ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr); if (ret < 1) { printf("can't send spi message\n"); exit_with_trace(EXIT_STATUS_SPI_ERROR, ulTraceModule, __FUNCTION__, __FILE__, __LINE__); } //toolMutexUnlock(&MutexSPI); if (with_rx == true) memcpy (txBuffer, rx, len); #if DBG_SPI hex_dump(rx, len, 32, hex_dump_rx_prefix); #endif free(rx); free(tx); } See capture bellow doing a read access in loop on the radio spi. Time to time, there is also an expected CLK timing on the second access. Conclusion: Doing a first access to bypass the unexpected timing is not enough. I have to add something else or find another solution ...

If there's a kernel or u-boot update then your box won't boot. The kernel and u-boot need patches from my repository for it to work on your box. There are no apt packages for this. I guess you need to burn another sdcard and start from scratch.

If you want to upgrade the userspace flavor on top (like Jammy to Noble for example) it is indeed recommended to start from scratch. If you want to upgrade the Armbian core components like firmware, kernel and boot-loader, these upgrades are shipped as regular apt package.

Hi, Thanks, I've tried both working image on my h618 Transpeed tv-box. I have some newbie questions: - On the miniarch image: I managed to upgrade + setup the wifi, and it works, but I cannot install any desktop environment. I've done every steps and tried a lot different desktop environment, but no luck, it won't start, remains in the text console. Is it possible to install a (simple, like xfce4) desktop environment? How? - On the Armbian image: everithing works fine (I used an usb hub+usb wifi+bt, internal not working), and there is a working desktop environment, which is great! But I've tried to upgrade (apt update + apt upgrade) and the upgrade maybe messed up the boot somehow, the device won't boot since the upgrade. Is it possible to upgrade the Armbian image? How? Thanks, Sidha

I answer myself: the overlays are here: https://github.com/radxa/overlays/tree/main You need to take the desired overlay, compile it using dtc and put it in the /boot/dtb/rockchip/overlay folder. Next, turn on the overlay in armbian-config and voila root@proc01:/home/victor# ls /dev/ | grep spi spidev1.0

So, if I want to upgrade the Armbian version, I have to do an installation from scratch and migrate everything, right? Thanks

Description Support partner. How Has This Been Tested? [x] Was reported as working good. Checklist: [x] Any dependent changes have been merged and published in downstream modules View the full article

For Armbian updates regular code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } apt update && apt upgrade will be sufficient. If you however want to change your userspace (like Jammy to Noble) this is out of scope of Armbian and upstream tools (like do-release-upgrade in case of Ubuntu) have to be used. Armbian firmware and userspace are two pair of shoes. Armbian cannot handle userspace upgrades by itself simply due to lacking of both human and financial resources for development and testing lots of various scenarios. This is also the reason why doing this is not recommended and therefore entirely unsupported by us.

Good morning I don't quite understand everything. I understand that do-release-upgrade is not the right way to upgrade Armbian. So what is the right way? Thanks