problem using rockboxdev script to download cross compilers.

Hi list.
I am wondering if someone could please help me with a problem I am having 
downloading the cross compilers using the rockboxdev script, and also answer 
a few questions regarding target cpus.

firstly, are there only 3 types of cross compiler I need to download? as the 
wiki page on cross compilers talks about 3, but reading the window once the 
script is run is a little bit tricky with my screen reader, so that's why I 
am asking.
I want to get all of the cross compilers, because eventually I want to get 
this machine running a build server it more than meets the recquirements.

Now on to my problem I am having with getting one of the cross compilers.

I was trying to get the sh-1 cross compiler, and I put in s for the target, 
but something must have gone wrong when the file was downloaded as I get a 
message about unexpected end of archive.

So my question is could someone please tell me where I need to go in order 
to delete that corrupted file and start again?

I realise the path is given where files are downloaded when the script is 
run, but it is not the easiest dialogue to read with a screen reader. So I 
would appreciate it if someone could tell me the path please and the file 
name to remove.

Many thanks for your help.
Alex. 

__________ Information from ESET Smart Security, version of virus signature database 4650 (20091130) __________

Re: setting up linux for compiling rockbox.

Hi, many thanks for your reply.

The problem with the shared folder may this: The created folder is a virtual 
one and if you share this via vmware, it is still on the vm hard disk. Try 
to take the folder on your real OS and share it from there to the machine.

Could you please tell me how I go about doing this? I understand about 
folder sharing in windows, but am not at all sure about how to do this under 
linux, or what I would need to do to get windows to share my rockbox folder 
with the virtual machine.

Many thanks for your help.
Alex. 

__________ Information from ESET Smart Security, version of virus signature database 4650 (20091130) __________

The message was checked by ESET Smart Security.

http://www.eset.com

Re: setting up linux for compiling rockbox.

Re: setting up linux for compiling rockbox.

Please, i like to help ;). I will take a look, for how to make the folder shared from the real OS to the GUEST OS. I
use Mac, witchone you use? it is a bit important. When i know your real OS, it migt be better for me to look.
because i have al three systems: linux, mac AND Windows (xp, the best :) ).
So, tell me, what's your OS and i will take a look for you!
Bye!!

Re: setting up linux for compiling rockbox.

Am 01.12.2009 06:12, schrieb Kevin Ingwersen:
> Please, i like to help ;). I will take a look, for how to make the folder shared from the real OS to the GUEST OS.
I use Mac, witchone you use? it is a bit important. When i know your real OS, it migt be better for me to look.
because i have al three systems: linux, mac AND Windows (xp, the best :) ).
> So, tell me, what's your OS and i will take a look for you!
> Bye!!

Can you do that privately? Setting up a VM or the like doesn't belong to 
this list. Thanks.

Best regards.

Re: brain dump/plan re simplifying viewport/theme support in screens

small update.. closer to being reviewable.... WPS doesnt work as
expected, rec screen and lists do, plugins almost working...

2009/11/25 Jonathan Gordon <jdgordy <at> gmail.com>:
> more brain dump...
> end of last week it was agreed on that really the only place where
> having a "statusbar" is absolutly required is *early* usb and charging
> (early being almost never seen by users because its handled in the
> bootloader...)
> So, the better solution than trying to hardcode a fallback sbs (like
> the fallback wps) is to fix those screens with some pretty
> aniumations, or actually lay the info out on the screen better (TBD).
>
> What this means (along with the api rework) is that the only screens
> that would ever need to enable/disable the theme are ones which
> actually only disable the theme, all others would just assume that the
> theme is active. This means a fair bit of simplification (specifically
> the fm and rec screens).
>
> We could allow some screens to force toggle the theme (e.g do_menu() )
> but I'm leaning more to making it required of the calling code to
> re-enable the theme before calling do_menu() which means we can get
> rid of some logic there which currently handles showing the bars.
>
> The big annoyance will be for plugins here.. so we could fix a
> do_menu() wrapper for them to undo the theme, call do_menu(), then
> redo the theme change... not sure if thats a good idea though.
> In the core, I cant think of too many screens which would ever need to
> disable the theme... (Actually, only the quick/pitch screens, and the
> graphic EQ changer screen come to mind...)
>
> Jonathan
>
> 2009/11/24 Jonathan Gordon <jdgordy <at> gmail.com>:
>> Attached is my very quick first effort of doing this change in svn...
>> it doesnt work, and doesnt even compile yet.. yet enough has changed
>> so you get some idea of how it simplifies the API a bit (not much
>> though, but some...)
>>
>> It turns out that we probably cant completely hide _Set_fullscreen and
>> set_default to just viewport.c, although I'd really like to....
>> The reason why one funciton for both (externally) works is because of this:
>> 1) A screen knows how much room it needs... it has exactly 2 choices,
>> a) use the theme, or b) use full screen.
>> 2) with a single API call it can say "disable the theme, and setup the
>> viewport for full screen" which does everything else needed in the
>> background (i.e disabling the sbs updateing, etc)
>> 3) if a screen calls _set_fullscreen without disabling the sbs then
>> bad things will happen, doing it in 1 api call eliminates that
>> problem.
>>
>> anyway.. have a open mind over this... we can argue in the morning :)
>>
>> Jonathan
>>
>

Re: brain dump/plan re simplifying viewport/theme support in screens

flyspray is down and I'm ready for bed... this version builds without
warnings on bitmap lcd...

This patch (imo) simplifies the statusbar and viewportmanager API's.
magically fixes a bunch of the current statusbar redraw issues, and
removes some GUI events which would be better if they wern't
required... This also removes the notion of a inbuilt statusbar..
either its enabled or its not (top/bottom/custom all still work),
which means that some screens which used to force the bar cant do this
anymore... I think the only big "issues" here is recording screen
(semi skinnable, so maybe not such a issue) and early chargin/usb
screens which can be sorted out separately.

please test it out and let me know how it goes...
Jonathan

2009/11/30 Jonathan Gordon <jdgordy <at> gmail.com>:
> small update.. closer to being reviewable.... WPS doesnt work as
> expected, rec screen and lists do, plugins almost working...
>
> 2009/11/25 Jonathan Gordon <jdgordy <at> gmail.com>:
>> more brain dump...
>> end of last week it was agreed on that really the only place where
>> having a "statusbar" is absolutly required is *early* usb and charging
>> (early being almost never seen by users because its handled in the
>> bootloader...)
>> So, the better solution than trying to hardcode a fallback sbs (like
>> the fallback wps) is to fix those screens with some pretty
>> aniumations, or actually lay the info out on the screen better (TBD).
>>
>> What this means (along with the api rework) is that the only screens
>> that would ever need to enable/disable the theme are ones which
>> actually only disable the theme, all others would just assume that the
>> theme is active. This means a fair bit of simplification (specifically
>> the fm and rec screens).
>>
>> We could allow some screens to force toggle the theme (e.g do_menu() )
>> but I'm leaning more to making it required of the calling code to
>> re-enable the theme before calling do_menu() which means we can get
>> rid of some logic there which currently handles showing the bars.
>>
>> The big annoyance will be for plugins here.. so we could fix a
>> do_menu() wrapper for them to undo the theme, call do_menu(), then
>> redo the theme change... not sure if thats a good idea though.
>> In the core, I cant think of too many screens which would ever need to
>> disable the theme... (Actually, only the quick/pitch screens, and the
>> graphic EQ changer screen come to mind...)
>>
>> Jonathan
>>
>> 2009/11/24 Jonathan Gordon <jdgordy <at> gmail.com>:
>>> Attached is my very quick first effort of doing this change in svn...
>>> it doesnt work, and doesnt even compile yet.. yet enough has changed
>>> so you get some idea of how it simplifies the API a bit (not much
>>> though, but some...)
>>>
>>> It turns out that we probably cant completely hide _Set_fullscreen and
>>> set_default to just viewport.c, although I'd really like to....
>>> The reason why one funciton for both (externally) works is because of this:
>>> 1) A screen knows how much room it needs... it has exactly 2 choices,
>>> a) use the theme, or b) use full screen.
>>> 2) with a single API call it can say "disable the theme, and setup the
>>> viewport for full screen" which does everything else needed in the
>>> background (i.e disabling the sbs updateing, etc)
>>> 3) if a screen calls _set_fullscreen without disabling the sbs then
>>> bad things will happen, doing it in 1 api call eliminates that
>>> problem.
>>>
>>> anyway.. have a open mind over this... we can argue in the morning :)
>>>
>>> Jonathan
>>>
>>
>

powermgmt-h100.c

powermgmt-h100.c

Hello,

> I looked at powermgmt-h100.c file and I am quite surprised how low cutoff voltage is set. 

Really it seems that the limit is too low. Many times I observed that the bootloader tried to load Rockbox
when the voltage was too low for the harddrive to operate. The HDD spun up and down serveral times until the
bootloader gave up.

I still have the original battery in my H120 so the internal resistance could be considerably higher in
comparison to a new battery.

Vaclav Brozik

Re: bertrik: r21416 - trunk/firmware/drivers/tuner

On Sat, 20 Jun 2009 23:34:27 +0200
mailer <at> svn.rockbox.org wrote:

> Date: 2009-06-20 23:34:27 +0200 (Sat, 20 Jun 2009)
> New Revision: 21416
> 
> Log Message:
> Fix e200v2 radio problem (missing Si4702 initialisation)

> -        /* enable the internal oscillator */
> -        si4700_write_set(TEST1, TEST1_XOSCEN);
> +        /* Enable the internal oscillator
> +          (Si4702-16 needs this register to be initialised to 0x100)
> */
> +        si4700_write_set(TEST1, TEST1_XOSCEN | 0x100);

My Si4702/03-C19 datasheet says bits 13:0 are reserved and must be
written to their pre-existing value (so we shouldn't use 0x100 mask).

Is it different on newer revisions (-16) ?

--

-- 
Rafaël Carré