Jean-Louis Biasini | 5 Feb 20:03
Picon

Re: plugins

Hello,

I also think that there should be a list with required/optional plugin. 
It would be the best way to make sure the plugins are getting correctly 
implemented regarding keymaps/manual. + This would avoid working on 
stuff that no one care about.
However, some more plugin could get into PLA. I'm working on i.
I've started on LAMP (only the manual part is missing) and will look if 
I can send some more (infortunatly I don't have much time by now)

Jean-Louis Biasini

Boris Gjenero | 4 Feb 02:17
Picon
Gravatar

PP502x cache bug and ATA DMA test build

Hello All!

I created a test build for PP502x based devices. You can download it from:
http://dl.dropbox.com/u/16662598/Rockbox/pp502x_cache_test/index.html

Using it, you can help answer the following questions:

1) Which PP502x chips are affected by the FS#12391 cache bug? Load
/pp502x_cache_test/unaltered.ipod or /pp502x_cache_test/unaltered.mi4,
run /pp502x_cache_test/pp502x_cache_test.rock and see if it reports
mismatches. If the bug is present, you should see mismatches within a
few minutes. You can find your CPU type in System -> Debug (Keep Out!)
-> View HW info.

2) If the bug is present, is the workaround reliable? Boot normally or
load /.rockbox/rockbox.ipod or /.rockbox/rockbox.mi4, and run
/pp502x_cache_test/pp502x_cache_test.rock. You shouldn't ever see
any mismatches. Run the test for a substantially longer time than what
was needed to see mismatches.

3) If the workaround is reliable, is PP502x ATA DMA stable? Use Rockbox
normally. Make sure you test database creation and functionality. You
can confirm that DMA is being used in System ->
Debug (Keep Out!) -> View disk info.

More information is available in /pp502x_cache_test/README.txt. If using
a sansac200, sansae200, gogearsa9200, gogearhdd6330 or ipodnano1g, read
the exceptions section there.

You can report your findings to me and I will summarize them here. If
(Continue reading)

Marcin Bukat | 2 Feb 21:08
Picon
Gravatar

plugins

Hello rockboxers,

Following discussion on IRC
(http://www.rockbox.org/irc/log-20120202#12:14:31) I would like to
rise the issue with current state of plugins. We have lots of this,
almost every one have separate keymap (only a few use PLA). Making
plugins to compile is tedious work during porting. In configure you
can disable all plugins but this is not a solution as usually you want
at least test_ family to compile and compiling plugins separately is a
pain. The outcome of IRC discussion is twofold:
1) Rework plugin building so it would be easy to enable particular
plugin on a given target. If someone wants particular plugin he is
welcome to provide a patch.
2) Relax the requirements for target to become stable. I mean we could
agree on minimal subset of plugins (and documentation in manual)
needed for a given port to fulfill stable criteria. Rockbox is about
playing music and not playing games and watching rotating cube after
all.

So I would like You to express your opinion.

Marcin

nappel | 2 Feb 18:22
Gravatar

Donate hardware: Trekstor i.Beat move S (2GB)

Hi guys,

I want to donate my old mp3player to the rockbox community, because the 
accumulator is flat.
It is a Trekstor i.Beat move S (2GB). If someone is interested in 
starting a port for this player please feel free to answer.

nappel

Amaury Pouly | 1 Feb 18:59
Picon
Gravatar

Radio power handling

Hi all,
While working on the fuze+ radio (which is quite picky), I ran into the mess known as our radio code and one issue in particular which is power handling. Currently our code works with something I consider problematic choice:
- a tuner API: tuner_get and tuner_set
- one power handling function: tuner_power
The problem is that tuner_get/set is handled by the driver and tuner_power is device specific but they are used as the same level. To put it differently, the power handling is completely bypassing the driver. Currently this works because for most (if not all) devices, tuner_power does not actually control the tuner power but the tuner chip enable or something similar. A corollary is that tuner_power does not reset the device and the registers.
If one looks carefully at the si4700 driver for example, it is clear that it assumes the registers are never destroyed and thus that tuner_power does not really control the power. Furthermore, nothing prevents our radio code from calling tuner_set(RADIO_TUNE,x) while "powered off" which of course makes no sense (I find the radio code complicated to follow but this is not a surprise I guess). Such a thing could be handled properly if the power state was part of the driver.

Unfortunately, I have good reasons to believe that this assumption does not hold for the fuze+ and this is problematic in two ways:
- I cannot implement tuner_power since that would destroy the register, so I would need to enable it once and let tuner_power as a stub
- but then, the generic radio code somehow relies on the fact that calling tuner_power stops the radio without calling any other driver function in some occasion (correct me if I'm wrong), which is not the case

What I am proposing is twofold:

1) Remove all direct calls to tuner_power and move them to the drivers and replace all tuner_power(ed) calls from other parts of the code by calls to tuner_set/get by introducing two new properties: RADIO_POWER(ED). So concretely tuner_power(en) -> tuner_set(RADIO_POWER, en) and tuner_powered() -> tuner_get(RADIO_POWERED).

2) In drivers like the si4700, implement tuner_set(RADIO_POWER,x) the proper way by cleanly shutting show/powering up the radio before/after calling tuner_power; thus removing the assumption that tuner_power doesn't reset the registers. For the other drivers, we could simply forward tuner_set(RADIO_POWER,x) to tuner_power.

Any opinion on that ? I already have some code written but it is not clean enough for now and I don't want to go forward if the design appears to be too problematic.

Best regards

Amaury Pouly

Magnus Holmgren | 28 Jan 13:14
Picon

libarm_support

Hi,

I don't understand why, but this line in lib/arm_support/arm_support.make breaks 
Fuze V2 builds for me:

LIBARMSUPPORT := $(BUILDDIR)/lib/libarm_support.a

(Change-Id: I34526a015357e36ffd612bf2fabf78a0354066ca)

I get this error when linking a rock:

LD credits.rock
/cyg/d/Source/C/Rockbox/rockbox/build/lib/libarm_support.a(support-arm.o): In 
function `__div0_wrap_s':
(.text+0x4): undefined reference to `__div0'
/cyg/d/Source/C/Rockbox/rockbox/build/lib/libarm_support.a(support-arm.o): In 
function `__div0_wrap':
(.text+0xc): undefined reference to `__div0'
collect2: ld returned 1 exit status
/cyg/d/Source/C/Rockbox/rockbox/apps/plugins/plugins.make:117: recipe for target 
`/cyg/d/Source/C/Rockbox/rockbox/build/apps/plugins/credits.rock' failed
make: *** [/cyg/d/Source/C/Rockbox/rockbox/build/apps/plugins/credits.rock] Error 1

Removing the above line allows the build to continue.

I'm using gcc 4.6.2 on Cygwin, in case that makes a difference.

--

-- 
   Magnus

Torne Wuff | 24 Jan 13:03
Picon
Gravatar

Code reviews now available on gerrit

Hi again everyone,

I have enabled code reviews on Gerrit. This means that you can now
upload changes for review, even if you are not a committer. We expect
that in the future, people will use this rather than uploading patches
to Flyspray. The documentation on how to do this is available at
http://www.rockbox.org/wiki/UsingGit .

The build system is building from git and appears to be working okay.
The recent changes on the website and the CIA bot are tracking git as
well.

There is still more to do, though! If you want to tackle any of the
following tasks, go for it:

1) Help to update documentation on the wiki to refer to the UsingGit
page - currently everything refers to SVN still.

2) Help to update references to SVN in the docs directory in the source.

3) Test out the process and suggest improvements to UsingGit.

4) Try your hand at writing html/css to embed into Gerrit to make it
look more like the rest of our site (see
http://gerrit.rockbox.org/r/Documentation/config-headerfooter.html for
how this works)

5) Be around on #rockbox to help people out in general with using git.

6) Anything else you can think of! (bug Torne about stuff).

--

-- 
Torne Wuff
torne <at> wolfpuppy.org.uk

asettico | 18 Jan 13:46
X-Face
Picon

Repository commits notification

Hi all,
since the change to git, I did not receive anymore the commit 
notifications. I'm still listed among the rockbox-cvs list members.
Do I need to do something to reenable them?
Thanks for any hint.
--

-- 
  ,= ,-_-. =.  asettico ~ [ http://rossomaltese.it/   ]
((_/)o o(\_)) OpenPGP ~~ [ 1024D/1CB926BA 2003-11-29 ]
  `-'(. .)`-'
      \_/

Torne Wuff | 10 Jan 00:02
Picon

We've moved to git! No more SVN!

Hi folks,

Just to let everyone know, we have now shut off commit access to the
SVN server, and enabled commit access to the Git repository hosted on
our Gerrit instance. This means that your svn checkouts are now
obsolete, and to get newer versions of Rockbox you will need to check
it out using Git.

For instructions on how to use the git server, see
http://www.rockbox.org/wiki/UsingGit which hopefully explains it well
enough :)

We are in the process of migrating the build system, the recent
changes on the website, the CIA bot on IRC, and other services to be
based on git. You should probably hold off on committing any
significant code changes until we have the build system running again
:p

The svn server is still available for read access up to the last
version committed, r31646. This will eventually go away, but remains
available for now in order to help anyone with pending changes in a
svn checkout update to the last possible point before creating a diff.

If you want to help out with the migration process, there's several
things you could do:

1) Help to update documentation on the wiki to refer to the UsingGit
page - currently everything refers to SVN still.

2) Help to update references to SVN in the docs directory in the source.

3) Test out the process and suggest improvements to UsingGit.

4) Try your hand at writing html/css to embed into Gerrit to make it
look more like the rest of our site (see
http://gerrit.rockbox.org/r/Documentation/config-headerfooter.html for
how this works)

5) Help people on #rockbox with the tools migration, if you know how
the build system/etc work.

6) Be around on #rockbox to help people out in general with using git.

7) Anything else you can think of! (bug Torne about stuff).

One thing to note is that code reviews on Gerrit are not yet enabled.
You can try this out on the sandbox repository by following the old
GerritDemoGuide instructions on the wiki; I'll turn it on on the real
repositories once we've written up some docs about how non-committers
can use it and some guidelines on how to prepare acceptable patches to
upload to it. We have enough work to be getting on with :)

Thanks to Zagor who has done all the server side work to get this
hosted on our infrastructure, thanks to everyone who contributed ideas
and comments while I was writing the docs and policies, and thanks in
advance to everyone who helps out with getting the remaining tools and
docs migrated over! Apologies for this taking so long, but I've been
really busy :p

--

-- 
Torne Wuff
torne <at> wolfpuppy.org.uk

Rafaël Carré | 8 Jan 05:02
Picon

[PATCH] usb-s3c6400: store EP info by direction

Just like is done for other drivers...
Can someone please test this on Nano2g and/or Classic 6g ?

If it works we'll be able to share more code/bugs/fixes between the
iPods and the AMSv2 !
---
 firmware/target/arm/usb-s3c6400x.c |   69 +++++++++++++++++++-----------------
 1 files changed, 36 insertions(+), 33 deletions(-)

diff --git a/firmware/target/arm/usb-s3c6400x.c b/firmware/target/arm/usb-s3c6400x.c
index 71bd127..7bcfced 100644
--- a/firmware/target/arm/usb-s3c6400x.c
+++ b/firmware/target/arm/usb-s3c6400x.c
@@ -515,7 +515,7 @@ int usb_drv_send(int ep, void *ptr, int len)
 }
 #else

-static struct ep_type endpoints[USB_NUM_ENDPOINTS];
+static struct ep_type endpoints[USB_NUM_ENDPOINTS][2];

 /* USB control requests may be up to 64 bytes in size.
    Even though we never use anything more than the 8 header bytes,
@@ -535,15 +535,15 @@ static volatile bool plugged = false;

 static void reset_endpoints(int reinit)
 {
-    unsigned int i;
-    for (i = 0; i < sizeof(endpoints)/sizeof(struct ep_type); i++)
-    {
-        if (reinit) endpoints[i].active = false;
-        endpoints[i].busy = false;
-        endpoints[i].status = -1;
-        endpoints[i].done = true;
-        semaphore_release(&endpoints[i].complete);
-    }
+    for (unsigned i = 0; i < sizeof(endpoints)/(2*sizeof(struct ep_type)); i++)
+        for (unsigned dir = 0; dir < 2; dir++)
+        {
+            if (reinit) endpoints[i][dir].active = false;
+            endpoints[i][dir].busy = false;
+            endpoints[i][dir].status = -1;
+            endpoints[i][dir].done = true;
+            semaphore_release(&endpoints[i][dir].complete);
+        }

     DEPCTL(0, false) = DEPCTL_usbactep | (1 << DEPCTL_nextep_bitp);
     DEPCTL(0, true) = DEPCTL_usbactep;
@@ -575,26 +575,28 @@ static void reset_endpoints(int reinit)
 int usb_drv_request_endpoint(int type, int dir)
 {
     bool out = dir == USB_DIR_OUT;
-    for(size_t ep = out ? 2 : 1; ep < USB_NUM_ENDPOINTS; ep += 2)
-        if (!endpoints[ep].active)
+    for(size_t ep = out ? 2 : 1; ep < USB_NUM_ENDPOINTS; ep += 2) {
+        if (!endpoints[ep][out ? DIR_OUT : DIR_IN].active)
         {
-            endpoints[ep].active = true;
+            endpoints[ep][out ? DIR_OUT : DIR_IN].active = true;
             DEPCTL(ep, out) = (DEPCTL(ep, out) & ~(DEPCTL_eptype_bits << DEPCTL_eptype_bitp)) |
                 (type << DEPCTL_eptype_bitp);
             return ep | dir;
         }
+    }

     return -1;
 }

 void usb_drv_release_endpoint(int ep)
 {
+    bool out = !(ep & USB_DIR_IN);
     ep = ep & 0x7f;

     if (ep < 1 || ep > USB_NUM_ENDPOINTS)
         return;

-    endpoints[ep].active = false;
+    endpoints[ep][out ? DIR_OUT : DIR_IN].active = false;
 }

 static void usb_reset(void)
@@ -646,14 +648,14 @@ static void handle_ep_int(bool out)
         {
             if (!out) inflight = false;
             commit_discard_dcache();
-            int bytes = endpoints[ep].size - (DEPTSIZ(ep, out) & (DEPTSIZ_xfersize_bits < DEPTSIZ_xfersize_bitp));
-            if (endpoints[ep].busy)
+            int bytes = endpoints[ep][out ? DIR_OUT : DIR_IN].size - (DEPTSIZ(ep, out) & (DEPTSIZ_xfersize_bits < DEPTSIZ_xfersize_bitp));
+            if (endpoints[ep][out ? DIR_OUT : DIR_IN].busy)
             {
-                endpoints[ep].busy = false;
-                endpoints[ep].status = 0;
-                endpoints[ep].done = true;
+                endpoints[ep][out ? DIR_OUT : DIR_IN].busy = false;
+                endpoints[ep][out ? DIR_OUT : DIR_IN].status = 0;
+                endpoints[ep][out ? DIR_OUT : DIR_IN].done = true;
                 usb_core_transfer_complete(ep, out ? USB_DIR_OUT : USB_DIR_IN, 0, bytes);
-                semaphore_release(&endpoints[ep].complete);
+                semaphore_release(&endpoints[ep][out ? DIR_OUT : DIR_IN].complete);
             }
         }

@@ -662,12 +664,12 @@ static void handle_ep_int(bool out)

         if (!out && (epints & DIEPINT_timeout))
         {
-            if (endpoints[ep].busy)
+            if (endpoints[ep][out ? DIR_OUT : DIR_IN].busy)
             {
-                endpoints[ep].busy = false;
-                endpoints[ep].status = 1;
-                endpoints[ep].done = true;
-                semaphore_release(&endpoints[ep].complete);
+                endpoints[ep][out ? DIR_OUT : DIR_IN].busy = false;
+                endpoints[ep][out ? DIR_OUT : DIR_IN].status = 1;
+                endpoints[ep][out ? DIR_OUT : DIR_IN].done = true;
+                semaphore_release(&endpoints[ep][out ? DIR_OUT : DIR_IN].complete);
             }
         }

@@ -735,8 +737,8 @@ static void ep_transfer(int ep, void *ptr, int len, bool out)
     /* disable interrupts to avoid any race */
     int oldlevel = disable_irq_save();
     if (!out) inflight = true;
-    endpoints[ep].busy = true;
-    endpoints[ep].size = len;
+    endpoints[ep][out ? DIR_OUT : DIR_IN].busy = true;
+    endpoints[ep][out ? DIR_OUT : DIR_IN].size = len;

     if (out) DEPCTL(ep, out) &= ~DEPCTL_stall;

@@ -762,11 +764,11 @@ static void ep_transfer(int ep, void *ptr, int len, bool out)
 int usb_drv_send(int endpoint, void *ptr, int length)
 {
     endpoint = EP_NUM(endpoint);
-    endpoints[endpoint].done = false;
+    endpoints[endpoint][1].done = false;
     ep_transfer(endpoint, ptr, length, false);
-    while (!endpoints[endpoint].done && endpoints[endpoint].busy)
-        semaphore_wait(&endpoints[endpoint].complete, TIMEOUT_BLOCK);
-    return endpoints[endpoint].status;
+    while (!endpoints[endpoint][1].done && endpoints[endpoint][1].busy)
+        semaphore_wait(&endpoints[endpoint][1].complete, TIMEOUT_BLOCK);
+    return endpoints[endpoint][1].status;
 }

 void usb_drv_cancel_all_transfers(void)
@@ -778,8 +780,9 @@ void usb_drv_cancel_all_transfers(void)

 void usb_drv_init(void)
 {
-    for (unsigned i = 0; i < sizeof(endpoints)/sizeof(struct ep_type); i++)
-        semaphore_init(&endpoints[i].complete, 1, 0);
+    for (unsigned i = 0; i < sizeof(endpoints)/(2*sizeof(struct ep_type)); i++)
+        for (unsigned dir = 0; dir < 2; dir++)
+            semaphore_init(&endpoints[i][dir].complete, 1, 0);

     /* Enable USB clock */
 #if CONFIG_CPU==S5L8701
--

-- 
1.7.7.3

Al Le | 7 Jan 09:48
Picon
Picon

rbutil/rbutilqt/base/encoderbase.h, r31595

Just nitpicking, but shouldn't the comment read "Child class should 
commit __the__ SettingsList to permanent storage"? I.e. with r31595, not 
"the" but rather "from" should have been removed.


Gmane