Rockbox Development > New Ports

SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

<< < (279/386) > >>

FlynDice:
@funman:

I have flashed my clip+ with the unmodified dualboot.S code.  It seems to work just fine but there does not seem to be a any extra delay in addition to the boot time for an unpatched firmware(as it appeared there should be from looking at dualboot.S).  I tried upping the delay value from 0x500000 to 0x5000000 & 0x50000000  with no difference in the results.  Looking closer now and scratching my head.  Am I being a bit too paranoid do you suppose? ???


Edit:
After looking through the code more closely I still think I should be seeing a delay with the patched firmware in relation to the unpatched and I do not.  After I copy the newly patched firmware file to my clip+ it does do the upgrading firmware routine.  And when I turn it back on it starts up asking for settings like it normally does after a firmware upgrade.  However, there is no added delay when booting.  In all cases there is about a 1 sec lag between pushing the power switch and seeing the OF splash start up.  This leads me to believe that the delay code(5 sec in SVN & much more in my modified) in dualboot.S is somehow not running.

Here are the steps I used to produce my patched firmware:
- I built a clipv2 bootloader (I don't really think this matters as I'm not running actual rockbox code yet....)
- I used scramble -add=cli+  to produce bootloader-cli+.sansa
- I modified mkamsboot to work for clip+(just removing the #if (0)) and built it.
- I ran mkamsboot to produce patched firmware named Rclppa.bin
- I loaded the patched firmware on the clip+ and renamed to clppa.bin
- After seeing no delay the first time, I modified dualboot.S to try to increase the delay but was not successful.

Here is the diff and console output that I saw.       http://pastie.org/807886

The patched firmware that I used seemed to work identically to the unpatched. 

mc2739:
@FlynDice

Check your forum PMs

FlynDice:
@ mc2739:

You got it exactly right Thanks!!!!   ;D

I still had to modify the delay as the 0x500000 only delayed about .5 secs and was not very obvious.  I wonder if this means the processor is being clocked a lot higher?  We'll see!



EDIT:

I'm attaching a .pdf with my results for GPIOA.  I've got to figure out where to go from here so If someone has an idea please speak up. 

I would find it odd if this wasn't a keyscan type thing similar to the clip & clipv2 but I can't make it fit together in my head just yet.  Moving on to GPIOB,C,D with the same code does not seem logical to me.

EDIT:

Just went back & found funman's post with some hints --> http://forums.rockbox.org/index.php?topic=14064.msg160803#msg160803

EDIT:

I've found all of the buttons except pwr now.  There is no hold button.  The OF implements the hold function with a long home press.
New .pdf attached.

EDIT:

I now have Dualboot working with left button.  No Rockbox code yet, just a delay to simulate branching to rockbox.

funman:
good job!

Did you forget to update dualboot.c / dualboot.h when the delay wasn't changed?

I have one remark before you commit your diff:

You should find the USB pin: I see that the OF writes GPIOB before reading buttons, if you skip this step reading the left button might just not work on some specific Clip+.

That's the same process than checking buttons, you can add the check after checking for left button since you know it works on your Clip+.
EDIT: only add the check after left button in your test build, once you found the USB pin it should be the first check (as it is in dualboot.S) as I believe it's much less likely to fail than a button check.


Once it's done you should commit it, so you can start LCD code and maybe be helped by others :)

I'll look at making the Clip+ bootloader target build

funman:
Just found this on google.

In the first post:

--- Quote ---WARNING: drivers/usb/host/as352xhcd.o(.text+0x2be0)
--- End quote ---

In the third post:

--- Quote ---AS353X NAND Driver, (c) 2010 austriamicrosystems
--- End quote ---

And a bit more down:

--- Quote ---insmod /lib/modules/2.6.28.4-as353x-patch-svn1406/kernel/drivers/usb/gadget/dwc_otg/dwc_otg.ko
dwc_otg: version 2.60a 05-JUN-2009
...
dwc_otg: Detected: Synopsys DWC OTG 2.60a Core
--- End quote ---

If one of you can write chinese and feel like asking them where they got their linux sources and if they are willing to share, perhaps we could find some SD code!

Note we already have the source for dwc_otg (link on the SansaAMS page)

Navigation

[0] Message Index

[#] Next page

[*] Previous page