Jump to content

Recommended Posts

Posted
50 minutes ago, MX10.AC2N said:

Hi @jock

After 3h47 of operation, system freezed again.

Reboot and there is some update

Start-Date: 2022-06-27  08:08:26
Commandline: apt upgrade
Upgrade: udev:arm64 (249.11-0ubuntu3.1, 249.11-0ubuntu3.3), libnss-myhostname:arm64 (249.11-0ubuntu3.1, 249.11-0ubuntu3.3), libpam-systemd:arm64 (249.11-0ubuntu3.1, 249.11-0ubuntu3.3), libsystemd0:arm64 (249.11-0ubuntu3.1, 249.11-0ubuntu3.3), systemd:arm64 (249.11-0ubuntu3.1, 249.11-0ubuntu3.3), libudev1:arm64 (249.11-0ubuntu3.1, 249.11-0ubuntu3.3), systemd-sysv:arm64 (249.11-0ubuntu3.1, 249.11-0ubuntu3.3)
End-Date: 2022-06-27  08:09:43

Wait and see..

If the system freezes again, I'll try 1.1 GHz but the RK3328 is designed to run at 1.4 GHz and can accept 1.5 GHz normally.
Maybe I need to change something in dtb as I can add 1.4ghz and 1.5ghz overlays but in armbian-config I can't select those values only 1296Mhz has maximum value.

AFAIR rk3328 is advertised a 1.5ghz part, but actually is 1.3ghz, I can be wrong, though.

The suggestion to try 1.1Ghz is to understand if the problem is due to voltage regulators (the reason why it is very important for you to use led-conf3 overlay) or there is something wrong elsewhere.

BTW you are now back to v5.15 or still on v5.18? Are you using 333MHz idbloader or 667MHz one?

Posted
1 hour ago, MX10.AC2N said:

@jock

I still on v5.18.. freezed again

So I will switch at 1.2ghz for testing.. There is no 1.1ghz on selecting page of armbian-config

1208144689_Capturedcran(62).thumb.png.b3f9fae30bc00fbbff2d08f83d66b71c.png

564790604_Capturedcran(63).thumb.png.e1e34762e26e5c6a7ad9af3612f57f92.png

1.4ghz has a max value for RK3328 seeing here => http://opensource.rock-chips.com/images/9/95/Rockchip_RK3328_Datasheet_V1.3-20200310.pdf

I don't change idbloader..

No, 1.2GHz is not enough; you must go below that value otherwise it is a useless test.

Use 1.08GHz if you want a reliable test.

 

BTW, on the datasheet the maximum operating frequency is expressed as 1.3GHz (Table 3-2, page 37):

 

image.png.3a97cbf672700cae6392cd4f351b2d4f.png

Posted
3 hours ago, MX10.AC2N said:

@jock

Run well from 1h30 at 1.2ghz but ok I will switch at 1.0ghz..

Your alright for 1.3ghz, my mistake, sorry..

Ok so it looks to me that:

  • kernel v5.18
  • idbloader 667 Mhz
  • CPU at max 1.08/1.2GHz

seems to work stable enough, right?

Posted
1 hour ago, MX10.AC2N said:

@jock

Yes, for moment kernel v5.18 system run from 5h46 without freeze under 1.08ghz

Seems to be stable at 1.08ghz..

Mmmh so I guess I need to double check the led-conf3 overlay... maybe something subtle changed in kernel v5.18 and the overlay does not apply clean anymore.

Thanks for patience! Also if you have a serial adapter, it could be useful to report the u-boot logging that may tell you if something is wrong with the device tree...

Posted (edited)

Thanks to you bro @jock all this is only possible through your work.
I'm only testing.. But I haven't a serial adaptater, pity that u-boot does not save the log directly in a file it would be easier..

Maybe I'll invest in a serial adapter.. something like this will do https://www.amazon.fr/AZDelivery-Adaptateur-UART-TTL-conversion-dinterface/dp/B08T24NML9/ref=sr_1_38?keywords=adaptateur+usb+serie&qid=1656347527&sr=8-38

System run from 8h45 without freeze..

Edited by MX10.AC2N
Posted
18 hours ago, MX10.AC2N said:

Thanks to you bro @jock all this is only possible through your work.
I'm only testing.. But I haven't a serial adaptater, pity that u-boot does not save the log directly in a file it would be easier..

Maybe I'll invest in a serial adapter.. something like this will do https://www.amazon.fr/AZDelivery-Adaptateur-UART-TTL-conversion-dinterface/dp/B08T24NML9/ref=sr_1_38?keywords=adaptateur+usb+serie&qid=1656347527&sr=8-38

System run from 8h45 without freeze..

Yes, an adapter like that is fine; beware you need some basic soldering skills and your board must have accesible serial pads (usually marked with TX RX GND labels, in rows of 3 or 4 holes one after another) to get things done.

If you don't feel acquainted with electronics mind your choices, but surely a serial adapter like that is always handy when you need to do some debug on various devices (tv boxes and routers mainly, but also televisions, decoders, phones, ...)

Posted
1 hour ago, Buqan Kaleng Kaleng said:

does anyone using H96max rk 3318 ? want to know if there's an easy way  to make the led (digital clock) turn on

You can do this using the OpenVFD driver. If you read back on this topic, you’ll find a lot of posts on how to use it. There is no easier way.

Posted

I've a problem. I set the clock frequency to 1.3 Ghz and enabled both items in the emmc section. I had done this before and never had any problems but now, on reboot, I have this errors.

How I can fix it? Thank u.

 

IMG20220628160931__01.thumb.jpg.036f035639cfb9e22a414ab4f6498d51.jpg

Posted
48 minutes ago, pakos96 said:

How I can fix it? Thank u.

Not enabling the eMMC items that break your installation.

How to know which one breaks? Trial and error.

A photo of dmesg | grep mmc2 could also be nice to what is going on.

 

 

Posted
5 hours ago, jock said:

Not enabling the eMMC items that break your installation.

How to know which one breaks? Trial and error.

A photo of dmesg | grep mmc2 could also be nice to what is going on.

 

 

 

Thank u. As I said earlier, I had already enabled those two options in the past and hadn't had any problems. How I can revert the prevous settings?

So, grep was not found as command but I see "dmesg" and I've this. It can be helpful?

 

IMG20220628221647__01.thumb.jpg.8ebbaa1311b5d9375f18303b9cf14812.jpg

  

Posted

@pakos96 from the dmesg you posted there is a problem with the sdio wifi too (device mmc1), so there is something wrong with your configuration which is disrupting the mmc controller as a whole.

Can't say anything more, rk3318-config clearly says that those settings are for advanced users, may or may not work with your board and incorrect settings can prevent your system from booting. 🤷‍♂️

 

There are plenty of ways to access your current installation. A couple of them: boot another installation from USB or sdcard, or just use the multitool to do maintenance.

Posted (edited)
On 6/6/2022 at 5:04 AM, MX10.AC2N said:

Hi,

I have a problem of NO_PUBKEY with apt.

Réception de :9 http://armbian.systemonachip.net/apt jammy InRelease [26,8 kB]
Err :9 http://armbian.systemonachip.net/apt jammy InRelease
  Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 93D6889F9F0E78D5
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait
6 paquets peuvent être mis à jour. Exécutez « apt list --upgradable » pour les voir.
W: Une erreur s'est produite lors du contrôle de la signature. Le dépôt n'est pas mis à jour et les fichiers d'index précédents seront utilisés. Erreur de GPG : http://armbian.systemonachip.net/apt jammy InRelease : Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 93D6889F9F0E78D5
W: Impossible de récupérer http://apt.armbian.com/dists/jammy/InRelease Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 93D6889F9F0E78D5
W: Le téléchargement de quelques fichiers d'index a échoué, ils ont été ignorés, ou les anciens ont été utilisés à la place.

How can I solve this error ?

Thank

 

I had the same problem with NO_PUBKEY 93D6889F9F0E78D5 from APT UPDATE when I reinstalled Armbian 22.05.3 on my Banana Pi.

 

Use this command to get the PUBKEY from the Ubuntu Keyserver and write it correctly to /etc/apt/trusted.gpg.d:

 

wget http://keyserver.ubuntu.com/pks/lookup\?op\=get\&search\=0xdf00faf1c577104b50bf1d0093d6889f9f0e78d5 | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/armbian.gpg

 

Edited by dexrock
Posted
On 6/25/2022 at 5:37 PM, jock said:

@MX10.AC2N @Willy Moto Ok I managed to compile just the idbloader that does the DDR initialization to 333 MHz.

 

This is the binary with the 333MHz ddrbin: idbloader.img

 

And you can install from the box itself on the eMMC (should be suitable for @MX10.AC2N, mmcblk2 should be the eMMC, but please verify!) installation doing:

dd if=idbloader.img of=/dev/mmcblk2 bs=32k seek=1 && sync

 

Or you can boot into multitool (this should be the case for @Willy Moto) and do the same via shell. Of course you need to transfer the file on multitool FAT partition, boot with multitool and then  mount the FAT partition manually via shell.

 

 

 

Hi @jock

Sorry was not able to get back sooner.   I cannot find the mount device under  /dev/  path.  Which one points to the multiboot FAT partition? 

 

 

Posted (edited)
On 6/27/2022 at 3:31 PM, jock said:

AFAIR rk3328 is advertised a 1.5ghz part, but actually is 1.3ghz, I can be wrong, though.

The suggestion to try 1.1Ghz is to understand if the problem is due to voltage regulators (the reason why it is very important for you to use led-conf3 overlay) or there is something wrong elsewhere.

BTW you are now back to v5.15 or still on v5.18? Are you using 333MHz idbloader or 667MHz one?

 

Running the latest Armbian build with Kernel 5.18.6:

 

I have not applied the 333 Mhz idbloader.img yet (due to not sure which /dev/block to mount).

So instead, I ran rk3318-config and also tuned down the CPU speed to 1.1 Ghz.

 

This time, I was able to reboot without any issue .

 

I am running the sudo memtester 512M right now.   So far system is still stable 1.1 GHz CPU + RAM speed @ 667Mhz as you stated in this build.

 

========================

 

PS:  If I know how to mount the FAT partition, I can try the different combination of 1.3 Ghz CPU + RAM speed @ 333 Mhz  under Kernel 5.18.6 to compare the results.

       Believe I was under this combination when using Kernel 5.15.35.

 

Edited by Willy Moto
Posted

@Willy Moto If you're stable with 1.1Ghz and DDR@667MHz there is no sense in downgrading to 333MHz; the issue is not the DDR neither kernel; the problem is the CPU@1.3GHz.

I don't remember your board and the led-conf you were using, but for example @MX10.AC2N has exactly the same problem as yours. If you were using led-conf3 because your board has a regular rk3328 with the proper power regulation chip then there is some issue there: either the power regulator or the device tree overlay has some issues and needs to be fixed to let the CPU works stable at 1.3GHz.

Posted

Sorry to bring up this topic again, but today almost every h96 max box is produced with this new 2734c wireless chip. I've tried everything that is possible with software, but can't connect to the wifi network. I think it would be necessary to make a new overlay specifically for this. I'm not a hardware expert, could any of you make this? Maybe you don't need a box like this, since other images were already specialized for this chip in 2019, maybe you can take it out of it:

https://forum.freaktab.com/node/789155

 

 

Posted
7 hours ago, jock said:

@Willy Moto If you're stable with 1.1Ghz and DDR@667MHz there is no sense in downgrading to 333MHz; the issue is not the DDR neither kernel; the problem is the CPU@1.3GHz.

I don't remember your board and the led-conf you were using, but for example @MX10.AC2N has exactly the same problem as yours. If you were using led-conf3 because your board has a regular rk3328 with the proper power regulation chip then there is some issue there: either the power regulator or the device tree overlay has some issues and needs to be fixed to let the CPU works stable at 1.3GHz.

 

I am using unlisted as my led-conf in rk3318-config.  By the way, is there any command to confirm the actual DDR RAM speed ?

As there is no traditional BIOS  so  dmidecode  wouldn't work.

 

I think you're right, but if I have to guess I think CPU 1.3 Ghz and DDR@333Mhz would also be fine. 

I have 2 TV boxes:  one with RK3318, and one with RK3328.

 

Not sure if it makes any difference, but I'll post back further after some more testings.

Thanks for your work as always.

 

 

Posted
4 hours ago, Willy Moto said:

By the way, is there any command to confirm the actual DDR RAM speed ?

No, there is no such thing. The only way to know what kind of memory you have is read the signature on the chips and look for the datasheet.

But usually DDR3 shipped with these tvboxes are 667 or 800 MHz parts.

 

5 hours ago, Willy Moto said:

I think you're right, but if I have to guess I think CPU 1.3 Ghz and DDR@333Mhz would also be fine. 

You may try, but I have no reason to think that DDR frequency can in any way interfere with CPU frequency.

 

5 hours ago, Willy Moto said:

Not sure if it makes any difference, but I'll post back further after some more testings.

That would be interesting since you have two different boards; often those with rk3328 have a power regulation chip and rk3318 have none, but you have to look to the boards PCB.

Generally, choosing the right led-conf/GPIO pins configuration for the board is essential to get stability and functionality, but without A ) detailed photos of the board and B ) original dtb from Android it is impossible to produce suitable GPIO pin configuration.

Now this kernel v5.18 looks like is having issues of which I don't grasp yet the nature of...

Posted
On 6/30/2022 at 4:19 PM, jock said:

No, there is no such thing. The only way to know what kind of memory you have is read the signature on the chips and look for the datasheet.

But usually DDR3 shipped with these tvboxes are 667 or 800 MHz parts.

 

I understand.   I was googling for some time looking for memory benchmark tool to compare before & after this upgrade.

I'll see if that effort goes anywhere .  Will let you know.

 

 

On 6/30/2022 at 4:19 PM, jock said:

 

That would be interesting since you have two different boards; often those with rk3328 have a power regulation chip and rk3318 have none, but you have to look to the boards PCB.

Generally, choosing the right led-conf/GPIO pins configuration for the board is essential to get stability and functionality, but without A ) detailed photos of the board and B ) original dtb from Android it is impossible to produce suitable GPIO pin configuration.

Now this kernel v5.18 looks like is having issues of which I don't grasp yet the nature of...


Thanks for the hint.  I made sure to dump a backup of the original Android ROM image with multitool.

 

Now to the task of dtb extraction

I'll see if I can get this done in a few days (currently still busy with a few other non-IT matters 😅).

 

 

Posted

It is important for me to solve my wifi connection problem, so I dedicated this whole day to extract the dtb from the original Android device. So the chip I'm having a problem with is the 2734C. It seems to work well with the 6334 overlay, but it can never connect to the wifi network. Looking into the content of the dtb, I was surprised to read that in the device tree it reads: wifi_chip_type = "rtl8822bs".
This is where all my knowledge ends, my request is that you make me a wlan overlay based on the attached dts that I can use for this chip. Thanks.
 

rk3318_h96_max_android.dts

Posted
14 hours ago, paradigman said:

It is important for me to solve my wifi connection problem, so I dedicated this whole day to extract the dtb from the original Android device. So the chip I'm having a problem with is the 2734C. It seems to work well with the 6334 overlay, but it can never connect to the wifi network. Looking into the content of the dtb, I was surprised to read that in the device tree it reads: wifi_chip_type = "rtl8822bs".
This is where all my knowledge ends, my request is that you make me a wlan overlay based on the attached dts that I can use for this chip. Thanks.
 

rk3318_h96_max_android.dts 83.94 kB · 0 downloads

 

 

There is such 2734C chip, a google search would have confirmed that to you easily.

The chipset under the hood is an ampak AP6334 which is in turn made of a couple of broadcom chips. The wireless part is a bcm4334.

 

Probably your issue is not the dtb but the wifi chip firmware or, more in particular, the nvram /lib/firmware/brcm/brcmfmac4334-sdio.rockchip,rk3318-box.txt which is not suitable for your board setup. The wifi depends on how the board is build for important things like reference frequency, antenna setup, sideband gpio, etc... If the nvram does not specify these params correctly, it will not perform well or will not work at all.

 

The best thing you could do is mount the vendor partition of your Android firmware and search for a suitable firmware for your board or extract from the live Android system.

Tthat could be easy but could also require various steps  to get access to the partition, it depends and how the firmware is built.

 

Otherwise you could look around in google, download new nvrams for bcm4334/ap6334 and try and see if they work for you.

 

edit: BTW the wifi chip is fully supported by linux kernel and works wonderfully well on my board; when I say don't buy tv boxes if you want supported hardware I mean exactly this.

 

Posted (edited)

I have killed my machine h96max+ with the latest update, looking for help to recover...

 

- Looked for updated kernel, found it in usual place: https://users.armbian.com/jock/rk3318/upgrade/

- Noticed that stuff is marked as edge and that there is a directory `v5.15` with non edge stuff

- Downloaded stuff from the `v5.15` directory that is stuff marked as current rather than edge as it seemed more conservative

- Noticed the `bsp` file was not in the `v5.15` dir, got the one from the dir above as there is no *current* or *edge* mark on it (was this my mistake?)

- Installed everything including the `linux-u-boot-current

- used armbian-config to update the u-boot on the system

 

System not booting anymore... What is the advice to try a recover?

 

[UPDATE]

 

I have probably succeeded in recovering the machine. However, what has happened is unclear to me. The kernel was oopsing and only by stopping the systemd boot I was able to get a prompt. From the latter trying to do anything was continuously resulting in applications segfaulting...

 

Before I try again, @jockcan you please help clarify:

 

- if the problem was in using a bsp file mismatched wrt the kernel I was using?

- if I am expected to use the -edge or the -current kernel from 22.08?

Edited by callegar
UPDARE
Posted (edited)

Another update.

 

I have gone through the last two pages of the thread, and I think that what I was experiencing is quite similar to what other users @MX10.AC2N and @Willy Moto were experiencing: boot issues, gcc segfaulting.  The notable difference is that I was experiencing them with a 5.15 kernel (the one from the 5.15 dir), not the 5.18 one, while I was using the `bsp` file from the upgrade directory.

 

Now I have used multitool to downgrade everything to the 22.05 version and everything is back to normal, but I understand it is important to me to see if and how I can move forward in view of the mainstreaming of 3328 tv boxes.

 

So I have started making some tests and the issue is definitely not `armbian-bsp-cli-rk3318-box_22.08.0-trunk_arm64.deb`. Installing that alone onto the bootable system keeps it bootable.

 

Before I make more tests, I wonder about `idbloader.img`: if I install that, how do I revert that install?

 

Edited by callegar

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines