hexdump
-
Posts
472 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by hexdump
-
-
On 6/4/2019 at 8:58 PM, Sico said:
@hexdump I tried to change these entries and many more but with no success.
Maybe a silly question, can we just take and build the dtb from the android dts changing the boot references? There are other important parameters?@Sico - using the android dtb will most probably not work - i tried it with the t9-android.dtb on my t9 and it failed. with a serial console i was at least able to boot with it with "init=/bin/bash" in the kernel cmdline, but it paniced as soon as i tried to do anything more complex with it.
as i said, the only real option from where you are right now is to get the serial console working and post the boot output when booting your rk3328-t9-2g.dtb ...
good luck and best wishes - hexdump
-
what exactly would be required to be done (for someone who never did any dram driver development)? i looked at the commits in the git repo you mentioned and it looks like it contains tries to define the ram timing in the code but at some point it switched to getting the timing info from a binary blob. is that correct and do you know how far he got with either of the two approaches?
a lot of thanks in advance and best wishes - hexdump
-
i just gave it a try to boot the orange-pi-3 and pine h64 armbian images and the orangepi 4.9 kernel image on a q-plus h6 4g/32g tv box and it did not work out well - the serial console output was:
Quotearmbian images:
U-Boot SPL 2019.04-armbian (May 27 2019 - 02:06:56 +0200)
DRAM:This DRAM setup is currently not supported.resetting ...
orangepi 4.9 kernel image:
[240]HELLO! BOOT0 is starting!
[244]boot0 commit : 94a1b3d504ad4cd9bb5d9522947301ac0350ab1b
[251]key press : [and nothing more. looks like one would first need to get some uboot working to the point that it boots well and is able to boot a kernel. the legacy uboot on the box is a 2014 one, so even older than the already historical 2015 ones from amlogic boxes
... the bad thing about it is that you cannot interrupt its boot via keyboard early on, so no way to explore if it can be used to boot a mainline kernel.
anyone having any idea how to add the proper dram setup to uboot (i guess its not part of the dtb as for rockchip devices) or how to extract maybe a sdcard uboot from a stock firmware image (like it can be done for amlogic boxes)?
best wishes - hexdump
-
@armar - yes with the -I or -O fs options you can also use a device tree structure as input or output for the dtc command - it then works exactly like a dtb file with the -I or -O dtb options.
@Sico - your edited dts file looks right - the last easy option is see would be to set the dmc-opp entry (memory voltage and frequency scaling) for opp-600000000 and opp-800000000 from disabled to okay like in your dts, but i guess it will not help much neither. opp-hz should not really differ between the dts files, except for the higher disabled clocks by me.
if all that does not help, i would suggest you get some pl2003 usb to serial adapter and solder a serial console to your board (only gnd, rx and tx - usually tx from the board to rx of the adapter and the other way around). this way you will be able to see the bootup messages and get an idea about what really is the problem. one thing to be aware is that the baud speed of the serial console is 1500000 for rockchip devices instead of the usual 115200.
good luck - hexdump
-
hi @armar - the above device-tree-copy.tar.gz is the android dtb, just in another format and read from the system in an easier way
@Sico - your hardware is definitely different from the 4g/32g t9 hardware - atttached is the resulting android dts file for your box - what you can do is: take my rk3328-t9.dts file from above and change all the opp-microvolt* values in the various sections to the values in your dts file and then build your dtb from it on a linux machine with the command "dtc -I dts -O dtb your-modified-rk3328-t9.dts > rk3328-t9-2g.dtb" and try this dtb then. you might need to install the "device-tree-compiler" package on your linux system for this.
good luck and let me know about the result and post the resulting rk3328-t9-2g.dts and rk3328-t9-2g.dtb files here in case it works.
hexdump
-
@coreyou - for the t9 you need my special rk3328-t9.dtb - just look upwards in this thread to find it. @balbes150 - can you maybe include it into the next image you build? it seems to at least work well on the 4g/32g models.
@Sico - in case another sd card will not help neither, then i guess the hardware is different between the 4g/32g model which i use and the 2g/16g model you have. in that case maybe try to install a terminal app on your android, put in some free and fat32 formatted sd-card or usb stick, find out where it gets mounted via "df" command, cd to that dir, run the following code:
Quotemkdir device-tree-copy
cd device-tree-copy
for i in `find /proc/device-tree/ -type d | sed 's,/proc/device-tree/,,g'` ; do echo $i; mkdir -p $i ; done
for i in `find /proc/device-tree/ -type f | sed 's,/proc/device-tree/,,g'` ; do echo $i; cat /proc/device-tree/$i > $i ; done
cd ..
tar czf device-tree-copy.tar.gz device-tree-copyand afterwards please attach the resulting device-tree-copy.tar.gz here. this is the dtb describing the hardware and which we can then read by unpacking that archive and running "dtc -I fs -O dts device-tree-copy" on a linux machine to maybe find out more ...
best wishes - hexdump
-
@Sico - if you use my rk3318-t9.dtb it should work with only the sd-card, so the sd-card and usb-stick procedure should not be required. maybe doublecheck that you have the proper dtb and that it is referenced properly in extlinux.conf (FDT /dtb/rockchip/rk3328-t9.dtb and no FDTDIR defined) and then it should simply work. only try the t9-fast one if you have it running stable with the normal t9. mx10 usually will not work on t9 and h96max+ with sd-card only, as it does not detect the sd-card after booting. what might also be possible is that the manufaturer changed the hardware meanwhile - this can always happen with those cheap chinese tv boxes. if you do not get it running at all, it might be required to solder wires to the gnd, rx and tx connection on the board and connect it to anther computer via some usb to serial adapter to see where it fails on the serial console output.
good luck and best wishes - hexdump
-
please keep in mind, that you will need a special t9 dtb for the t9 box - just see my last post a bit up from here to download it
best wishes - hexdump
-
-
here is the latest round of my dtb for t9 and h96max+ rk3328 tv boxes - changes since last version:
- properly enable dmc (i think this allows better memory timing)
- raise voltage for the 1.392ghz clock (disabled by default) to the values which worked for @amirul as well
- raise thermal trip points slightly to 85/95/110 degree celsius
- add a rk3328-t9-fast.dtb which has the 1.392ghz cpu clock and higher memory clocks enabled (the 1.512ghz cpu clock is still disabled by default as its likely not working or too unstable in most cases)
the cpu performance ist about 5-10% better than my last t9 dtb for the regular t9 dtb and about 10-15% better than my last t9 dtb for the t9-fast dtb and as such the cpu performance is now about even with the mx10 box one ... i noticed that the usb2 port might be a bit unstable at times, so better use the usb3 port - maybe this is a general problem for rk3328 boards ...
best wishes - hexdump
rk3328-t9.dts rk3328-t9.dtb rk3328-t9-dtb.diff rk3328-t9-fast.dtb rk3328-t9-fast.dts rk3328-t9-fast-dtb.diff
-
@balbes150 - do you remember where the mx10-fast dtb is coming from or do you know, what exactly makes it faster? i compared it to the normal mx10 dtb on an mx10 box and it is indeed about 10% faster ... then i compared the two dts files, but the differences are huge and the mx10-fast looks more like a modified evb dts. i'm doing all this to find out, if it is posssible to speed up the t9 box a bit as well - it is with my t9 dtb as fast as the mx10 box with the regular mx10 dtb. comparing all those dts files the only obvious differences which might be relevant for the speed are the ddr timing (which is nearly the same for the mx10-fast as for my t9 dtb, so not much to gain here), the cpu opp tables (also very similar, only the mx10-fast dtb uses higher voltages than the others) and the dmc opp tables (same as for the cpu opp tables). i think that only rasing the voltages doe not speed up anything without raising the clocks too and will just produce more heat - right?
in general the mx10-fast dtb is at 1296mhz comparable to an amlogic s905w at 1200mhz (i.e. only a few percent faster), but with the non fast dtbs those rk3328 boxes seem to be about 10% slower than the amlogic ones at the same/similar clock speed and this does not really make too much sense as they are all using a53 cores and their performance scales nearly linearly with clock speed (for instance a raspberry bit 3b at 1.2ghz has nearly exactly the same cpu performance like an amlogic s905w at 1.2ghz).
-
-
-
hi @amirul, thanks for testing - i think the performance difference to the mx10 might be due to cheaper components maybe - i have now as a last round added the ddr memory timing from the t9-android dtb as well - not sure if it makes any significant difference ... it is interesting that the 1.4 and 1.5 ghz speeds do not work for you - on my box (t9 too) both work well (at least in normal usage), but the box heats up very fast then - maybe also different components used even within the same line of those boxes - with them everything is possible
latest t9 dtb with t9 android ddr memory timing:
-
my last t9 dtb was still missing some changes: the voltage regulator setup seems to be quite different between the evb and the t9 / h96max+ which also affected the cpu powering and as a result the voltage and frequency scaling was still not fully working and the box was only running at about 600mhz cpu clock max most of the time ... i have now reworked the t9 dtb even more - again based on the t9-andoid dtb - and cleaned up the regulator setup completely as i think ... now frequency scaling works well and the box should run at about twice the speed as before
... while i was at the opp tables and the voltages i also added disabled entries for 1.392 and 1.512 ghz cpu clock with useful values for this regulator setup - it works, but i did not do proper long stability tests with cpuburn and it does not make much sense at all anyway, as the box with the default cooling will heat up quickly and will be thermal throttled down to below even the default 1.296 ghz soon ...
based on the dtb source diff it should now even be possible to build a properly working dts source file for the kernel source tree based on the evb dts in there and maybe even a working dts/dtb for the mainline kernel might be possible with a bit of work ..
now the files - if you have a t9 or h96max+ (untested by me, but looks like it has the same hw setup - please let me know if it really works) box, you should definitely give this dtb a try ...
-
with this diff against rk3328-evb.dtb for the 4.4 rockchip kernel i got mmc, serial console and the usb2 port working for a t9 rk3328 box (4/32g) and i think the h96max+ is similar, so maybe it will work there too - the resulting rk3328-t9.dtb and .dts are attached as well. @balbes150 if it works for others too it might be worth to include it into future rk3328 tv box images maybe.
-
i assume that the box simply has nand and no emmc - i have a similar box (x96 mini): sold as s905w 2/16g box with emmc and in the end it is a s905x box with 1/8g and nand which fakes the 2/16g in its hacked android - your emmc chip printed name might simply be fake as well - the boot problem comes from the armbian boot script, it hangs when probing the (non existing) emmc i guess - i think i worked around it by 'setenv start_emmc_autoscript "echo hello"'' and then 'run bootcmd' on a serial console - in theory setting the start_emmc_autoscript to something not doing anything (or maybe even some cleaner solution) in some kind of alternative aml_autoscript should give you back a working android boot even without serial console ... good luck
-
-
hi @jock - i'm thinking about trying to follow your approach of getting a rk3288 tv-box booting well with a mainline u-boot instead of the very limited rockchip bootloader those boxes come with. the box i have is an orbsmart s92, which i think is identical to the beelink r89, orion r28 and ubox boxes. i have it running quite well so far using some sd-capable rockchip bootloader i once found on the linuxium site, but as said having a real contemporary mainline u-boot would make booting different kernel etc. much easier and maybe even gives me a serial console for the bootloader (the bootloader i have does not seem to use the normal serial port - starting from the kernel boot it works fine then though). i looked at the way you are building the u-boot for the q8 box from the original rockchip and the mainline one and i read your mainline u-boot contributions for the q8 box and have three questions about it:
1. how did you get the memory timing when booted with the original rockchip bootloader - did you add some debug prints to the kernel or did you get it via some userspace program?
2. how big might be the chance that another rk3288 tv-box like my s92 might work with your memory timings?
3. do i need any other specific information about my hardware to get mainline u-boot compiled for it? to me it looks like the memory timing is the only one and everything else i can get from the linux kernel dtb for my box, but maybe i overlooked something ...
a lot of thanks in advance and best wishes - hexdump
-
hi @balbes150 first a big thank you for all your efforts - it is so nice to be able to use those easily available amlogic (and now rk3328 too) tv boxes as linux systems so easily! i have a question regarding your emmc install script: you are putting the beginning of the partition about 700mb after the beginning of the emmc device to avoid overwriting sensible stuff required for booting like the dtb etc. i guess - are those 700mb based on anything specific or is this just a good guess that that far nothing relevant should be anymore? do you have any more details what critical information required for booting is on the emmc and should not be overwritten - i think dtb and env are required for sure - anything else? a lot of thanks in advance and best wishes - hexdump
Since Tanix TX6 can boot from the SD card
in Allwinner CPU Boxes
Posted
oh - that sounds quite complicated
would btw. also something like https://github.com/armbian/build/blob/master/config/sources/rockchip.conf#L68-L71 possible where @jock used the existing binary spl for the memory initialization and then combined it with mainline uboot on the xt-q8l-v10 rockchip tv box?
a lot of thanks in advance and best wishes - hexdump