Lollipop - Wasser Firmware for Beelink R89

[Gormar]

I'm currently use Ugoos 3.0.4 patched wasser 3.0.3.
If I understood you, I need to flash wasser 3.0.4a (system.img) and from your zip (resources.img, kernel.img)

No. You have to flash resource.img and kernel.img from Rusk's zip file. But you should assert if your Android Tool have proper address for them both. To do so you should look into /proc/cmdline file with for example "cat" command. I think that default values 6000h for resource and e0000h for kernel should be used in UGOOS firmware also. But better safe than sorry .

[Ben.Efrati]

No. You have to flash resource.img and kernel.img from Rusk's zip file. But you should assert if your Android Tool have proper address for them both. To do so you should look into /proc/cmdline file with for example "cat" command. I think that default values 6000h for resource and e0000h for kernel should be used in UGOOS firmware also. But better safe than sorry .

But if I don't flash the system.img, I'll stay with Ugoos version and not wasser 3.0.4a

[Gormar]

But if I don't flash the system.img, I'll stay with Ugoos version and not wasser 3.0.4a

Yes of course. My bad. But you don't have system.img yet. You should extract it from Wasser's update.img with RK3xxx firmware tool.

Nevertheless it might be dangerouse to leave data from previous system. If you want to preserve data from apps you should backup them with for example Titanium Backup Root.
What's strange with Wasser's LP(and probably some other) I can't use this tool to install backed up applications and I have to use Google Play Store which is a pain in the lower part of my back .

[Rusk]

Ben.Efrati,
I don't understand You... If you want to fully upgrade to Wasser 3.0.4a, of course, all your data and apps will be removed.

[Ben.Efrati]

Gormar , Rusk
Thank you both.
I'll extract wasser 3.0.4a system.img from update.img and then flash it with kernel.img and resources.img from rusk's post

[Gormar]

Gormar , Rusk
Thank you both.
I'll extract wasser 3.0.4a system.img from update.img and then flash it with kernel.img and resources.img from rusk's post

Don't forget to flash boot.img also.
You can try this but remember to create backup first.

On the other if you do not flash misc.img you might have problems. And if you flash it your whole data partition will be formated.
There is also another problem. System.img and system partition inside UGOOS 3.0.4 and Wasser's 3.0.4 LP ROM's might have different size. Flashing them interchangable you might overwrite other important data.

[BTR11]

Unfortunately, I do not have the necessary knowledge to check or fix this problem.
I can advise only to patch it by new Wasser 3.0.4a. I extracted resource and kernel, try, maybe it will fix the problem...

In addition, for users Tronsmart Orion R28 - IR Remote support in Wasser-3.0.4a - resource+kernel_tronsmart_r28_wasser304a.7z

Thanks Rusk; I did this by myself before asking the question here, and the reults was the same, the R89 cannot see the 5Ghz - AC channels 132 - 144, for that reason I thought in some intervention / modification to the level of sytem.img from Ugoos; if some of you can confirm that the wifi dirver as it´s configured into this rom UT3 v3.0.4 patched waser 3.0.3 or 3.0.4a can not see those channels it would great to know.
So the region setup for WiFi driver it´s not coming from the kernel or resource.img but from system.img; so in Ugoos LP, the region for 5 Ghz band is not USA, it´s any other for that reason the R89 cannot see 5Ghz AC channels from 100-112 & 132-144. The 2.4 Ghz & 5 Ghz wifi region can be easily changed by the users in Windows system thru driver´s properties, it´s not the same in Android that if the developer/rom cooker does not consider this aspect the user can not access this property. Wasser v3.0.3 & 3.0.4a do not have this problem, in 5 GHZ band the Wifi can see all channels and the signal it´s very strong.
The attached file (from dd-wrt forum) shows in dark-black color the 5 Ghz active channels by regions worldwide; setting a very restricted region into the driver produce these problems.

[BTR11]

Hi Gormar, I see in your signature you had been using wasser 3.0.4a with kernel & resource overclocked, in Lollipop what it´s the maximum stable you had tested?; can you share thes images.
I´m still running in one of my R89, ugoos stage 3 with your kernel & resource.img overclocked to 1.92 Ghz with excellent performance. Thanks.

[Gormar]

... in Lollipop what it´s the maximum stable you had tested?; can you share thes images.

My signature wasn't completely updated after I flashed Wasser's 3.0.4a ROM. No it is wholly true and tested.

RK3288 maximum stable frequency is quite difficult subject. It might depend from what software someone use and if there is proper cooling of the SoC. During my first trials with RK3288 OC (in Wasser's first KK ROMS) I could quite easlly achive 2.0 GHz for CPU, 625 MHz for GPU and 792 MHz for DDR3. After passing time, many different ROM's and probably some IC deterioration (maybe PSU?) I couldn't achive stable boot with 2.0 GHz CPU then I settled with 1.9GHz max OC. What's strange with mo123's HPH LP v1.3 ROM with Wasser's 3.0.3 kernel and resource my box couldn't work stable with 1.9GHz and that's why I lowered my OC once more to 1.8GHz. Now with Wasser's 3.0.4a LP ROM again I can use this device with 1.9GHz CPU but I didn't test memory OC above 640MHz primarily because for some strange reason I can not use /dev/video_source to change DDR3 frequency on the fly.

I can dump my resource.img and send it here but you can use my overclockmatic_RK3288 tool faster.

[BTR11]

Ok Gormar, thanks. I had not tried your overclomatic yet, but I will study a little about it and I will try and see the results. I think I can start with the same values used in stage 3, had been stable in KK.
The idea is to help to minimize the "lag"ops with the mouse, that kind of cursor stuck , microfreeze when using air mouse, a R-89 old & chronic problem.

[Gormar]

Ok Gormar, thanks. I had not tried your overclomatic yet, but I will study a little about it and I will try and see the results. I think I can start with the same values used in stage 3, had been stable in KK.
The idea is to help to minimize the "lag"ops with the mouse, that kind of cursor stuck , microfreeze when using air mouse, a R-89 old & chronic problem.

I think that overclocking CPU doesn't help with mitigating those muicrofreezes problem because those are most probably connected with eMMC.
Even so with Wasser's 3.0.4a LP ROM I might say that this problem is quite rare.

[BTR11]

I think that overclocking CPU doesn't help with mitigating those muicrofreezes problem because those are most probably connected with eMMC.
Even so with Wasser's 3.0.4a LP ROM I might say that this problem is quite rare.

I thought OCéd CPU + RAM could help with that microfreezes, but it´s not, you are right, the eMMC had been a huge mistake on this device, this is not a part of the hardware system to cut cost, message to Beelink, this cost "reputation or good will".
Well, I think these microfreezes here are as often as usual on the latest roms, KK or LP, may be can be noticed more or less depending of the usage of the device, but it´s a matter of just clicking the air mouse couple of times you can suffer it.

On the other hand, I found you overclomatic v1.7-LP into the thread because in OP the link does not work, I had followed your instructions and ran it and I get OC'éd the device with original config without touch it, so i got CPU @ 1.92 Ghz (1.4 v) - DDR @ 800 Mhz (1.275 v) - GPU @ 600 Mhz (1.2 v). The GPU value it´s the same of the original wasser v3.0.4a. So with those values i run antutu 6.0.1 (latest) and the score was around 54500. After that, I had used the device during 3 hours now and hed been stable without see any bad symptom yet. Very handy and easy to use your overclockmatic, thanks.
The original 4 CPU operatings points into wasser v3.0.4a found by overclockmatic are at least curious, very conservative:

Found CPU clock DTB leaf start at offset: Ox14170
Modify CPU clocks? (y/n}:y
Found 4 CPU operating points at Ox1417c:
MHz : mV
312 : 1100
504 : 1100
816 : 1100
1008 :1100
Modified CPU operation points:
1608 :1300
1704 :1325
1800 :1350
1920 :1400
Found 10 CPU PVTM operating points at Ox14278:
MHz : mV : margin uV
600 : 950 : 50000
696 : 950 : 50000
816 : 1000 : 50000
1008 :1050 : 75000
1200 :1100 : 75000
1416 :1200 : 75000
1512 :1300 : 75000
1608 :1350 : 75000
1704 :1350 : 75000
1800 :1350 : 75000
Modified CPU PVTM operation points:
MHz : mV : margin uV
600 : 950 : 50000
696 : 950 : 50000
816 : 1000 : 50000
1008 :1050 : 75000
1200 :1100 : 75000
1416 :1200 : 75000
1608 :1300 : 75000
1704 :1325 : 75000
1800 :1350 : 75000
1920 :1400 : 75000
Confirm write operation (y/n):y

[Gormar]

The original 4 CPU operatings points into wasser v3.0.4a found by overclockmatic are at least curious, very conservative:

Found CPU clock DTB leaf start at offset: Ox14170
Modify CPU clocks? (y/n}:y
Found 4 CPU operating points at Ox1417c:
MHz : mV
312 : 1100
504 : 1100
816 : 1100
1008 :1100

Yes, although those CPU operation points hasn't any meaning because PVTM (Performance, Voltage, Thermal Management) is enabled.

Other thing to notice is that if you just had used default overclockmatic_RK3288.cfg file then your DDR3 frequency is 646MHz (670MHz in config) because the last value (800MHz what gives real 792MHz) is only for performance mode which isn't configured in Wasser's 3.0.4a LP resource file part called DTB. Even if it was there choosing it would require manual intervention.

[BTR11]

Other thing to notice is that if you just had used default overclockmatic_RK3288.cfg file then your DDR3 frequency is 646MHz (670MHz in config) because the last value (800MHz what gives real 792MHz) is only for performance mode which isn't configured in Wasser's 3.0.4a LP resource file part called DTB. Even if it was there choosing it would require manual intervention.

Let me share the rest of the log with you, may be you can say something more about it:

Found DDR Memory clock DTB leaf start at offset: Ox1434c
Modify DDR memory clocks? (y/n):y
lnfo: Changed endian in DDRleaf.
lnfo: Changed endian in DDRleaf.
lnfo: Changad endian in DDRleaf.
lnfo: Changad endian in DDRleaf.
Found 4 of DDR memory operating points at Ox14358:
MHz :mV
200 : 1075
300 : 1075
456 : 1125
533 : 1150
Modified DDR memory operation points:
200 : 1075
456 : 1125
600 : 1200
800 : 1275
Found 1of DDR memory freq-table at Ox143d4:
SYS_STATUS_NORMAL : 533 MHz
Modified DDR memory freq-table points:
SYS_STATUS_NORMAL : 600 MHz
Found 4 of DDR memory auto-freq-table at Ox143e8:
MHz: 240, 324, 456, 528
Modified DDR memory auto-freq-table:
MHz: 240, 456, 600, 800
Confirm write operation (y/n): y

Found GPU clock DTB leaf start at offset: Ox144b0
Modify GPU clocks? (y/n): y
Found 2 of GPU operating points at Ox144bc:
MHz : mV
500 : 1150
600 : 1250
Modified GPU operation points:
533 : 1200
600 : 1250
Confirm write operation (y/n): y
Kernel locks not found till offset: Ox1000000
1lroot@flounder:/data #


When you talk about "performance mode" you make reference to set the governor to "performance" i.e thru non-frills cpu app? to can get the maximum frequency on DDR?; currently I´m running interactive governor with cpu from 1608 to 1920 Mhz & deadline I/O scheduler. I guess is a good thing that the rom (or the kernel.ing) it´s reported without "locks". Thanks gormar for your work and recommendations.

EDIT:
PS: I had re-read your OC thread & now understand what do you mean by performance mode for the DDR3 (different of Performance Governor for the CPU); so with the command echo "p" > /dev/video_state I will be running the device´s DDR with the maximum frequency of 800 Mhz (that for DDR3 means x2 to get 1600 Mhz); is Ok to run the Box permanently in this way, is it safe?
As well I had seen different values between .cfg file from overclockmatic v1.0.6 & v1.0.7 and now you mention other values not contained in those files, so I will be tweaking to the values mentioned by you on DDR, that 670 Mhz does not exist on those .cfg files.
By the way I like what I´m getting from Wasser v3.0.4a with these OCéd values, I perceive some improvements with the "lag" / microfreezes with the air mouses, it´s less noticeable, may be too early to say it, but it´s looking good.

[Gormar]

echo "p" > /dev/video_state

This command will not work as expected in at least last Wasser's LP ROM because DTB in resource file contains only one SYS_STATUS value called "NORMAL" (echo "n" > /dev/video_state) and there isn't for example SYS_STATUS_PERFORMANCE. That's why last value from overclockmatic DDR frequency table isn't efectively used as in my assumption. Overclockmatic_RK3288 was built with thought that last value should be associated with "PERFORMANCE" mode. To get higher DDR frequency just change penultimate DDR value (600) to some bigger number but do not forget to set 1200 mV for ARM LOGIC in this DDR operation point because it might be required for this SoC to operate DDR-1600 mode in stable condition. 800 Mhz (1600MHz DDR) for DDR3-1600 memory at 1.5V (seen as 1.2V in PMIC (regulator.1) because it is decived by voltage divider on feedback input) shouldn't be a problem. For RK3288 it might because according to this SoC White Papers it is only validated for DDR3-1333 memory.

Note: 670 (646 in real life) DDR frequency might be default in my internal overclockmatic config. In the wild I might have choose different value .

I like last Wasser's LP ROM quite a bit but there are some quirks that I might want to change. For example GPU operation table contains only two frequency values and the lowest is quite high. [email protected] for idle GPU frequency IMHO isn't rational especially if you consider that this was maximum frequency in first ROM's and this SoC GPU can work with frequency as low as 180MHz at 0.9V. But maybe I don't know something and it can have impact on stability which is rather exemplary in last Wasser's firmware.