jock

  • Posts

    967
  • Joined

  • Last visited

Recent Profile Visitors

3810 profile views
  1. @marshall sorry for taking so long in answering. At the moment I'm a bit busy and a bit tired too. Your issue seems to require more attention than expected, still could not figure out what is wrong. From the log you posted I see something very odd: I don't see the eMMC card (mmc2), the sdio wifi chip (mmc1) is not detected at all and the sdcard (mmc0) has problems getting into high speed mode. This is the hardest combo ever!
  2. Decompress the image before writing to sdcard? Or use a proper burning software that does it for you?
  3. Ah, you're right. It depends upon the kernel in the image you burnt actually. If you took a recent (one week) image probably have the "edge" kernel (5.14), so the right command line is this: sudo apt-mark hold linux-image-edge-rockchip64 linux-dtb-edge-rockchip64 linux-u-boot-edge-rk3318-box Anyway, it is not so important to hold the upgrade of the u-boot package. The offenders are the other twos.
  4. Indeed it is possible, but I have only a single S905 box without the original firmware nor a deep knowledge of the boot process of amlogic socs. It would be limited to S905 and probably cover just the simple boot cases.
  5. This is probably the mistake. rk3318 images are "experimental" and absolutely not yet into armbian official repository. When you do upgrades and a kernel upgrade happens, the system breaks. That's my mistake not including the lines to block apt from upgrading kernel. You can however reinstall and then mark packages to hold with the following command: sudo apt-mark hold linux-image-current-rockchip64 linux-dtb-current-rockchip64 linux-u-boot-current-rk3318-box Then doing upgrades should be right fine.
  6. Glad to hear everything is back to normal. About the Amazon DRM etc... I don't know anything about. I see that libreelec is downloading chrome and extracting the widewine DRM binary to let some plugins work, but I did not ever try Amazon Prime and don't know what are the requirements for that. The proprietary ATF may provide a "secure" application of some sort for DRM, but this is a guess. I never digged into what in reality there is. I may guess that "secure" ATF software is tailored with some other userland software which I'm not aware of that may lie in the Android image, but this is all purely guessing
  7. @marshall It would be more helpful if you could post dmesg | grep mmc, but still I can't realize where the issue could be...
  8. Ahhh ok, we got the right explanation. Now the message is properly gone from dmesg. The problem is this: the box always boots from eMMC because there is a valid bootloader there. The bootloader is in reality composed of many parts executed one after another. The station-m1 bootloader contains a thing that is called ATF (Arm Trusted Firmware). This piece of software is like a protected sandbox, something that runs outside the kernel or, if you prefer, above the kernel. It can whatever do it wants, can even stop the linux kernel. In fact it controls some very low level things, like system reset, core initialization, standby/resume, and so on... It also controls the RAM frequency scaling, so memory can switch from 300 Mhz up to 800 Mhz and more. Now there are two "flavours": the proprietary rockchip ATF (compiled by rockchip with their own customizations) and the public one provided by ARM. The proprietary ATF is fully-fledged, but actually we don't really know what is inside: it's a blob provided by rockchip. The public opensource ATF has just basic features, but we know it is harmless. When I say harmless I want to stress out the fact that the ATF can peek his nose everywhere in the system, in fact it is widely used to implement DRM (Digital Rights Management) and HDCP (HDMI Copy Protection) features in tv boxes, to prevent piracy and restrict user rights in some form. A proof of some harmful behaviour (not yet fully understood) is the fact that if I run rk3318 boards with proprietary ATF, the system crashes when cpu frequency is > 1.1Ghz. 1.1Ghz is the advertised speed for the rk3318 chip. When I run the opensource ATF, rk3318 boards runs happy at 1.3 Ghz or even above. Now this behaviour is a bit suspect: I don't want to state that the rockchip ATF is crashing the system on purpose to limit the frequency speed of the chip, but if we consider the final effect, it is so. All this long explanation is to say that maybe the bootloader installed in the eMMC may cause headaches of some sort. I don't know if there are limiting behaviours on rk3328 too, but as we are used to say in Italy, the wolf loses the hair but does not lose the vice (ie: what they do once, they can do again) It would be wise to clean the eMMC bootloader. If you're not afraid to lose the eMMC installation, you could erase the eMMC with blkdiscard. If you don't want to lose it, you may make a backup of the first megabyte of the eMMC on the sdcard, zero-fill the first megabyte of the eMMC, and finally reboot. Otherwise leave it as-is and just and see what happens with led-conf3 overlay again.
  9. @MX10.AC2N What is a sec... there is something that definitely should not be there. In your dmesg log I see: [ 2.326648] rk3328-dmc ff780000.dmc: current ATF version 0x101 Instead the expected message from a freshly installed system (debian bullseye) is this: [ 2.307538] rk3328-dmc ff780000.dmc: trusted firmware need to update or is invalid On you system the DRAM memory controller (DMC) driver is definitely active, while it should not be! This is incredibly unexpected! Now I tried both the latest images on my box and the DMC does not activate because there is the need for a bootloader piece of code I didn't yet plugged into, so I wonder what the hell is going on! Do you ever installed the older image with legacy kernel in eMMC or is there original Android in eMMC? This is absolutely strange, it looks like the bootloader is not what it is expected to be! By the way to fix this issue, which is potentially causing you a system freeze or kernel fault, substitute /boot/dtb/rockchip/rk3318-box.dtb with the one attached here. rk3318-box.dtb
  10. Very strange... May I ask you if you're using the sdcard or the system is installed on emmc? Also if you can edit armbianEnv.txt and set verbosity=10 maybe the kernel provides some more hints. At the moment I'm running out of ideas: a full dmesg from serial would give some hints on what is going on I need some time to think about the issue...
  11. This is the led-conf3 overlay compiled manually again: rockchip-rk3318-box-led-conf3.dtbo
  12. @MX10.AC2N Gosh, this cannot be true... it should be the same led-conf3 I published before for testing, just recompiled by armbian this time. Don't even understand why it is freezing since cpu-hs overlay is not set and cpu is limited to 1.0 ghz
  13. Well that's not something that surprises me. A lot of u-boot code is just crap,with half-baked drivers, inconsistent nomenclature, bugs everywhere, and much more. It is one of the worst things to work with. BTW, I always booted from sdcard because my board has a NAND chip, so I could not ever try anything
  14. Enables the HS200 mode for the internal eMMC. Normally this is safe, because the kernel asks the eMMC is it is able to work in that mode. I have another board (rk322x) which has a HS200 eMMC and it is able to reach a sequential read speed of 130MB/s! Sometimes the eMMC or the board is not able to keep up, and activating the switch crashes everything. The same applies with emmc-ddr overlay, just that the mode here is DDR, which is yet capable of reaching considerable speeds (> 90MB/s). Note that it is just the bus speed, the eMMC should be of good quality, which is not always the case on tv boxes. edit: about the esp8089 issues, the driver is not yet included into mainline kernels like 5.14