Reply
Thread Tools
Posts: 362 | Thanked: 426 times | Joined on Nov 2010 @ Italy, Lombardia
#121
Originally Posted by pali View Post
No, It is same because first is multiply and then is byteshift. Try this:

Code:
printf("%#x %#x\n", 4*114 >> 2, 114);
printf("%#x %#x\n", 4*46 >> 2, 46);
output is:

Code:
0x72 0x72
0x2e 0x2e
Sorry but you are wrong.

My example was for a BYTE datatype, if you use an INT it is normal that it works as you expected because my numbers are too little to generate an overflow during left shift.

But please try with correct numbers
Code:
printf("%#x %#x\n", 4*1073741824>> 2, 1073741824);
printf("%#x %#x\n", 4*3075541994>> 2, 3075541994);
And the above code yields to these results:
Code:
0x0 0x40000000
0x37510bea 0xb7510bea
Numbers are very different now.

I reapet that C code like n<<VAR>>n (or (2^n)*VAR>>n) is usually used to clear the n most significative bits of VAR (if VAR is unsigned)

Last edited by Fabry; 2011-10-09 at 20:24. Reason: better english
 
Posts: 362 | Thanked: 426 times | Joined on Nov 2010 @ Italy, Lombardia
#122
Originally Posted by mirakels View Post
Yes it will be the same and probably will be compiled away.
But in this form it will show the weirdness of needing to scroll way beyond
the actual framebuffer.
It is the same only for values smaller than 2^(n-2), where n is the number of bits contained on you variable/constant (8, 16, 32 or 64).
So compiler can optimize (and remove useless operations) only if it is a constant and the fixed value assigned is less then 2^(n-2) alias 1,073,741,824 for an integer costant

Last edited by Fabry; 2011-10-09 at 20:21.
 
Posts: 2,154 | Thanked: 8,464 times | Joined on May 2010
#123
@Fabry: ok, now I know this, but in U-Boot our number was not very big (so no change)
 
Posts: 2,154 | Thanked: 8,464 times | Joined on May 2010
#124
Now I published new version of U-Boot. It has fixed eMMC support and runtime configurable bootmenu.

Source code is now in branch pali on u-boot-shr: https://gitorious.org/u-boot-shr/u-boot/commits/pali

Last edited by pali; 2018-07-08 at 14:26.
 

The Following 4 Users Say Thank You to pali For This Useful Post:
Posts: 362 | Thanked: 426 times | Joined on Nov 2010 @ Italy, Lombardia
#125
Good job.

Now when this problems:
  • High power consumption
  • Incompatibility with HW Rev different from 2101 (as Matan's version)
will be fixed, Pali's u-boot will be the best boot-loader for N900
 

The Following User Says Thank You to Fabry For This Useful Post:
Posts: 2,154 | Thanked: 8,464 times | Joined on May 2010
#126
For compatibility with other HW revisions, see http://talk.maemo.org/showpost.php?p...&postcount=120
Should work on 2101, 2204 and 2104...

And power problem. Now we have in u-boot code for twl4030 regulator, so we have tool for power control. Also code for control GPIO and MUX is in u-boot too...
 

The Following 2 Users Say Thank You to pali For This Useful Post:
Posts: 362 | Thanked: 426 times | Joined on Nov 2010 @ Italy, Lombardia
#127
So the two problems have been already fixed ?

I have a rev 2101 and I can check eventually only power consumption.
 

The Following User Says Thank You to Fabry For This Useful Post:
Posts: 1,225 | Thanked: 1,905 times | Joined on Feb 2011 @ Quezon City, Philippines
#128
Holy ****, Pali! This is better than Multiboot!
I'm going to measure power consumption before/after u-boot when I have time (probably this Saturday).

Can we have this by default in power50?
__________________
N9 PR 1.3 Open Mode + kernel-plus for Harmattan
@kenweknot, working on Glacier for Nemo.
 
Posts: 362 | Thanked: 426 times | Joined on Nov 2010 @ Italy, Lombardia
#129
I made an attempt with the new kp48 image.

These are the problems found:
  • Power consumption problem is still present.
    Initially it seems that p. consumption is normal (discharge rate on idle = 1-3% / hour) but after 1-2 hours of continuos idle the situation changes and becomes "discharge rate on idle greater than 10% / hour"
  • Lcd screen is always powered on.
    Maemo never turns off it, it only shows a black screen (with backlight on, this is evident on a dark room)
  • There is problem with battery's charge measurement.
    I had 50% of reported battery's charge and I have rebooted the phone.
    After reboot reported battery's charge was only 7% and some mins after it was still 7%.
    I doubted that a boot process can really consume over 40% of battery's charge, so I have flashed, by multiboot, a PR1.3 kernel (with no u-boot).
    After reboot the reported battery's charge was 10% (greater than before) and some mins after it has raised to 39%
  • It seems that bootmenu appears even with closed keyboard
 

The Following 2 Users Say Thank You to Fabry For This Useful Post:
Posts: 197 | Thanked: 101 times | Joined on Dec 2009 @ Netherlands
#130
@fabry
comparing uboot+kp48 with pr13kernel seems wrong to see power consumption differences.
You should use kp48 with and without u-boot to do valid comparison tests.
 

The Following User Says Thank You to mirakels For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 19:42.