fabiobassa

Hi @jock  I managed to run the image on my respeaker coreV2 board  added the rk3229-respeaker-v2-armbian-rev2.dtb to /boot/dtb  and  changed the fdtfile=rk3229-respeaker-v2-armbian-rev2.dtb in /boot - great work

And perhaps try with different SD cards. I first used some expensive recommended 64GB SanDisk card and nothing worked then I tried a "no-name" cheap 8GB card and it worked perfectly. I think it's up to luck when it comes to the SD cards. The recommended expensive cards might work more often than the cheap ones, but sometimes it's the other way around. 

@chinhhut
Will try to explain you what loader is with an analogy: in normal pc you have bios and master boot record. Well, maskrom is bios and is contained in the soc itself, loader is a sort of master boot record and it enables the emmc and ddr.
You can have a look here
http://opensource.rock-chips.com/wiki_Boot_option

 

I did extract it by a working firmware using a tool that unpacked the whole firmware. Try to google for RK3xxx_firmware_tools_5.23.1_by_SergioPoverony.zip and leave alone that github since it is just one piece of the puzzle. The detailed infos how to get a working loader are in the rockchip instructions

 

Of course and the command would be rkdeveloptoo rl 0x0 etc etc etc ( try rkdeveloptool -h to get the help)
But if you are lucky that works multitool, well that is the easiest way to clone and clone back

@chinhhut
Will try to explain you what loader is with an analogy: in normal pc you have bios and master boot record. Well, maskrom is bios and is contained in the soc itself, loader is a sort of master boot record and it enables the emmc and ddr.
You can have a look here
http://opensource.rock-chips.com/wiki_Boot_option

 

I did extract it by a working firmware using a tool that unpacked the whole firmware. Try to google for RK3xxx_firmware_tools_5.23.1_by_SergioPoverony.zip and leave alone that github since it is just one piece of the puzzle. The detailed infos how to get a working loader are in the rockchip instructions

 

Of course and the command would be rkdeveloptoo rl 0x0 etc etc etc ( try rkdeveloptool -h to get the help)
But if you are lucky that works multitool, well that is the easiest way to clone and clone back

Yes, I'm looking into.
I read your previous messages and as far as I remember you have two three problems:
- HDMI is not working
- eMCP flash is not working
- only one led is working
 
The first two are unexpected problems. If I remember correctly @marshall also had an eMCP board. He had a problem with SDIO, but eMCP flash is working fine.
You instead have a problem with eMCP flash, which is pretty unusual, strange and worse.
 
Could you please try this libreelec image and tell me if you see anything on HDMI? Armbian uses the same libreelec HDMI timing patches, thus we could discover if the problem may be related to those patches. You can just burn the image and sdcard, plug it in and ti should boot. If possible, please post dmesg output you get over serial too (don't remember if baud rate is 1.5Mbps or 115Kbps)
 
About the development process on testing armbian images, there are some things that I want to make clear:
we need to do several tests, it may be a slow process and results are not guaranteed you should already be able to put Android back on the board with rockchip tools in case you want to go back accept the very remote risk to brick the board The plan is to first erase completely the internal eMCP flash, either using rkdeveloptool for linux of the rkdevtool for windows. For the former tool, instructions are in the paragraph Erase the flash memory in the first page of the thread.
Once flash is erased, the board always boots from sdcard. sdcard is far easier to use for testing.
 
First of all, try both the legacy 4.4 and current 5.10 kernels and see if results are the same. dmesg log is always appreciated, even better is to paste the link produced by armbianmonitor -u
Images can be downloaded from armbian download page, just use a suitable burner tool like balena.etcher or whatever you prefer to burn the image on the sdcard.
 
This are two overlays to use for your board. They should provide at least working leds, hopefully the eMCP flash should work too.
This overlay rk322x-led-conf7.dtbo is for legacy 4.4 kernel.
This other overlay rk322x-led-conf7.dtbo is for mainline 5.10 kernel.
 
Use one or the other In dependency of which kernel are you testing.
The overlay must be put in /boot/dtb/overlay directory of armbian installation and must be activated adding a line overlays=led-conf7 in /boot/armbianEnv.txt file.
You should be able to do that with no hassle directly on the sdcard.
 
I hope this fixes led and eMCP flash problems. It is improbable that anything changes with HDMI. For that problem I need to know if the libreelec image is working right for you or it isn't.

@chinhhut

Try these steps:
1) push the little switch inside the hole while inserting a male-male cable into the otg
2) on another linux machine you should have now a new device (lsusb will help you) and you can run rkdeveloptool
3) rkdeveloptool ld should List Device
4) rkdeveloptool rd 3 should Reset Device into mode 3  ( maskrom )
5) rkdeveloptool db MiniLoaderAll.bin ( of course from your path) should upload a temporary loader to recognize the internal emmc
6) if all is successfull until now you can rkdeveloptool wl 0X0 yourimage.img . This should flash the internal emmc .

DISCLAIMER: very " dangerous" approach , be ready to have the opportunity to short the emmc clock pin to ground to go back into mask rom
 
MiniLoaderAll.zip

@chinhhut
Glad you got success .
Don't forget to put a like that helps @jock and myself in community reputation
 
 
 

@chinhhut
Glad you got success .
Don't forget to put a like that helps @jock and myself in community reputation
 
 
 

@chinhhut - this might be some interesting reading too regarding boxes, which cannot boot from sd card: https://github.com/hexdump0815/u-boot-misc/issues/2
 
best wishes - hexdump

@fabiobassa @jock I've followed your guide and got success. Thank you so much.
root@mybox:~/rkdeveloptool# ls 99-rk-rockusb.rules Makefile.in RKComm.h RKImage.h RKScan.h cfg configure.ac main.cpp CMakeLists.txt Property.hpp RKComm.o RKImage.o RKScan.o config.h.in crc.cpp main.o DefineHeader.h RKBoot.cpp RKDevice.cpp RKLog.cpp Readme.txt config.ini crc.o parameter_gpt.txt Endian.h RKBoot.h RKDevice.h RKLog.h aclocal.m4 config.log gpt.h rkdeveloptool Makefile RKBoot.o RKDevice.o RKLog.o autom4te.cache config.status license.txt Makefile.am RKComm.cpp RKImage.cpp RKScan.cpp boot_merger.h configure log root@mybox:~/rkdeveloptool# ./rkdeveloptool ld DevNo=1 Vid=0x2207,Pid=0x320c,LocationID=101 Loader root@mybox:~/rkdeveloptool# ./rkdeveloptool rd 3 Reset Device OK. root@mybox:~/rkdeveloptool# ./rkdeveloptool db MiniLoaderAll.bin Opening loader failed, exiting download boot! root@mybox:~/rkdeveloptool# ./rkdeveloptool db /root/MiniLoaderAll.bin Downloading bootloader succeeded. root@mybox:~/rkdeveloptool# ./rkdeveloptool wl 0X0 /root/Armbian_21.11.0-trunk_Rk3318-box_bullseye_edge_5.14.14_minimal.img Write LBA from file (100%) root@mybox:~/rkdeveloptool# ./rkdeveloptool ---------------------Tool Usage --------------------- Help: -h or --help Version: -v or --version ListDevice: ld DownloadBoot: db <Loader> UpgradeLoader: ul <Loader> ReadLBA: rl <BeginSec> <SectorLen> <File> WriteLBA: wl <BeginSec> <File> WriteLBA: wlx <PartitionName> <File> WriteGPT: gpt <gpt partition table> WriteParameter: prm <parameter> PrintPartition: ppt EraseFlash: ef TestDevice: td ResetDevice: rd [subcode] ReadFlashID: rid ReadFlashInfo: rfi ReadChipInfo: rci ReadCapability: rcb PackBootLoader: pack UnpackBootLoader: unpack <boot loader> TagSPL: tagspl <tag> <U-Boot SPL> ------------------------------------------------------- root@mybox:~/rkdeveloptool# ./rkdeveloptool ld DevNo=1 Vid=0x2207,Pid=0x320c,LocationID=101 Maskrom  

@fabiobassa, @jock: you are right guys, I apologize to you.
I realize I’m really frustrated by the helplessness. I just want to work, but I can’t, I feel like I’m exposed to the playful entertainment of others.

@paradigman

 

And here you are wrong another time, yet..... Again and again. You dint trampled nothing of professional since here nothing of professional, just fun spending time in cheap tvboxes not suited for professional use.

I have 40 years in professional cellular phones official repairing of most known brands , one of the biggest of my country !!! .. but when I present myself try to be polite and modest, looking for empathy and collaboration, not being rude as you have been and JUDGE. Judge from the high step of 20 years professional. Ridicolous !
I don' t  put my FLAG of being into professional for 40 years ( so you can even, if you are able, to think whom and what age you speaking with or maybe you were convinced to speak to some young nerd, maybe a big mistake) .
You have the erroneus idea that 20 years in professional give you  " rights" and again I answer: put apart your narcissistic aspect. Never said BEFORE my " status " and then my person.
I repeat : you are noone ( remember) to judge.
This is the reason I don't let you speak in thay way.. people that put before their " staus" instead of putting WHO they are deserve worst even answer than what i gave and still giving to you,
It is human respect, not professionl pride. Is politness .

Now can't work more because my eyes not so good and things getting smaller and smaller so better play with easy things, human readable. Boxes are for me still at my hardware capabilities

 
What the hell you're speaking ? Have at least read that long post i gave you? THis is an exaustive explanation of all I have. follow it, you have all the actual status of the art, and that post is the OFFICIAL rockchip way.
.. me.. we .. don't hide nothing. All we have is written. What is NOT written is because we don't have the hardware to study. That's all. No reverse engeneering but trials and errors. Or do you believe we wouldn't be happy to have hardware acceleration or other fantastic thing from those boards and we are satisfied of the work made until now?? Hell, no!


 

And again.. this is YOUR problem.If you're frustated  ou are late on you project don't discarge your frustration on here, go out having a fun and clear ideas.
Buy real well supported hardware and you' ll be in time and you boss happy. And if you don't have money to buy more expensive hardware... well guess: IS YOUR PROBLEM, try crowfounding

always outspoke and please, already taken too much time in nonsense speaking, let's go back into hardware and software aspects. Speaking of pride, judgments, hidden, etc etc.. Blah !
Thank you so much

@paradigman
I agree with @fabiobassa: there is an attitude problem here, and your frustration is clear.
I'm not happy about your work being late, but that's not my fault, nor a fault of the Armbian project.
If you were in the nearby I would you offer a beer and try to find a solution about your problem, but I guess you're not in the neighborhood.

The only thing I can suggest you right now, is to find an officially supported board from Armbian here and pursue your business project forgetting tv boxes.

I have the plus. However, I was never able to boot Armbian from the SD card, I used Multitool from this thread. Added the Armbian ISO to it, multitool booted fine from the SD card, then took a backup of the stock ROM with multitool and then erased eMMC and installed Jock's Armbian via multitool. 
 

@chinhhut Probably Perhaps your h96 max is unable to boot from sdcard because the sdcard is allocated to the "alternative" controller. Much more important than the box name is the board name/signature though.
From what I have seen on the forums, this breaks any kind of sdcard boot or update. I guess it is just not supposed that the tvbox manufacturers use this alternative controller for sdcard, so there is the need to find an alternative solution to boot, which I'm not yet aware of.
USB boot is available only if u-boot from armbian image is installed in the eMMC. The stock u-boot does not care about USB devices.
 
This is the most serious issue that is preventing me to ask to merge rk3318/rk3328 tvbox support in main Armbian source code.

Have fun experimenting. I myself is "hooked" on playing with the TV-boxes. First I had an old Mini M8S II Amlogic S905x 2/8 box that had been in a drawer for years, and I thought it should be possible to use it as a mini server and found Armbian. Then I felt that 8GB was a bit tiny, and started to look around for something slightly bigger though still cheap. I was choosing between Rockship RK3328 and Allwinner H6 since it looked like they both had fairly good support already, and not an Amlogic S905x(2,3,4) since I read here on the forum about some bad practice from Amlogic. After finding out that the H6 only can handle 3GB RAM, I went for the RK3328. In my subjective experience, the Amlogic felt easier to work with and also felt faster... No idea if it is for real. Thinking about getting a box with an Allwinner chip as well, just so I have one each of the three bigger brands, but it will have to wait for some savings to pile up. The RK3566 boxes with 8GB RAM looks fun as well, but I don't think I use anywhere near 4GB at the moment...

Hi, @fabiobassa .
My df,free results show values like @curse 's.
Exactly, 4G RAM/64G ROM does exist.
There are honest people in that country once in a while.
 
I have since crashed it and recovered to a stock ROM that I had backed up, but it worked.
Also, I am now reinstalling all of armbian.
 
I'll see you then.

Ahh. So it's a HK1 thing...I got a H96 Max+ and at least it seems to have the specified RAM/eMMC size.
 
Welcome to Armbian 21.11.0-trunk Bullseye with Linux 5.10.68-rockchip64 No end-user support: built from trunk System load: 55% Up time: 2 days 21:36 Memory usage: 17% of 3.88G IP: 192.168.0.13 192.168.0.15 CPU temp: 75°C Usage of /: 10% of 57G storage/: 74% of 1.9T storage temp: 31°C curse@H96MaxPlus:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 1.9G 0 1.9G 0% /dev tmpfs 398M 44M 355M 11% /run /dev/mmcblk2p1 57G 5.4G 51G 10% / tmpfs 2.0G 0 2.0G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 2.0G 32K 2.0G 1% /tmp /dev/sda1 1.9T 1.4T 490G 74% /home/curse/Media /dev/zram1 49M 22M 24M 49% /var/log tmpfs 398M 0 398M 0% /run/user/1000 curse@H96MaxPlus:~$ free -h total used free shared buff/cache available Mem: 3.9Gi 711Mi 308Mi 43Mi 2.9Gi 3.1Gi Swap: 1.9Gi 4.0Mi 1.9Gi  

Sorry but I have to be sincere about this: I don't like the reasoning, I found it unethical.
 
Believe it or not, I don't receive any kind of money from anyone; Armbian team also does not receive anything from these no-name boards, instead has to pay electricity, bandwidth to host images and forums.
It is just courtesy of Armbian guys if all of this is possible, they ask nothing in charge; although Armbian does not officially support any TV Box - as clearly and boldly stated in the first posts of all my threads.
 
My role in all of this is just driven by passion and learning, not money. I decided to share my work and studies with others because I think that if other people does the same, the world will become a better and funnier place.
As you see, the learning curve is pretty steep, and trying to build an out-of-the-box working solution for boards whose specifications and datasheets are kept secret is a huge time wasting job.
What I expect in change is usually a "Thank you": most of the time it suffices.
 
Here I read, and I really hope I misunderstood the post, that someone is going to make business around this.
That's pretty ok to me: I do support tv boxes for passion. I also use Linux which is free and made by others for passion and work and I pay nothing to anyone; nonetheless I contribute to opensource the way I can.
 
Now if your concern is missed support, don't ask community what can do for you and point out what community is not doing for your business; start thinking about what you can do for community that helps both community and your business.
In all of this long thread I don't know how many people donated to Armbian project - I'm not part of the official team.
But I'm totally sure that, except for the very generous board donations from @fabiobassa to whom all people here should as well be very grateful, I never ever received a penny or one board from anyone. And note that I don't ask boards as gratification - I already have several of them taking dust - but to study them. Nonetheless I am still here available for free support and for fun.
 
Asking me, or anyone else, to spend money to buy cheap crap and spend time reverse engineering that crap for your business is just unethical. It's parasitizing.
You need good Linux support for your tv boxes? Ask the manufacturers of those boxes, and see what they answer to you.
The problem about the "right price" is that the price can't be right if you don't include software developing and maintaining costs. Chinese tv boxes manufacturers are fetching "just working" Android distro into their products. If they would want to support a full linux environment, the price would be three or four times the actual price.
 
Want to talk about business?
Send a precise request to the developer of your choice (me included) and wait for a proper price quotation.
 
Want to do everything by yourself? You can.
Armbian developers spent hours to write proper documentation, available on docs.armbian.com. Source code is publicly available on github repository.
If you find it difficult navigate into, spend hundreds of hours lo learn things, as me and several others did, to raise your skills to keep up with your business.

This demonstrates that you know very little about Armbian. Official support is granted for boards which have official specs and whose manufacturers provide datasheets. Hopefully those manufacturers also provide fundings, sponsorship or any kind of support. There is no reverse engineering with officially supported boards: manufacturers provide specs, in form of openly available electrical diagrams and general documentation.
 
Tv boxes don't provide any datasheet about board specs, often chinese manufacturers even provide fake specs to buyers to sell their crap. They definitely does not sponsor the project in any form, thus Armbian does not endorse any tv box, nor do I: you need something for a serious project? Buy serious hardware, not chinese cheap and unsupported crap.
 
If you think Armbian purpose is to tell you how to understand boards and their chips, understand datasheets, write proper device trees, configure and compile the linux kernel, and whatever it requires to properly support a board, you're out of context.
I spent time doing all of these things above, so everyone else can do that. If you don't have enough skills to do that, that's not a fault of the project. You can still build up those skills, if you have enough time and will to sacrifice for the purpose.
 
There is a donation and help providing page, not just money, but whatever people can do is appreciated, even writing documentation.
Plus the community does not need to be funded with money, it is funded by will of people who wants to do something useful for others.
 
Armbian is not a company that does things on people request and I don't think you can "hire" someone from inside the project for your particular needs.
But again I repeat: you can still contact and pay developers - ANY developer, not necessarily an Armbian developer - for your needs.

Hello everyone. I received my TV BOX from CN today, and I joined the game.
For your information, my box is [HK1 RBOX R1 mini] w/4G/64G.
It's the one with a picture of an eagle on the top.
I installed the files from the SD card.
Armbian_21.11.0-trunk_Rk3318-box_bullseye_edge_5.14.14_minimal.img
I used multitool to back up the stock ROM and then flashed it to eMMC.
Wired LAN, wireless LAN 2.4G, 5G, USB-KB, MOUSE all work normally.
In addition, I installed xfce and Firefox, and it seems to be slow, but it works well.
Thanks to whoever is releasing and maintaining this wonderful thing.
I will write again if there is any movement.
 
Thank you.
 
 

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.
 

@MX10.AC2N @curse That's true, the only way to update currently is to start from scratch and the reason is exactly the one hiphotesis by @curse is right: since the whole thing is not yet into mainline armbian, upgrading via apt is not possible. Even worse: upgrading via apt will install official armbian packages, and it would just break the installation because it would remove the existing dtbs.
 
I'm going to add the .deb packages in the first page along the pristine images for manual upgrade, in the hope it will not break existing installations

@MX10.AC2N Great, happy that we're very close to the solution
To get 1.3Ghz, just add rk3318-box-cpu-hs overlay.
If I read the dtb correctly, also the wifi is attached to the extra sdio bus on your board, so you'd better add rk3318-box-wlan-ext overlay too!
 
Reboot and you should get these two other things.
 
BTW: you can also use rk3318-config to do all the necessary overlay configuration with the comfy menu interface. Just need to manually edit armbianEnv.txt before rebooting and set rk3318-box-led-conf3 in place of any other led-conf (there must be only one led-conf overlay). In the next update I will add the led-conf3 to rk3318-config so coming people with boxes like yours will find the recipe ready-made

Look at the post edit I made a little after, clarifies why the thing can't work on our tv boxes.
 
I learned things are and there on the internet, could not find a proper guide.
Anyway google reports this forum thread, which is a good starting point:
 
Yeah, undervolting is cool, but results vary a lot depending on the cpu sample.
GPU can be tweaked too. RAM can't be tweaked for three reasons:
the dmc (dram memory controller) node in the dtb is disabled the dmc driver in the kernel is a bit broken the piece of code that does the dram frequency scaling is not present The dram frequency is fixed by a thing which is called ddrbin, and it is the very first thing that boots (even before u-boot).
It is fixed to 330 Mhz currently, but probably I will push it to a higher yet safe value.
 
You need to put together an idbloader, which is composed of ddrbin + u-boot SPL.
You can inspect armbian sources for that, but if you're not an expert in compiling u-boot, I would rather suggest you to stay away from that to avoid lose mental sanity.