hexdump

Members
  • Content Count

    12
  • Joined

  • Last visited

About hexdump

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @amirul - can you please try to set the two entries with status = "okay" in the dmc-opp-table section to status = "disabled" in t9-fast and check if this runs more reliable? the opp-table entry now uses the voltage, which worked for you, so that should not be the problem. best wishes - hexdump
  2. 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
  3. @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).
  4. @Hai Phan a a5x dtb can be found here: if that does not work, then maybe give my t9 dtb from here a try: good luck! - hexdump
  5. @amirul - if you enabled both speeds at once, you might try to enable only the lower one - maybe this one still works, but the 1.5 ghz is too much for your box then ...
  6. 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: rk3328-t9-dtb.diff rk3328-t9.dtb rk3328-t9.dts
  7. 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 ... rk3328-t9-dtb.diff rk3328-t9.dtb rk3328-t9.dts
  8. 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. rk3328-t9-dtb.diff rk3328-t9.dtb rk3328-t9.dts
  9. 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
  10. @jock - thank you for the detailed response. this sounds really good - this way it might be even easier than i thought, as i'm completely fine with using the original u-boot part for the memory timing
  11. 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
  12. 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