ipodlinux-devel

[Ipodlinux-devel] dead ipod?

[Steven L. <sl...@uc...>]

hello everybody,

i've run into some serious trouble here, and i'm wondering if anyone can
help.  it appears that the third requirement on the build page, "No
reservations about the possibility of ruining your iPod. This would likely
invalidate your warranty as well. You have been warned!" is not joking.  my
ipod is now, effectively, a very shiny brick.

symptoms:  that of a brick, except shiny.  won't turn on, won't respond to
button pushes, firewire attaches, holding play/menu down, or anything else.
i have not busted it open to try unplugging/replugging battery, i'm hoping
someone here can suggest something a little less dangerous first.

what i can reconstruct:  i wasn't really paying much attention (as i didn't
expect this to happen), but as far as i can here is what steps preceded this
lock-up:  i booted the ipod into linux and forgot about it.  this caused the
battery to run down.  no problem -- hooked it up via firewire, forced reboot
with play/menu and then forced fw with ff/rew.  dded in apple's firmware
image, which, due to my flaky firewire hardware, crashed my computer.
rebooted my computer, tried dding it again, this time it worked.  rebooted
ipod into playing mode (by unplugging firewire).  i didn't actually play any
songs, but it booted into the menuing system just fine.  plugged fw back in,
and it rebooted into charging mode (with the check mark).  i now left it
alone for two days, and then when i went to unplug it to take on my trip it
was absolutely dead.  it's been this way for a week, and i'm still very
puzzled.  any help about reviving it would be appreciated.

thanks, and may this never happen to you,

Steven

Re: [Ipodlinux-devel] ipod from ppc doesn't boot

[Steven L. <sl...@uc...>]

On Wed, Apr 02, 2003 at 11:53:44PM +0100, Florin Boariu <fl...@bn...> said
> (thanks, steven, for pointing me to those :-)

np:-p

> perhaps someone could send me one of his kernel files, so i can patch my 
> firmware with those? this way i can test whether the problem is the way 
> my ipod-kernel was compiled.

you can get kernel images (objcopied and all ready for patching) from the sf
download area, http://sourceforge.net/project/showfiles.php?group_id=73079

> oh, there is some information which might be important: ipod has (had) 
> firmware 1.20, and is the old 5GB-model (old _real_ scrolling wheel, no 
> touchpad, no remote control).

this is the model and firmware i've been using, so that shouldn't be the
problem.

Steven

[Ipodlinux-devel] ipod from ppc doesn't boot

[Florin B. <fl...@bn...>]

hello everybody!

i turned my mac-ipod into a win-ipod like described in the gnupod docs 
(thanks, steven, for pointing me to those :-)

i build the kernel and patched it like steven described it in his email, 
copied the (patched) firmware to the first partition of the ipod and 
reset it -- several times. tried it with firewire plugged in and 
unplugged, but it doesn't boot. i can get it to disk-mode by hand (press 
forward+rewind), so i can re-copy the original firmware (then, of 
course, it works again).

it seems to stuck with that apple-logo. i can hear the hdd spinning, but 
no attempts to read from it whatsoever... anybody any ides?

perhaps someone could send me one of his kernel files, so i can patch my 
firmware with those? this way i can test whether the problem is the way 
my ipod-kernel was compiled.

oh, there is some information which might be important: ipod has (had) 
firmware 1.20, and is the old 5GB-model (old _real_ scrolling wheel, no 
touchpad, no remote control).

what about others?

regards,
florin.

Re: [Ipodlinux-devel] ppc ipod questions

[Steven L. <sl...@uc...>]

On Wed, Apr 02, 2003 at 01:47:01AM +0200, Florin Boariu <fl...@bn...> said
> my question is: what about partitioning? mac ipods have a different 
> partitioning. do i have to repartition my ipod to match the win-ipod 
> version?
> 
> and if i do: are there any restrictions about partition sizes, layouts 
> etc? or is it sufficient if i make a firmware partition of ~35 megs and 
> split the rest of the disk into different partitions?

download gnupod (it's homepage is on gnu's site).  the documentation includes
detailed instructions on  how to switch between 'mac' and 'win' ipods,
including partitioning (note that mac partitions are different than pc
partitions, and, indeed, the ipod even has a different number of partitions
depending on its winness or it's macness).  in short, i'd recommend
'converting' it to a win ipod for development purposes -- you can always
revert it back with apple's tool (converting either way requires reformatting
and thus wipes all data, so back up).

Steven

Re: [Ipodlinux-devel] ppc ipod questions

[Bernard L. <le...@bo...>]

Hi again,

I'm not 100% sure about the partition on the iPod, I haven't
experiemented that much (infact I'm just using the standard layout on my
win iPod).  I imagine the bootloader is quite sensitive to changes in
the partitioning.  I believe however that if "data" partition for a mac
iPod is converted from HFS+ to FAT32 it will still work with iTunes and
the Apple firmware.  Can anyone confirm that?

Anyhow except for experimentation I would suggest leaving the partitions
as they are currently.  Until an alternate usable firmware is available
being able to revert to the Apple firmware is very useful (required for
me!).  In the long run using an ext3 filesystem might be interesting to
get better usage of the available disk space.

Regarding the power-off situation the only real danger is is the reset
function of the iPod.  The lower battery power situation should be easy
enough to handle (eventually :) by the kernel.

cheers,
bern.

On Wed, 2003-04-02 at 01:47, Florin Boariu wrote:
> hello everybody!
> 
> i finally managed to build a toolchain for arm (arm-uclinux), compile 
> the kernel with patches for build from ppc (as described by steven in 
> his email), patch the firmware etc.
> 
> my question is: what about partitioning? mac ipods have a different 
> partitioning. do i have to repartition my ipod to match the win-ipod 
> version?
> 
> and if i do: are there any restrictions about partition sizes, layouts 
> etc? or is it sufficient if i make a firmware partition of ~35 megs and 
> split the rest of the disk into different partitions?
> 
> i'm asking because... well, since i'm going to destroy my mp3 collection 
> anyway (or maybe not -- i could do a dd from my 3rd partition [data 
> partition on an mac-ipod] and mount it read-only via loopback to get 
> back my data -- there is a HFS+ filesystem patch somewhere around the 
> net which seems to work well in ro-mode :-) i'd like to change 
> partitionig scheme. i want my ipod to have different partitions, i.e. 
> for / /var and /home/music. / and /home/music could be mounted read-only 
> (i assume ipod-linux will be just as upset about power-off while system 
> is running as any other linux) and only mount a small partition (about 
> 200 MB?) rw, for files that need to be accessed rw access while system 
> is running (like several log files, and maybe some address books...)
> 
> best regards,
> florin (with a strong desire to irrecoverably destroy his ipod).
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: 
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> iPodlinux-devel mailing list
> iPo...@li...
> https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel
> 

Re: [Fwd: Re: [Ipodlinux-devel] hello]

[Bernard L. <le...@bo...>]

Hi Florin,

The major problem with the frame buffer for the iPod is that it doesn't
provide linear addressable display memory.  As I understand it, most of
these libraries will mmap() the frame buffer and then write directly to
display memory.  Unfortunately on the iPod that won't work becuase the
display memory is in the LCD and therefore not directly accessible.

The framebuffer keeps an in-memory copy of the memory and then writes
any updates to the LCD.  It would be possible to have an update thread
that continually re-writes the data to the LCD so that the mmap() type
approach would work.  I'm not sure how cpu intesive this would be.

Alternatively with a package like Microwindows you can write a
Microwindows driver that forms an interface between its drawing routines
and the display hardware.

Regarding an actual interface - the directory structure sounds like a
good place to start.  That should be doable using the current display
driver using something like ncurses.  Any takers?

cheers,
bern.

On Mon, 2003-03-31 at 12:30, Florin Boariu wrote:
> From: Florin Boariu <fl...@bn...>
> To: Bernard Leach <le...@bo...>
> Subject: Re: [Ipodlinux-devel] hello
> Date: 31 Mar 2003 11:31:19 +0200
> 
> > To answer your second question first, work is on-going on the project. 
> > I'm still trying to get hardware support into the kernel for all the
> > iPod devices.  I'm getting there but its slow going.  Currently I am
> > working on the power management aspects to see what I can do about
> > limiting battery usage.
> 
> great to hear -- i browsed through the ml archive yesterday and realized 
> myself that there was a lot going on :-)
> 
> > Other than the kernel work the biggist missing part is a GUI.  I had
> > thought to use Microwindows (since its already part of the uClinux build
> > tree).  I custom display driver needs to be written so to allow
> > Microwindows to use the iPod display.  The driver could be based on the
> > current framebuffer so it shouldn't be too hard.
> 
> whay about DirectFB? it seems to be a pretty good fbdev graphics library 
> with hardware support for a lot of things (which of course won't be of 
> any use on the ipod) and software fallbacks for all they have :-)
> 
> i had some thoughts on the topic "GUI": maybe a simple but efficient way 
> would be to implement some sort of directory browser with ... aehm "file 
> handles" for different types of files. MP3/OGGs could be direcly 
> inserted into a play queue (that's what i miss on my current ipod -- the 
> possibility to dynamically create playlists / play queues), iTunes or 
> XMMS playlists could be played directly, several text files in plain 
> ASCII (or even XML) format could be treated appropriately (GNUpod 
> playlists could be played, several address and/or diary formats could be 
> displayed etc).
> 
> this allows simple building of menu systems by just creating directories :-)
> 
> i had some thoughts on text imput, maybe based on some (intelligent?) 
> dictionary files and auto-completion. a typical while typing would look 
> like:
> 
>    o find an edit field
>    o start with letter 'a' as first letter of the word. the system
>      auto-completes the most appropriate word starting with 'a'
>    o if you don't want the word to start with 'a', just scroll to the
>      desired letter as first letter of the word. the system constantly
>      auto-completes the possible words to type (starting with 'b', 'c',
>      whatever.
>    o advance to the second letter (for example by pressing the
>      "fast-forward" key. scroll that one to the desired shape
>      (with system constantly auto-completing).
>    o when you're happy, press some enter button (for example "play").
> 
> this certainly won't be as good as a keyboard, but maybe it could be 
> somewhat usable if only the dictionary files are good enough 
> (menu-sensitive dictionary files: look up in name data bases while 
> typing addresses, look up in PATH while typing in a shell, look up in 
> playlists while typing songs etc...)
> 
> what do you think?
> 
> regards,
> florin.
> 

[Ipodlinux-devel] ppc ipod questions

[Florin B. <fl...@bn...>]

hello everybody!

i finally managed to build a toolchain for arm (arm-uclinux), compile 
the kernel with patches for build from ppc (as described by steven in 
his email), patch the firmware etc.

my question is: what about partitioning? mac ipods have a different 
partitioning. do i have to repartition my ipod to match the win-ipod 
version?

and if i do: are there any restrictions about partition sizes, layouts 
etc? or is it sufficient if i make a firmware partition of ~35 megs and 
split the rest of the disk into different partitions?

i'm asking because... well, since i'm going to destroy my mp3 collection 
anyway (or maybe not -- i could do a dd from my 3rd partition [data 
partition on an mac-ipod] and mount it read-only via loopback to get 
back my data -- there is a HFS+ filesystem patch somewhere around the 
net which seems to work well in ro-mode :-) i'd like to change 
partitionig scheme. i want my ipod to have different partitions, i.e. 
for / /var and /home/music. / and /home/music could be mounted read-only 
(i assume ipod-linux will be just as upset about power-off while system 
is running as any other linux) and only mount a small partition (about 
200 MB?) rw, for files that need to be accessed rw access while system 
is running (like several log files, and maybe some address books...)

best regards,
florin (with a strong desire to irrecoverably destroy his ipod).

Re: [Ipodlinux-devel] hello

[Carlos <ca...@pe...>]

El lun, 31 de 03 de 2003 a las 10:37, Bernard Leach escribi=F3:
> Hi Florin,
>=20

Hi people

> To answer your second question first, work is on-going on the project.=20
> I'm still trying to get hardware support into the kernel for all the
> iPod devices.  I'm getting there but its slow going.  Currently I am
> working on the power management aspects to see what I can do about
> limiting battery usage.

And you are doing a really amazing work, thanks!!!

>=20
> Regarding the Ogg playback, sofar I haven't tried to optimise it and no
> experts in this area have come forward with any suggestions on how to do
> it!  Just last week there was comment on the Tremor mailing list about
> some updates - I'm hoping that their next release will have some
> speed-ups.
>=20
> Other than the kernel work the biggist missing part is a GUI.  I had
> thought to use Microwindows (since its already part of the uClinux build
> tree).  I custom display driver needs to be written so to allow
> Microwindows to use the iPod display.  The driver could be based on the
> current framebuffer so it shouldn't be too hard.
>=20
> On that front I'd be interested to hear from any graphically minded
> people what the GUI could look like...

And what about using the framebuffer gtk2?

I think it only needs a framebuffer driver and don't need any additional
driver.

I was thinking on develop a GUI with gtk2 so we could also test it with
Linux && X as a normal application and just recompile it with
framebuffer support and put it inside iPod.


The web project is: http://www.directfb.org/gtk.xml

>=20
> cheers,
> bern.

Cheers and thanks for all your work bern.
>=20
> On Sun, 2003-03-30 at 15:28, Florin Boariu wrote:
> > hi everyone!
> >=20
> > this project sounds very interesting -- i own an ipod (mac version) and=
=20
> > an ibook, running both os 9.2 and linux.
> >=20
> > i'm very interested in running linux on my ipod, for two reasons:
> >=20
> > (1) the possibility of playing OGG files. i read on the website that=20
> > it's almost possible (80% realtime). any chances in the near future of=20
> > that becoming real-time?
> >=20
> > (2) the possibility to change my ipod's behavior. ipod has some really=20
> > nice features, but it would be simply great to be able to change those.
> >=20
> > as i understand from your website, there is some work to be done in the=
=20
> > area of drivers and GUI.
> >=20
> > as soon as i get home i'll try to reproduce the work as described on th=
e=20
> > website (that is making the linux kernel boot).
> >=20
> > is there at the time being any serious effort to make the ipod usable=20
> > with linux, or is work more or less stalled?
> >=20
> > i'm familiar with c/c++, and i also wrote some linux character devices=20
> > (mainly for big CCD cams). i'm aware that this might not be enough to=20
> > undestand all implications of the ipod/linux hack, but i'm learning fas=
t :-)
> >=20
> > is there anything special i can attempt?
> >=20
> > regards,
> > florin.
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > iPodlinux-devel mailing list
> > iPo...@li...
> > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel
> >=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:=20
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> iPodlinux-devel mailing list
> iPo...@li...
> https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel
--=20
Carlos Perell=F3 Mar=EDn
Debian GNU/Linux Sid (PowerPC)
Linux Registered User #121232
mailto:ca...@pe... || mailto:ca...@gn...
http://carlos.pemas.net
Valencia - Spain

Re: [Ipodlinux-devel] hello

[Bernard L. <le...@bo...>]

Hi Florin,

To answer your second question first, work is on-going on the project. 
I'm still trying to get hardware support into the kernel for all the
iPod devices.  I'm getting there but its slow going.  Currently I am
working on the power management aspects to see what I can do about
limiting battery usage.

Regarding the Ogg playback, sofar I haven't tried to optimise it and no
experts in this area have come forward with any suggestions on how to do
it!  Just last week there was comment on the Tremor mailing list about
some updates - I'm hoping that their next release will have some
speed-ups.

Other than the kernel work the biggist missing part is a GUI.  I had
thought to use Microwindows (since its already part of the uClinux build
tree).  I custom display driver needs to be written so to allow
Microwindows to use the iPod display.  The driver could be based on the
current framebuffer so it shouldn't be too hard.

On that front I'd be interested to hear from any graphically minded
people what the GUI could look like...

cheers,
bern.

On Sun, 2003-03-30 at 15:28, Florin Boariu wrote:
> hi everyone!
> 
> this project sounds very interesting -- i own an ipod (mac version) and 
> an ibook, running both os 9.2 and linux.
> 
> i'm very interested in running linux on my ipod, for two reasons:
> 
> (1) the possibility of playing OGG files. i read on the website that 
> it's almost possible (80% realtime). any chances in the near future of 
> that becoming real-time?
> 
> (2) the possibility to change my ipod's behavior. ipod has some really 
> nice features, but it would be simply great to be able to change those.
> 
> as i understand from your website, there is some work to be done in the 
> area of drivers and GUI.
> 
> as soon as i get home i'll try to reproduce the work as described on the 
> website (that is making the linux kernel boot).
> 
> is there at the time being any serious effort to make the ipod usable 
> with linux, or is work more or less stalled?
> 
> i'm familiar with c/c++, and i also wrote some linux character devices 
> (mainly for big CCD cams). i'm aware that this might not be enough to 
> undestand all implications of the ipod/linux hack, but i'm learning fast :-)
> 
> is there anything special i can attempt?
> 
> regards,
> florin.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> iPodlinux-devel mailing list
> iPo...@li...
> https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel
> 

[Ipodlinux-devel] hello

[Florin B. <fl...@bn...>]

hi everyone!

this project sounds very interesting -- i own an ipod (mac version) and 
an ibook, running both os 9.2 and linux.

i'm very interested in running linux on my ipod, for two reasons:

(1) the possibility of playing OGG files. i read on the website that 
it's almost possible (80% realtime). any chances in the near future of 
that becoming real-time?

(2) the possibility to change my ipod's behavior. ipod has some really 
nice features, but it would be simply great to be able to change those.

as i understand from your website, there is some work to be done in the 
area of drivers and GUI.

as soon as i get home i'll try to reproduce the work as described on the 
website (that is making the linux kernel boot).

is there at the time being any serious effort to make the ipod usable 
with linux, or is work more or less stalled?

i'm familiar with c/c++, and i also wrote some linux character devices 
(mainly for big CCD cams). i'm aware that this might not be enough to 
undestand all implications of the ipod/linux hack, but i'm learning fast :-)

is there anything special i can attempt?

regards,
florin.

[Ipodlinux-devel] New release now available

[Bernard L. <le...@bo...>]

Hi all,

I've just uploaded a new release to the website.  The kernel patch is
based on the lastest CVS version and so includes the recent updates to
include serial support and the line dicipline driver for the remote
control.  The release also includes a working firewire driver (the
previous patch I believe was missing some pieces!).

In addition to the patch I have also uploaded kernel binaries (both the
"win" and "mac" versions) but more importantly a new root filesystem
archive.  This new filesystem boots the iPod with ethernet support
running so that it can be quickly connected to the host via telnet.  I
will endevour to get some documentation online as to how all this works
soon (unless there are any volunteers!).

For those that can do some testing I'd be appreciative of any feedback
on this update.

cheers,
bern.

[Ipodlinux-devel] Fast audio decoders

[Dan C. <da...@da...>]

Hi,

I don't have an iPod myself, but nonetheless I find your project 
interesting. While scouring the web, and the Hydrogen Audio forums in 
particular, I found a couple of interesting links:

"Embedded Decoder Brings Hardware Support For MPC!"
http://www.hydrogenaudio.org/index.php?s=&act=ST&f=2&t=4094

"RAM optmize version of Tremor for ARM"
http://www.hydrogenaudio.org/index.php?act=ST&f=9&t=6975

MPC is an audio codec which supposedly offers the best quality at 
relatively high bit rate (should be transparent at 160-170kbps). I 
believe you know what Tremor is ;) You should also take a look at FAAD. 
On my slow iMac with it's slow FPU, it uses significantly less CPU for 
decoding than any of the MP3 decoders. It just might be fast enough for 
the iPod :)

I hope you find this useful.

- Dan

Re: [Ipodlinux-devel] status update 17.02.03

[<arm...@ya...>]

Hi Bernard,

If the ipp code is structured in a way that would allow it, the best
split between cpus for mp3 decoding might be to have the co-processor
do subband synthesis and audio output and have the main cpu do
everything else.

(Subband synthesis is the final step in mp3 decoding, to transform
uncompressed frequency domain data to uncompressed time domain data.
It should be fairly well de-coupled from the rest of the decoder).

This is going back towards a system where the cop runs only the audio
output driver, except that now the audio output driver contains the
final stage of the mp3 decoding (which just happens to require approx
50 % of the cpu bandwidth). If fast SRAM is big enough to hold the
synthesis code + synthesis working buffer + some buffered audio data
on its way to the DAC, then you should get almost double the
throughput of a single cpu.

Andre
--





__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: [Ipodlinux-devel] status update 17.02.03

[Bernard L. <le...@bo...>]

Hi Chandan,

Not sure if you got to do any experimentation, but I've just tried what
you were suggesting.

First up I reverted to just using a single cpu to drive the audio.  The
results were (using the mp3example) a noticible slowdown.

The second experiment was to put some of the ipp code into the fast ram
and try that.  This turned out to be a little harder than first hoped
(since I don't have the source code to that).  Anyhow with those changes
the performance was back up to near real-time.  It is definitely less
than the original cpu-cop version but this version is only using one
processor!

My current feeling is that using this cpu-only audio driver is the right
way to go (and then to use the cop as a decoding unit..?).  Or at least
using the internal ram for buffering is a big waste.  I suppose a
cpu-cop driver using sdram and cache flushing would be one more
experiment there...

I'll see about getting the audio driver into CVS so it can be compiled
as either.

The mp3example program on the other hand is a bit of a nightmare!  To
get this to work I compiled up a dummy program that called the functions
to relocate and compiled it to 0x40000000.  This program is then copied
to the right location and then stubs are used to call to the right
spot.  Does anyone have any suggestions as to how this could be
simplified?

cheers,
bern.

On Tue, 2003-03-04 at 16:04, Chandan Kudige [home] wrote:
> In the current implementation of cop code, everytime an application
> tries to write more than one frame of data to the /dev/dsp, it will be
> put to sleep as long as the kernel keeps feeding this data to the cop
> (I think the shared SRAM is 92K only)
> 
> One way to handle this would be to implement a kernel thread which would
> take the user data and keeps feeding to the cop. This thread would be
> sleep most of the time, and the user program can continue its execution
> in parallel. I still havent tried this out.
> 
> Intel's mp3player writes one frame at a time and hence does not incur
> this waiting. But I can verify by playing it to /dev/null just to be
> sure.
> 
> So if we can do away with the cop and write to the audio in the main
> processor we can still follow this approach so that we do not tie up the
> user process. We can still move the decoding routine into the SRAM (I
> would assume that 92K should be more than enough!).
> 
> I can give this a try over the weekend.
> 
> -Chandan
> 
> On Tue, 2003-03-04 at 03:44, Andre wrote:
> > Bernard Leach <le...@bo...> wrote:
> > > 
> > > An extension of that would be to then put the decoding routines
> > > in fast ram (since we wouldnt be using it as the buffer).
> > > I'm not sure how big a win this would be but it is how the real
> > > firmware works...
> > > 
> > 
> > My guess is that this will be a _big_ win. The internal SRAM is
> > likely to be 32bit wide, with low (probably zero) wait-states when
> > accessed from the ARM.
> > 
> > The system SDRAM on the other hand (Samsung part No. K4S561632 ??) is
> > 16bit wide, has the overhead of refreshes etc and is probably clocked
> > slower as well (anyone with an open ipod and a 'scope handy, please
> > put a probe on pin 38 of the SDRAM chip and let us know for sure...
> > :-).
> > 
> > The most important code in madplay to speed up is the imdct36
> > assembler function and the contents of synth.c. The later may take a
> > bit more work, but the former is fully PIC so a quick and dirty test
> > would be to hack madplay to memcpy the whole of III_imdct_l into fast
> > SRAM at program startup and then call it from there via a function
> > pointer (its only called from 2 places in layer3.c).
> > 
> > How big is the internal SRAM by the way ???
> > 
> > Andre
> > --
> > 
> > 
> > 
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Everything you'll ever need on one web page
> > from News and Sport to Email and Music Charts
> > http://uk.my.yahoo.com
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> > for complex code. Debugging C/C++ programs can leave you feeling lost and 
> > disoriented. TotalView can help you find your way. Available on major UNIX 
> > and Linux platforms. Try it free. www.etnus.com
> > _______________________________________________
> > iPodlinux-devel mailing list
> > iPo...@li...
> > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel
> > 
> 
> 

[Ipodlinux-devel] working kernel from ppc

[Steven L. <sl...@uc...>]

hello,

here is a list of hacks that i had to do to build a kernel for the ipod on my
ppc.  i hope this helps other people, and hopefully some of it will get
generalized into the main release.

1) get version 1.1 of the patch_fw.c which supports big endian machines

2) get cvs module 'toolchain' from cvs.uclibc.org:/var/cvs.  cd to gcc-2.95,
edit Makefile accordingly, and 'make'.  gcc-3.2.1 does not work (it makes a
bogus kernel).  after a long time this will give you compiler/toolchain and
uclibc.  add (installation dir)/bin to your PATH.

3) unpack 2.4.20 kernel, apply uClinux-2.4.20-uc0.diff.gz, cvs co the
ipodlinux stuff (directions on site).  make sure when you cvs co you remove
the files it doesn't want to overwrite so that it overwrites them:-p

4) edit kernel Makefile.  line 28:  set CROSS_COMPILE to 'arm-uclibc-'.  line
39, set LD = $(CROSS_COMPILE)ld --no-warn-mismatch'.

5) drivers/char/keyboard.c +287 -- whoever wrote this is on something
illegal.  just comment out the whole bit (!define() is not defined,
console_tasklet is not defined...) from before the #ifdef to after the
#endif.

6)  arch/armnommu/kernel/setup.c +418 -- this should read '__initdata' where
it now reads '__init'.

7) now we can cp the ipod def-config to .config, make oldconfig, and make
dep.  then make, make modules.  might wanna add the appropriate
CONFIG_IEEE1394*=m lines to .config first, though.

8) follow instructions on site for backing up, patching, and installing
firmware.  my ipod boots:)  my friend has replicated this.

9) somehow get umsdos to /work/.  still on this step.

note insmod sbp2 sbp2_max_speed=0 helped a lot to reduce crashes while dding,
and is still 100megs/sec (faster than the disk in the 'pod by far).

hope this is of help, feel free to ask me any questions.

Steven

Re: [Ipodlinux-devel] serial drivers (remote control and piezo)

[Mark G. <ge...@ge...>]

On March 13, 2003 05:49 pm, Bernard Leach wrote:
> Now does anyone know of a portable serial keyboard that works with only
> a TX line? :)

hehehe I was thinking the same thing :)

Gerk

[Ipodlinux-devel] serial drivers (remote control and piezo)

[Bernard L. <le...@bo...>]

Hi all,

Seems I was a little hasty with the latest patch.  Today I had a look at
building the serial drivers to try out the remote control and the
piezo.  After about 1/2 of reading and 1/2 testing I had something
working!  This is why I really like Linux!

Anyhow I've just checked into CVS the code to get the serial ports
working.

/dev/ttyS0 is the remote control.  if you type "stty -F /dev/ttyS0 raw"
and then "cat /dev/ttyS0" and then press a button on the remote control
you should see output.

The data appears as so:

0xff 0xfd 0xf1 0x00
and repeats until you release the key
when you get
0xff 0xfd 0xf0 0x00

the 0xf1 part varies on the key pressed.
0xf1 -> play/pause
0xf2 -> volume up
0xf3 -> volume down
0xf4 -> fast foward
0xf5 -> rewind

You can't write to this this serial port and expect anything good to
come from it.

/dev/ttyS1 is connected to the piezo.
dd if=/dev/zero of=/dev/ttyS0 count=10 bs=1
should produce some noise.
if=/dev/urandom should produce a different noise.

stty -F /dev/ttyS1 speed 19200
will also change the noise.

Now does anyone know of a portable serial keyboard that works with only
a TX line? :)

enjoy,
bern.

Re: [Ipodlinux-devel] updated kernel patch available

[Bernard L. <le...@bo...>]

Hi Chandan,

I'm not having any trouble running multiple binaries from the startup
shell script.  The previous patch to the PAGE_OFFSET etc seemed to have
fixed that problem.

The other possibility is a problem with your uClibc.  Are you using the
one in the toolchain or a newer one?  I am building all my tools from
the full uClinux source distribution.  If you haven't already I'd
suggest downloading that (and get then get iPod updates from my CVS
tree).  That build uses a very recent uClibc, all the various tools have
been patched to work correctly under uClinux.  I've update the build
documentation online with more information on the uClinux-dist build.

My script to get things up on the iPod

insmod /lib/modules/2.4.20-uc0/kernel/arch/armnommu/mach-ipod/ieee1394.o
insmod /lib/modules/2.4.20-uc0/kernel/drivers/ieee1394/eth1394.o
ifconfig eth0 10.0.0.1
inetd

inetd is configured to run telnetd as normal.

The only problem I have with my setup is that the password file is not
recognised so you just press enter,enter for the user and password
prompts :)

cheers,
bern.

On Wed, 2003-03-12 at 22:42, Chandan Kudige [home] wrote:
> Hi Bernard,
> 
> I did manage to compile the kernel for the ipod with firewire support
> and also the host eth1394 module with the patch.
> 
> How do you configure stuff ? I still cannot execute more than one binary
> (when it returns it hangs), so if I run ifconfig I cannot run anything
> else after that. Are you able to run telnetd an spawn a shell on the
> telnet session without problems ?
> 
> Or do you have your own version of telnet which configures ip address
> and waits for connections ?
> 
> Thanks,
> Chandan
> 
> On Wed, 2003-03-12 at 13:53, Bernard Leach wrote:
> > Hi all,
> > 
> > I've just uploaded a new kernel patch that reflects the current head of
> > the tree in CVS.  The firewire patches are in there directly now rather
> > than having to download extra parts and hand-patch.
> > 
> > The following host side patch to drivers/ieee1394/eth1394.c though is
> > still required to get TCP/IP going.  (This is a patch to a vanilla
> > 2.4.20 kernel).
> > 
> > Also available now in CVS are the uClinux-dist "vendor" files.  If you
> > drop them into a source release for uClinux then you can simply build
> > all your binaries for the iPod.  The build documentation online has some
> > more details.
> > 
> > I'll put together binary releases in the next couple of days.
> > 
> > cheers,
> > bern.
> > 
> > --- eth1394.c.orig      2003-03-12 16:35:47.000000000 +0100
> > +++ eth1394.c   2003-03-12 16:38:27.000000000 +0100
> > @@ -680,6 +680,11 @@
> >         }
> >   
> >         ptask->skb = skb;
> > +       /* hack to address broadcast packets to the "other" node */
> > +       if ( (dest_node & NODE_MASK) == NODE_MASK ) {
> > +               dest_node = priv->host->node_id ^ 0x1;
> > +               addr = ETHER1394_REGION_ADDR;
> > +       }
> >         ptask->addr = addr;
> >         ptask->dest_node = dest_node;
> >         INIT_TQUEUE(&ptask->tq, hpsb_write_sched, ptask);
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by:Crypto Challenge is now open! 
> > Get cracking and register here for some mind boggling fun and 
> > the chance of winning an Apple iPod:
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> > _______________________________________________
> > iPodlinux-devel mailing list
> > iPo...@li...
> > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel
> > 
> 
> 

[Ipodlinux-devel] updated kernel patch available

[Bernard L. <le...@bo...>]

Hi all,

I've just uploaded a new kernel patch that reflects the current head of
the tree in CVS.  The firewire patches are in there directly now rather
than having to download extra parts and hand-patch.

The following host side patch to drivers/ieee1394/eth1394.c though is
still required to get TCP/IP going.  (This is a patch to a vanilla
2.4.20 kernel).

Also available now in CVS are the uClinux-dist "vendor" files.  If you
drop them into a source release for uClinux then you can simply build
all your binaries for the iPod.  The build documentation online has some
more details.

I'll put together binary releases in the next couple of days.

cheers,
bern.

--- eth1394.c.orig      2003-03-12 16:35:47.000000000 +0100
+++ eth1394.c   2003-03-12 16:38:27.000000000 +0100
@@ -680,6 +680,11 @@
        }
  
        ptask->skb = skb;
+       /* hack to address broadcast packets to the "other" node */
+       if ( (dest_node & NODE_MASK) == NODE_MASK ) {
+               dest_node = priv->host->node_id ^ 0x1;
+               addr = ETHER1394_REGION_ADDR;
+       }
        ptask->addr = addr;
        ptask->dest_node = dest_node;
        INIT_TQUEUE(&ptask->tq, hpsb_write_sched, ptask);

Re: [Ipodlinux-devel] firewire success!

[Bernard L. <le...@bo...>]

Hi all,

A couple of points I managed to miss in the announcement.

In order to use the eth1394 module on your host machine I would
currently recommend sticking to just having the PC and iPod connected. 
I don't believe it should cause any problems to other devices but its
very early days in this driver's life :)  The patch to the eth1394
driver renders it pretty much useless for talking to anything but the
iPod.  You can have a 2nd copy of that driver and just modprobe the
correct one if you need a "normal" eth1394 as well.

The second big catch is that the iPod must have nodeid 01 and the host
must be 00.  The two ids are allocated basically randomly so if the iPod
ends up with the wrong one just reboot it.  Hopefully I can sort out
this bug soon!

cheers,
bern.

On Fri, 2003-03-07 at 18:02, Bernard Leach wrote:
> Hi All,
> 
> Finally I have had some success with firewire on the iPod!  I have now
> successfully telnet'ed to my iPod, logged in and run things
> interactively.  Needless to say I'm a happy camper!  This should make
> some of the testing experimentation much simpler.
> 
> Firstly some bad news.  I almost certain the hardware can't support the
> RFC'ed version of TCP/IP over ethernet it just doesnt support the
> necessary parts of IEE1394.  The good news is that if you run Linux its
> can be made to work anyhow!
> 
> There are still some bugs & weirdness but if you follow the steps it
> should work :)
> 
> Firstly you need to get the svn version of the IEEE1394 drivers.  To do
> this see their sourceforge website.  You need to get the 2.4.xx stuff. 
> You then need to copy that to your uClinux build & to your host PC
> kernel.  Then you will need to apply two different patches to those
> trees.  The changes are quite small though (infact you could probably
> just modify the current versions in 2.4.20 but I havent tried that yet).
> 
> Once you are patched up, for uClinux just copy in the new config from
> arch/armnommu/def-configs/ipod to .config and do a make oldconfig.  then
> make dep && make && make modules.  The ethernet over 1394 is configured
> as a module so you also need an insmod/modprobe.
> 
> A fairly easy way to get all the tools is to grab the full uClinux
> distribution and compile from that.  A new version is just out and
> includes just about everything under the sun (its a 120MB download). 
> Check out their website.
> 
> For those who don't mind waiting once a few people have tested this I'll
> put together a new patch & binary release with all the goodies.
> 
> BTW if anyone has a SBP2 device they could test this I'd be interested
> in hearing how it goes.
> 
> cheers,
> bern.
> 

[Ipodlinux-devel] firewire success!

[Bernard L. <le...@bo...>]

Hi All,

Finally I have had some success with firewire on the iPod!  I have now
successfully telnet'ed to my iPod, logged in and run things
interactively.  Needless to say I'm a happy camper!  This should make
some of the testing experimentation much simpler.

Firstly some bad news.  I almost certain the hardware can't support the
RFC'ed version of TCP/IP over ethernet it just doesnt support the
necessary parts of IEE1394.  The good news is that if you run Linux its
can be made to work anyhow!

There are still some bugs & weirdness but if you follow the steps it
should work :)

Firstly you need to get the svn version of the IEEE1394 drivers.  To do
this see their sourceforge website.  You need to get the 2.4.xx stuff. 
You then need to copy that to your uClinux build & to your host PC
kernel.  Then you will need to apply two different patches to those
trees.  The changes are quite small though (infact you could probably
just modify the current versions in 2.4.20 but I havent tried that yet).

Once you are patched up, for uClinux just copy in the new config from
arch/armnommu/def-configs/ipod to .config and do a make oldconfig.  then
make dep && make && make modules.  The ethernet over 1394 is configured
as a module so you also need an insmod/modprobe.

A fairly easy way to get all the tools is to grab the full uClinux
distribution and compile from that.  A new version is just out and
includes just about everything under the sun (its a 120MB download). 
Check out their website.

For those who don't mind waiting once a few people have tested this I'll
put together a new patch & binary release with all the goodies.

BTW if anyone has a SBP2 device they could test this I'd be interested
in hearing how it goes.

cheers,
bern.

Re: [Ipodlinux-devel] status update 17.02.03

[Chandan K. [home] <ch...@to...>]

In the current implementation of cop code, everytime an application
tries to write more than one frame of data to the /dev/dsp, it will be
put to sleep as long as the kernel keeps feeding this data to the cop
(I think the shared SRAM is 92K only)

One way to handle this would be to implement a kernel thread which would
take the user data and keeps feeding to the cop. This thread would be
sleep most of the time, and the user program can continue its execution
in parallel. I still havent tried this out.

Intel's mp3player writes one frame at a time and hence does not incur
this waiting. But I can verify by playing it to /dev/null just to be
sure.

So if we can do away with the cop and write to the audio in the main
processor we can still follow this approach so that we do not tie up the
user process. We can still move the decoding routine into the SRAM (I
would assume that 92K should be more than enough!).

I can give this a try over the weekend.

-Chandan

On Tue, 2003-03-04 at 03:44, Andre wrote:
> Bernard Leach <le...@bo...> wrote:
> > 
> > An extension of that would be to then put the decoding routines
> > in fast ram (since we wouldnt be using it as the buffer).
> > I'm not sure how big a win this would be but it is how the real
> > firmware works...
> > 
> 
> My guess is that this will be a _big_ win. The internal SRAM is
> likely to be 32bit wide, with low (probably zero) wait-states when
> accessed from the ARM.
> 
> The system SDRAM on the other hand (Samsung part No. K4S561632 ??) is
> 16bit wide, has the overhead of refreshes etc and is probably clocked
> slower as well (anyone with an open ipod and a 'scope handy, please
> put a probe on pin 38 of the SDRAM chip and let us know for sure...
> :-).
> 
> The most important code in madplay to speed up is the imdct36
> assembler function and the contents of synth.c. The later may take a
> bit more work, but the former is fully PIC so a quick and dirty test
> would be to hack madplay to memcpy the whole of III_imdct_l into fast
> SRAM at program startup and then call it from there via a function
> pointer (its only called from 2 places in layer3.c).
> 
> How big is the internal SRAM by the way ???
> 
> Andre
> --
> 
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you feeling lost and 
> disoriented. TotalView can help you find your way. Available on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> iPodlinux-devel mailing list
> iPo...@li...
> https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel
> 

Re: [Ipodlinux-devel] status update 17.02.03

[<arm...@ya...>]

Bernard Leach <le...@bo...> wrote:
> 
> An extension of that would be to then put the decoding routines
> in fast ram (since we wouldnt be using it as the buffer).
> I'm not sure how big a win this would be but it is how the real
> firmware works...
> 

My guess is that this will be a _big_ win. The internal SRAM is
likely to be 32bit wide, with low (probably zero) wait-states when
accessed from the ARM.

The system SDRAM on the other hand (Samsung part No. K4S561632 ??) is
16bit wide, has the overhead of refreshes etc and is probably clocked
slower as well (anyone with an open ipod and a 'scope handy, please
put a probe on pin 38 of the SDRAM chip and let us know for sure...
:-).

The most important code in madplay to speed up is the imdct36
assembler function and the contents of synth.c. The later may take a
bit more work, but the former is fully PIC so a quick and dirty test
would be to hack madplay to memcpy the whole of III_imdct_l into fast
SRAM at program startup and then call it from there via a function
pointer (its only called from 2 places in layer3.c).

How big is the internal SRAM by the way ???

Andre
--





__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: [Ipodlinux-devel] status update 17.02.03

[Bernard L. <le...@bo...>]

[ CC'ed back to the list :) ]

Hi Chandan,

Those numbers are interesting, it looks like the audio driver is
_really_ wasting that extra cpu!  One experiment we could try is to just
get the main cpu to do all the work.  An extension of that would be to
then put the decoding routines in fast ram (since we wouldnt be using it
as the buffer).  I'm not sure how big a win this would be but it is how
the real firmware works...  The "fast ram" is onboard ram so I guess its
similar speed to the cache??

cheers,
bern.

On Tue, 2003-03-04 at 06:02, Chandan Kudige [home] wrote:
> > Be careful about changing the optimisation level when compiling with
> > gcc. -O3 should be faster than -O2, but in a lot of cases it isn't
> > (infact -O1 or -Os are sometimes faster than either of them !!). I
> > don't think it's going to make it 25% faster, but you should give
> > each one a try if possible.
> I will give this a try tomorrow.
> 
> > 
> > Did you try madplay with '-o/dev/null' ??
> > That would give a clue about how much time is spent in madplay and
> > how much in the other stuff (e.g. audio output driver etc).
> > 
> 
> Here are the numbers with /dev/null
> For the 128 second clip:
> Without patch:  163.00 sec 
> With patch:     158.47 sec
> 

Re: [Ipodlinux-devel] status update 17.02.03

[Chandan K. [home] <ch...@to...>]

Hi Bernard,

> There is a newer version of the Intel libraries that may also provide
> some improvement.  Last time I looked there was a 3.0 download but I
> couldnt install the thing as I dont have a RPM system (or the patience
> to stuff about with them).  These libraries also have JPEG processing
> which could be quite cool.
> 

I think I am using the 3.0 ... I did download the older version, but I
installed the latest one in the end. The RPM has no dependency, so you
can safely install it. It just puts in some files under
/usr/local/ipp/ippsa111

> The other audio decoder option is madplay.  I was using that originally
> but not getting very good performance.  Andre (see the CC list) sent me
> some ARM performance patches which should help.
> 

I also tried ffmpeg (which has always been known for its performance,
and it has a integer only version too). But I have not seen/used ARM
specific optimisations with ffmpeg.

If you could please send me the ARM patches for madplay I will give it a
shot. I think intel achieves the phenomenal performance by a lot of
hand-optimisations.

> Regarding the playlists etc have you looked at any of the existing Linux
> programs for processing the current iPod databases?  I imagine a lot of
> Mac users would be quite happy to keep using iTunes to manage their
> stuff...

There is enough support for using iPod + iTunes with Linux. There is a
scripting tool called gnupod ( http://sf.net/projects/gnupod), there is
a iTunesDB library ipod ( http://ipod-on-linux.sf.net ). I do have a
KDE/Qt program which supports iTunes format and adding/removing songs,
creating and managing playlists etc (http://guipod.sf.net).
We can continue to use it in our firmware, but also provide a foldermode
to browse and play from folders directly.

cheers,
Chandan