Menu
▾
▴
ipodlinux-devel
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(9) |
Mar
(21) |
Apr
(12) |
May
(11) |
Jun
(6) |
Jul
(3) |
Aug
|
Sep
(10) |
Oct
(20) |
Nov
(32) |
Dec
(41) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(48) |
Feb
(27) |
Mar
(120) |
Apr
(69) |
May
(15) |
Jun
(1) |
Jul
(6) |
Aug
(1) |
Sep
(1) |
Oct
(6) |
Nov
(2) |
Dec
(4) |
| 2005 |
Jan
|
Feb
(10) |
Mar
(1) |
Apr
(1) |
May
|
Jun
(3) |
Jul
|
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2006 |
Jan
(3) |
Feb
(4) |
Mar
(9) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bernard L. <le...@bo...> - 2004-05-09 11:19:08
|
I don't have a mini so not likely to be much progress there... For typing probably the best solution is to use a serial keyboard (like from the Palm etc) and hook it up to the serial input in the remote (or better on the dock). If the electronics were sorted out the software already exists... cheers, bern. On Thu, 2004-05-06 at 18:36, Joe Corneli wrote: > > I googled around online and found some differences in hardware for the > > mini, notably the new firewire chip and the ability to act as both a > > USB 2.0 client and host. Now I imagine plugging in a USB keyboard is > > actually a > > I assume that these new FW chips will find their way into the next > upgrade of the iPods some time this year? So I can put off buying on > for yet another year. My first gripe, no touch-screen, so no > possibility of good input. Now, the FW chip will presumably soon be > able to be host, so keyboards can be hooked up.. > > Looking forward to that day! I guess it is theoretically possible > with the mini right now though? > > It is amazing that there seems to be no small platform extant with > onboard USB keyboard support. (If I'm wrong about this, let me > know.) > > Any updates on the possibilities for typing/xmodmap/Emacs on iPod > (or mini) would be very much appreciated. |
|
From: Matthew J. S. <ge...@do...> - 2004-05-07 16:35:27
|
As I posted on the forum: http://www.dotink.org/podzilla -- although it's really not much yet. If I made it sound like more I do apologize. As far as beginning to integrated the mp3 code stuff, that might be a ways off still, although it should be designed as independently as possible I think and then pulled in. What you could do if you're interested is download that code, start and mp3.c and mp3.h file and try to keep all your stuff in there for now and just keep various actions as different functions. I'm not really sure how libmad does it, but you could have a funciton to queue up the mp3s if passed and array of strings, etc..etc.. and then we'll work it in later. Really depending on how much you've already done in with the original podzilla I'd suggest you keep going on that we can just pull in from that code. The designs are similar yet this one is just more modularized, so it may be just as easy to do it that way, not sure. The best thing you can do right now, unless you plan to integrate the code now or in the end is to just keep track of any changes you make outside of mp3.c and mp3.h, and/or ogg.c and ogg.h (if you're doing these). This way here I know what kind of hooks have been buried into other parts of podzilla. If you're gonna do all the work yourself then I'd suggest waiting a bit till the more underlying stuff in podzilla is finalized. This way you know I won't be making any major changes to PTK and/or the basics of Podzilla. My best suggestion to all those who want to develop right now is to continue work on the latest podzilla I released based on the original code (or even the original for that matter, but there were some fairly major changes I made with event handling to the newer of the old ones). You can get that code on the site I mentioned above as I'm not sure if Bern has committed it to CVS yet. Unless of course you want to work out some of the underlying stuff, then either talk to me or Bern and we'll try to balance off when and how to work that. Once all this stuff is finalized Podzilla and PTK will be released as 0.2 -- at which point the widgets we have now should be finalized and nothing major should be changing to them, and only more widgets will be added. At 0.2 for Podzilla I'd like to see it basically jumping through most of the menus with as many of the settings done as we can get. I still wouldn't mark these at anything less than 2 weeks away, however (just to make sure). Really once the ground work is laid I don't suspect it should be more than another 2 weeks or so to get pretty much all the major functionality in place -- while it may not be well in place, it will definitely be in place. Some of the functionality that will wait is things like the calendar and contacts... and you really won't see indicator widgets until around the same time as those as those will entail new widgets. Anyway, that's all I got, cheers. On Fri, 7 May 2004 15:40:48 +0200 "Jonathan C. Ross" <jon...@ba...> wrote: > Hi again Efram/Matthew, > > where can I find the PTK/podzilla code? (I must have missed a crucial > posting or so?) I guess actually contributing by coding would help > more than just presenting you ideas :-). Anyway, I'd like to work on > calling libmad from your version of podzilla rather than my own > version. > > Cheers, > > Jonathan. > |
|
From: Joe C. <jco...@ma...> - 2004-05-06 16:36:49
|
> I googled around online and found some differences in hardware for the
> mini, notably the new firewire chip and the ability to act as both a
> USB 2.0 client and host. Now I imagine plugging in a USB keyboard is
> actually a
I assume that these new FW chips will find their way into the next
upgrade of the iPods some time this year? So I can put off buying on
for yet another year. My first gripe, no touch-screen, so no
possibility of good input. Now, the FW chip will presumably soon be
able to be host, so keyboards can be hooked up..
Looking forward to that day! I guess it is theoretically possible
with the mini right now though?
It is amazing that there seems to be no small platform extant with
onboard USB keyboard support. (If I'm wrong about this, let me
know.)
Any updates on the possibilities for typing/xmodmap/Emacs on iPod
(or mini) would be very much appreciated.
|
|
From: Matthew J. S. <ge...@do...> - 2004-05-06 06:20:32
|
For those who haven't paid attention to the forums, and for the fact alone that I said I'd post on here when the time came, I'm making an anouncement. As many of you well know, PTK has matured a fair amount to the point where Podzilla coding has begun. I'm actually progressing through Podzilla rather quickly aswell. However, at the moment Bernard is doing some cleanup work and additions to PTK so I'm trying to stay away from it. Despite this I've had to make some slight changes during the Podzilla development which should be easily incorporated to whatever he does. Anyway, this call is to all of those who were interesting in submitting ideas that they felt should be included in Podzilla. I recommend using the forum to actually discuss this as I think it's a better medium and will serve us better to look back on the ideas and pull them in as we develop. But to all those who were interested, jump on the forum ASAP and get your ideas out. Here's the rundown of where Podzilla stands at the moment (tis not much, but as I said I'm progressing faster now that my laptop is set up): - Initialization works great. Most of the objects we see now are global and exist on a main window.. these things are stuff that a lot of functions need to be able to write to, for example the title in the header. The clock is also global, as will be any indicators that get stuck on the footer once the indicator widget is done. - There's some general event handling stuff in there. Mainly just for hitting the menu key right now. The menu key with a simple push and let off will close a window -- I plan to implement it so that holding the menu key minimizes a window and all windows will be accessible through a list added either on the Main menu or in Extras -> Windows. This creates some unique functionality that podzilla will have over apple's firmware. While apple's firmware no doubt could do this and may (you just don't see the inactive windows unless you close or minimize the active one) we will have more like a window manager type scenario. This means users can keep seveal windows open one with a calendar, one with contacts, and maybe a file browser or something, and switch between them. The benefit of this is not losing your place or something if you close another window and want to come back to what you were doing with a calendar. - With that said, I've implemented a crude window stack which is just an array of MAX_WINDOWS number of pointers to windows. It seems pointless to go through another child/parent/sibling scheme, and the seek time to place a window in a slot and remove one should be minimal. The current MAX_WINDOWS is set to 50 which will probably be extremely high. Once some testing is done It'll probably get cut down quite a bit. - The main menu initializes, however, right now all the functions are ptk_nullvoid_function. There's an issue at this point in the game with the way the listbox widget is designed, and I'm probably gonna have to rework some of it, but I'm waiting till Bern finishes up as that's more of a major bit of work. The problem is as follows: I want to make all items essentially the same, thus we have all items containing a pointer to a function which is to be called when that list item is "executed" so to speak. However, depending on what the list item is, these function may require different types and amounts of arguments. So I'm still cooking up a way to fit around that. - There's some crap animation job I did that slides the windows off to the right when they are minimized. Maximizing a window slides it back in from the left -- similar to apple's -- not sure how smooth it's going to be yet as I've only tested this on X on my laptop where it's actually not that great looking. - I've pulled in the old ipod.c file I used with the settings stuff, so basically the old podzilla.conf system is what I'm gonna stick with, which I find personally to be the better way to keep it going. It's still up in the air how the menu's are going to be formed. The options are to keep all menu information in a structures or to have it in a file and then have those parsed onto the menu. Either way there will exist two major menu functions... the first is for the main menu -- this requires it's own function as the main menu is configurable from within the iPod such as apple's firmware is. Thus it's construction looks something like: Pseudo code: if(main_menu_option == True) add the proper option to the menu All other menus just need to run through the list and add each thing in the list to the menu, thus those will be created using a simple generate menu function which will run through the structure or a section of a config file and put everything in place. File menus will of course also have their own function that actually reads the directory. Eventually I would suspect that menus built on the iTunes database would also have their own menu function. -- this however seems messy, and I may look for a cleaner solution later. I think that's about it for now. Podzilla "looks" fairly interesting as it stands -- but really doesn't do much of anything yet. Any ideas or suggestions on how to fix any of the problems (especially the one about item's function pointers) are going to be very well received. Lastly I'd just like to note some oddities and see if anyone out there with more technical skill than me can figure out why these happen: 1) In the PTK I handed of to Bern a couple days ago and what is currently linked in the forum things that created their own Graphic's Contexts would copy the original ptk_gc context -- thus creating a new one that is a copy. In their destroy functions they used GrDestroyGC to destroy it. However, I noticed upon destroying a listbox in podzilla that it seemed GrDestroyWindow attempted to destroy the GC aswell. This didn't make much sense to me because the Window doesn't really seem to have any way of knowing what GC is related to it. I double checked to make sure my relative update functions weren't accidently calling the destroy on a few things twice, and eventually boiled it down that GrDestroyWindow pretty much has to be what's also trying to destroy it. To resolve this I took GrDestroyGC out and just let the DestroyWindow handle it, however, I'm confused where this actually destroys the graphics context -- whether it somehow gets destroyed in my code or via microwindows stuff I don't know, but it DOES try to destroy it twice if both GrDestroyGC and GrDestroyWindow are used. The bug itself was microwindows spititng out a bunch of crap about being unable to destroy the Graphics context and then seg faulting. As I said, it's fixed by using just GrDestroyWindow but I'm really curious and want to ensure that the graphic's context is being destroyed properly. 2) For those who aren't familiar with my coding background or who don't hang out on IRC enough, I pretty much openly admit that I'm not a very good programmer. Despite this I move on for you the people. However, having no experience really with programming a toolkit or graphical applications in my life, I'm a bit confused with some of the concepts. One of these is the idea of the exposure. While I understand what kinds of things can cause the exposure event, I'm unsure exactly why or why it shouldn't be handled. The Podzilla event handler right now does nothing on an exposure event, and windows only get redrawn really when they are directly changed by podzilla. While PTK draws when a window is created and such, it by no means does it any other time, and with no concept of event handling does nothing on Exposure either. However, the weird thing about this all is that the Podzilla window on X seems to flicker as if it's being redrawn a tad bit slowly or something. It does this somewhat randomly, sometimes about a second apart here ot there, sometimes longer -- I suppose it may not actually be redrawing -- as I don't see where it would be... but any ideas what might cause this flicker on a Microwindows, X11, or Podzilla/PTK level? LAST FEW NOTES: Aside from removing GrDestroyGC from the destroy function in PTK I noted that PTK_CH didn't exist anymore, I had two PTK_CHAR's in ptk.h -- so I fixed that real quick by making on PTK_CH. I also ensured that the listbox, slider, and window based widgets cleared their windows before the redrew themselves. And I added a quick eventhandler function to widgets -- I may end up laying groundwork for PTK event handling, however, right now it's only there so that event handlers can be set on various widgets to actually handle keypresses. The original Demo didn't have this issue cause it only had one listbox and the event handler called it's functions directly, but since the event handler is not 100% centralized in PZ (at least not for keypresses) they each have to be aware of keypress function to call in the event a key falls to them. I guess until Bern is done with PTK and I come up with some other ideas I'll be trying to wrap my head around how microwindows handles 16-bit unicode and fonts and stuff and trying to make that a reality so I can convert PTK_CHAR's to wchar_t and use wchar based functions when necessary. There's still a long way to go in terms of internationalization support. I'm sure I'll figure it all out in the end... Sincerely, Matthew J. Sahagian (Efram) |
|
From: Bernard L. <le...@bo...> - 2004-05-03 18:54:27
|
Basically I just wrote some code to copy the firmware to the right location in memory (its the same location as the kernel so you need to make sure the kernel is shutdown e.g. interrupts off), then tried to intialise the hardware back to the state its in after the Apple bootloader. Then I jumped the CPU and COP to 0x28000000 ;) The problem I had was that after the final jump there is no debug, so when it failed there was no way to work out why. You then have to hard reboot, wait for linux to boot then try again. It gets pretty frustrating pretty quickly. cheers, bern. On Mon, 2004-05-03 at 06:05, David Piasecki wrote: > Bernard, > > What steps did you take in your attempt? > > David > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > iPodlinux-devel mailing list > iPo...@li... > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel > |
|
From: David P. <dpi...@ma...> - 2004-05-03 04:05:53
|
Bernard, What steps did you take in your attempt? David |
|
From: Bernard L. <le...@bo...> - 2004-05-02 10:48:35
|
Yeah that would be possible but it would need a much more advanced bootloader. Currently the bootloader just uses the standard apple firmware to do the diskloading portion so its very simple. If we "ported" grub/lilo or similar then it could work. As for the audio recording. I'll post when something goes into CVS ;) cheers, bern. On Sun, 2004-05-02 at 12:35, Mathieu wrote: > Hi ! > Okay, So when you have made some progress (like putting the driver in the > kernel), "keep us in news" :) ! > I have one other question.. Is it possible to put into a parition two > diffrent firmware (like linux and apple's firmware) and the bootloader will > load one of the firmwares. And when we would like update the firmware we can > just replace the firmware and we don't need anymore to rebuild all the > bootloader like now.. > > Best regards, > Mathieu > ----- Original Message ----- > From: "Bernard Leach" <le...@bo...> > To: <ipo...@li...> > Sent: Sunday, May 02, 2004 11:15 AM > Subject: Re: [Ipodlinux-devel] Recording > > > > > > Hi Mathieu, > > > > I have been working on the recording function but its not quite > > integrated into the kernel yet. I'm trying ot spend some time on it > > today so hopefully I'll make some progress. > > > > The sample program isn't a sample as such, just a bit of a assembler > > that tweaks the registers to get stuff to work. Not really useful for > > much more than that though. > > > > cheers, > > bern. > > > > On Thu, 2004-04-29 at 21:25, Mathieu wrote: > > > Hi everybody ! > > > > > > I have heard (on the forum) that some people are doing some work on > > > the recording feature of the iPod and I heard that a sample program > > > isa available too.. > > > So my question are where can I get this sample program and what the > > > state of the "research" ? > > > > > > Thanks > > > > > > Mathieu > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: Oracle 10g > > Get certified on the hottest thing ever to hit the market... Oracle 10g. > > Take an Oracle 10g class now, and we'll give you the exam FREE. > > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > > _______________________________________________ > > iPodlinux-devel mailing list > > iPo...@li... > > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > iPodlinux-devel mailing list > iPo...@li... > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel > |
|
From: Mathieu <zi...@xw...> - 2004-05-02 10:35:36
|
Hi ! Okay, So when you have made some progress (like putting the driver in the kernel), "keep us in news" :) ! I have one other question.. Is it possible to put into a parition two diffrent firmware (like linux and apple's firmware) and the bootloader will load one of the firmwares. And when we would like update the firmware we can just replace the firmware and we don't need anymore to rebuild all the bootloader like now.. Best regards, Mathieu ----- Original Message ----- From: "Bernard Leach" <le...@bo...> To: <ipo...@li...> Sent: Sunday, May 02, 2004 11:15 AM Subject: Re: [Ipodlinux-devel] Recording > > Hi Mathieu, > > I have been working on the recording function but its not quite > integrated into the kernel yet. I'm trying ot spend some time on it > today so hopefully I'll make some progress. > > The sample program isn't a sample as such, just a bit of a assembler > that tweaks the registers to get stuff to work. Not really useful for > much more than that though. > > cheers, > bern. > > On Thu, 2004-04-29 at 21:25, Mathieu wrote: > > Hi everybody ! > > > > I have heard (on the forum) that some people are doing some work on > > the recording feature of the iPod and I heard that a sample program > > isa available too.. > > So my question are where can I get this sample program and what the > > state of the "research" ? > > > > Thanks > > > > Mathieu > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > iPodlinux-devel mailing list > iPo...@li... > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel > > |
|
From: Bernard L. <le...@bo...> - 2004-05-02 10:17:09
|
Hi Mathieu, I have been working on the recording function but its not quite integrated into the kernel yet. I'm trying ot spend some time on it today so hopefully I'll make some progress. The sample program isn't a sample as such, just a bit of a assembler that tweaks the registers to get stuff to work. Not really useful for much more than that though. cheers, bern. On Thu, 2004-04-29 at 21:25, Mathieu wrote: > Hi everybody ! > > I have heard (on the forum) that some people are doing some work on > the recording feature of the iPod and I heard that a sample program > isa available too.. > So my question are where can I get this sample program and what the > state of the "research" ? > > Thanks > > Mathieu |
|
From: Bernard L. <le...@bo...> - 2004-05-02 10:14:19
|
I spent some time trying to start the Apple firmware from Linux but couldn't quite get the hardware initialisation right & it kept hanging/crashing. On Fri, 2004-04-30 at 05:38, David Piasecki wrote: > Is it possible to run Apple's firmware from within Linux? That way you > could have Apple's nifty interface without having to reboot. I'm sure > there's more involved, but I would imagine you'd do something like set > an instruction pointer while leaving the rest of Linux operating so you > could jump in and out of Linux. > > David |
|
From: David P. <dpi...@ma...> - 2004-04-30 03:38:33
|
Is it possible to run Apple's firmware from within Linux? That way you could have Apple's nifty interface without having to reboot. I'm sure there's more involved, but I would imagine you'd do something like set an instruction pointer while leaving the rest of Linux operating so you could jump in and out of Linux. David |
|
From: Mathieu <zi...@xw...> - 2004-04-29 19:25:12
|
Hi everybody ! I have heard (on the forum) that some people are doing some work on the = recording feature of the iPod and I heard that a sample program isa = available too.. So my question are where can I get this sample program and what the = state of the "research" ? Thanks Mathieu |
|
From: Bernard L. <le...@bo...> - 2004-04-29 18:32:08
|
Sorry, I don't think you can read back the values from the controller.
You could check the databook but I'm fairly sure you can't do it.
Anyhow its probably better/easier to just do what the framebuffer does
and keep a local buffer.
If you look at the microwdindows driver it uses the framebuffer's local
storage to "double buffer" the ram.
Speaking of microwindows though, why would you need your own drawPixel
when you could just use that?
cheers,
bern.
On Thu, 2004-04-29 at 10:08, Jean-Charles Tournier wrote:
> Hi all,
>
> I'am trying to access to the LCD directly by its controller. Thanks
> tothe framebuffer source file i understood how to write a pixel with
> the0x12 command. But now my problem is to read a value of a pixel? It
> isalso the command 0x12, but where I read the value in the CGRAM
> pointedby my cursor??? I can't find this information in the
> documentation.
>
> I send you my code which draw a pixel.
>
> void drawPixel( int x,int y, int color){
> unsigned short cursor_pos;
> unsigned data_lo, data_hi, data, mask;
>
> cursor_pos = (x/8) + (y * 0x20); //
>
> /* move the cursor */
> lcd_cmd_and_data(0x11, cursor_pos >> 8, cursor_pos & 0xff);
>
> /* setup for printing */
> lcd_prepare_cmd(0x12);
>
>
> data = color;
> data = data << ((x%4)*2);
>
> //Here is the problem!!! I know that my value of data_lo anddata_hi
> are false
> lcd_wait_write();
> data_lo = inl(0xc0001010);
> lcd_wait_write();
> data_hi = inl(0xc0001010);
>
> mask = 0x03;
> mask = mask << ((x%4)*2);
> mask = ~mask;
>
> if (x%8<4){
> data_lo &= mask;
> data_lo |= data;
> }
> else{
> data_hi &= mask;
> data_hi |= data;
> }
> lcd_send_data( data_hi, data_lo);
> }
>
> If anyone have an idea.....
>
> thanks,
> jean-charles.
|
|
From: Jean-Charles T. <jea...@rd...> - 2004-04-29 08:08:33
|
Hi all,
I'am trying to access to the LCD directly by its controller. Thanks to
the framebuffer source file i understood how to write a pixel with the
0x12 command. But now my problem is to read a value of a pixel? It is
also the command 0x12, but where I read the value in the CGRAM pointed
by my cursor??? I can't find this information in the documentation.
I send you my code which draw a pixel.
void drawPixel( int x, int y, int color){
unsigned short cursor_pos;
unsigned data_lo, data_hi, data, mask;
cursor_pos = (x/8) + (y * 0x20); //
/* move the cursor */
lcd_cmd_and_data(0x11, cursor_pos >> 8, cursor_pos & 0xff);
/* setup for printing */
lcd_prepare_cmd(0x12);
data = color;
data = data << ((x%4)*2);
//Here is the problem!!! I know that my value of data_lo and data_hi
are false
lcd_wait_write();
data_lo = inl(0xc0001010);
lcd_wait_write();
data_hi = inl(0xc0001010);
mask = 0x03;
mask = mask << ((x%4)*2);
mask = ~mask;
if (x%8<4){
data_lo &= mask;
data_lo |= data;
}
else{
data_hi &= mask;
data_hi |= data;
}
lcd_send_data( data_hi, data_lo);
}
If anyone have an idea.....
thanks,
jean-charles.
|
|
From: Benjamin H. <be...@ke...> - 2004-04-27 22:51:39
|
On Wed, 2004-04-28 at 01:38, Jonathan C. Ross wrote: > Have you got any pointers for reallocating code? As I said previously, > arm-elf-ld didn't like me trying to tell it where to put stuff. Should > I try > a kernel-style relocation? How would you guys do it? > > As Bern pointed out, we really need profiling... has anybody gotten > -pg to work with the arm-elf toolchain? For moving thigns around, I usually put them in separate ELF sections (I define __sram and __sramdata macros, similar to the kernel equivalent section macros) and then use the ld script to link those sections at different addresses than where they are loaded. Then, at boot, you need a bit of code that copies those to their final address. Ben. |
|
From: Jonathan C. R. <jon...@ba...> - 2004-04-27 15:38:42
|
On Apr 26, 2004, at 3:09 AM, Benjamin Herrenschmidt wrote:
>
> Well, there are 2 things. One is to allocate the memory in the
> SRAM, and the other is to call routines with the stack there. Normally,
> Linus has one stack per process/thread, so you need to chose carefuly
> where/when to switch stack there. Then, what I'd do is to create a
> small asm trampoline that switches the stack, store the old stack
> pointer
> on the new stack (for the exit path), and jump to the routine that has
> to be executed on the internal stack. You could do that on a thread
> entry point for a whole thread to use that SDRAM stack for example.
>
> Ben
>
Hi,
I've given myself a crash-course in ARM assembly and performed a
'stack trampoline' pretty much the way you suggest. I _think_ there is
some performance improvement, but It's very difficult to tell without a
proper profiler.
In summary, I have performed the following optimisations in libmad:
1. I have moved all dynamically allocated structures to the SRAM;
2. I have moved some static data from the sampling routines too
(the 'D' structure from D.dat)
3. I have moved the stack to 0x40017ffc
Guessing from audio quality and tempi, this has given me a 10-20%
performance boost.
I will attempt two more things now - first I'll try _moving_ the
sampling
code (judging by profiling on an i386 this is the bottleneck) to the
SRAM, along with some of the Huffmann and layer 3 static data.
If that fails, I'll try a hack where I write directly to the COP's
audio buffer
(instead of copying first to slow memory, converting to little-endian
DSP,
then writing back to SRAM). (We'll be doing this in the kernel version
anyway.)
As a last resort I will turn to hand-coding the dct/sample code -
looking
at the assembly output on sample.c, there is a lot of work to be done
there...
Have you got any pointers for reallocating code? As I said previously,
arm-elf-ld didn't like me trying to tell it where to put stuff. Should
I try
a kernel-style relocation? How would you guys do it?
As Bern pointed out, we really need profiling... has anybody gotten
-pg to work with the arm-elf toolchain?
Cheers,
Jonathan.
|
|
From: Benjamin H. <be...@ke...> - 2004-04-26 01:13:35
|
> I've been looking at the libmad code, and an awful lot of the > calculation seems to take place on the stack... Your idea seems very > good to me. How does one go about putting the stack somewhere else? I > tried hacking an ld script but I must confess I'm a bit stuck... Either > I don't understand the scripts at all, or arm-elf-ld doesn't like being > told what to do. > > The same goes for moving some code: after profiling on an i386, I tried > using __attribute__ to put some code on the on-board memory, to no > avail. > > On the up-side, I've managed to reduce the audio buffer in my kernel > to 16k, and have noticed a bit of speed-up from 'allocating' the > libmad data structures after 0x4000800C. I guess playback is around 95% > speed now. Well, there are 2 things. One is to allocate the memory in the SRAM, and the other is to call routines with the stack there. Normally, Linus has one stack per process/thread, so you need to chose carefuly where/when to switch stack there. Then, what I'd do is to create a small asm trampoline that switches the stack, store the old stack pointer on the new stack (for the exit path), and jump to the routine that has to be executed on the internal stack. You could do that on a thread entry point for a whole thread to use that SDRAM stack for example. Ben |
|
From: Jonathan C. R. <jon...@ba...> - 2004-04-25 20:19:59
|
On Wed, 2004-04-21 at 02:12, Benjamin Herrenschmidt wrote: > On Tue, 2004-04-20 at 22:00, Bernard Leach wrote: > > > What we really need though is some kind of profiling on memory usage for the > > decoder. Perhaps something like the Armulator does this (or could be > > modified). If we knew a little more about the memory usage pattern then it > > would be easier to optimise usage of the fast ram. > > Also, the ARM ABI isn't very stack intensive (at least not as much as > m68k is) but it may still be a good optimisation to put the decoder > stack in the fastest memory type you have. > Hi Benjamin, I've been looking at the libmad code, and an awful lot of the calculation seems to take place on the stack... Your idea seems very good to me. How does one go about putting the stack somewhere else? I tried hacking an ld script but I must confess I'm a bit stuck... Either I don't understand the scripts at all, or arm-elf-ld doesn't like being told what to do. The same goes for moving some code: after profiling on an i386, I tried using __attribute__ to put some code on the on-board memory, to no avail. On the up-side, I've managed to reduce the audio buffer in my kernel to 16k, and have noticed a bit of speed-up from 'allocating' the libmad data structures after 0x4000800C. I guess playback is around 95% speed now. Cheers, Jonathan |
|
From: Benjamin H. <be...@ke...> - 2004-04-21 00:24:33
|
On Wed, 2004-04-21 at 17:26, Matthew J. Sahagian wrote: > Fair enough, but the search for the contiguous memory still seems like reimplementation. Even if you want a couple frames of 24 songs, you could easily split those frame and then use the sizes of those for your malloc call. Either way your ultimate goal it to just keep track of them with an index. so to speak. Then once someone flips to that song it rips those initial frames from the memory location and starts to read the rest off of the disk. Either way, my statement about reimplementing had to do with finding contiguous blocks of memory, which seems for the most part, unnecessary, assuming you have a good enough method for tracking where the initial frames are loaded. One idea I had originally was a RAMDISK (which would also seem to solve your problem rather easily (at least with whole songs). I was looking forward to a RAMDISk for various parts of podzilla -- including graphics that get displayed as part of the software. Maybe the RAMDISK could simply be pushed f! orw > ard for what you're going to use it for... not sure. I still wonder why you bother... use a ring buffer :) Ben. |
|
From: Benjamin H. <be...@ke...> - 2004-04-21 00:23:35
|
On Wed, 2004-04-21 at 07:36, Matthew J. Sahagian wrote:
> Forgive me if I'm mistaken about what you're trying to do, but would it ure
> be possible simply to get the songs chosen for play, and attempt to allocate
> memory per song, and just retain a list of where these songs are in memory
> and then point to those for playing? It seems sort of strange that you're
> trying to re-implement something that's technically built into the memory
> manager. If there is no contiguous block large enough to hold the mp3 then
> you could attempt to split, and store half in one part half in another,
> and continue to split until it does fit... just an idea.
It's a lot more easier imho to just have a ring buffer of MP3 data
chunks. One chunk can be a complete song, or a partial chunk (buffer
too full to store a complete chunk). The iPod can typically "wakeup"
when it's at about 20 seconds of buffer exhaustion to refill with the
next songs in the list (Provided the refilling can be done without
interrupting the playback, dunno if the dual CPU architecture allow
you that, I doubt your IDE can do DMA, can it ?)
>
> On Tue, 20 Apr 2004 09:46:11 +0200
> "Jonathan C. Ross" <jon...@ba...> wrote:
>
> > Hi Bernard et. al.,
> >
> > As mentioned before on the mailing list, I am working on a play
> > queue/multi song buffer, and incorporating mp3 playback into podzilla.
> > In the process, I have run into a problem with memory management. After
> > coding and testing on the host (works great with libmad!) I
> > cross-compiled and installed the app on my iPod. Upon initialisation I
> > allocate 16M for the buffer, but this fails on the iPod. (Okay, I
> > probably need to allocate several blocks instead of one chunk, because
> > there is definately more than 20 M free, albeit not contiguous.) I then
> > wrote a simple-minded programme to probe the maximum amount of
> > contiguous memory:
> >
> > int main()
> > {
> > int bytes = 1;
> > char* buffer;
> >
> > while (buffer = (char*) malloc(bytes * sizeof(char))) {
> > free(buffer);
> > printf ("success with %d bytes\n", bytes);
> > bytes <<=1;
> > }
> >
> > return 1;
> > }
> >
> > The app hangs after 64-512 bytes, with endless errors scrolling by on
> > the lcd display, too fast to read. I am invoking the app via telnet
> > with the 2.4.24-ipod0 kernel. I have not tried it standalone. As there
> > are examples of malloc in existing code, I can only presume that there
> > is a problem with free(), or that I am missing the point entirely... (I
> > haven't coded plain c in a couple of years).
> >
> > Anbody else seen this behaviour? If not, any pointers as to how I can
> > debug it? (Slowing down the console messages would be a start!)
> >
> > A quick update on my progress: I have built a standalone libmad app with
> > console input (play/pause/quit) and with a modest (1 song) buffer (using
> > mmap). This works fine on the iPod, except of course that it is not
> > 100% real time... (a couple of tweaks in the configuration of libmad did
> > improve matters drastically though! I still have hope...). Otherwise,
> > I have built a circular buffer for multiple-track caching into
> > Podzilla. Playback is incorporated into the main loop by decoding a
> > single frame in between each successive poll of the event loop.
> >
> > As soon as I have sorted out the allocation problems and tidied up the
> > code a little, I will post my patches.
> >
> > Thanks,
> > Jonathan.
> >
> > P.S. since I upgraded to the ipod0 kernel, I have not been able to ftp
> > -p 192.10.1.1 anymore. Anyone know what's going on there?
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > iPodlinux-devel mailing list
> > iPo...@li...
> > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> iPodlinux-devel mailing list
> iPo...@li...
> https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel
--
Benjamin Herrenschmidt <be...@ke...>
|
|
From: Benjamin H. <be...@ke...> - 2004-04-21 00:13:12
|
On Tue, 2004-04-20 at 22:00, Bernard Leach wrote: > What we really need though is some kind of profiling on memory usage for the > decoder. Perhaps something like the Armulator does this (or could be > modified). If we knew a little more about the memory usage pattern then it > would be easier to optimise usage of the fast ram. Also, the ARM ABI isn't very stack intensive (at least not as much as m68k is) but it may still be a good optimisation to put the decoder stack in the fastest memory type you have. |
|
From: Matthew J. S. <ge...@do...> - 2004-04-20 18:16:32
|
Fair enough, but the search for the contiguous memory still seems like reimplementation. Even if you want a couple frames of 24 songs, you could easily split those frame and then use the sizes of those for your malloc call. Either way your ultimate goal it to just keep track of them with an index. so to speak. Then once someone flips to that song it rips those initial frames from the memory location and starts to read the rest off of the disk. Either way, my statement about reimplementing had to do with finding contiguous blocks of memory, which seems for the most part, unnecessary, assuming you have a good enough method for tracking where the initial frames are loaded. One idea I had originally was a RAMDISK (which would also seem to solve your problem rather easily (at least with whole songs). I was looking forward to a RAMDISk for various parts of podzilla -- including graphics that get displayed as part of the software. Maybe the RAMDISK could simply be pushed forward for what you're going to use it for... not sure. On Tue, 20 Apr 2004 12:26:31 +0200 "Jonathan C. Ross" <jon...@ba...> wrote: > Hi, > > I think you're overlooking something here... What if the track exceeds > physical memory in size? (I don't know whether you've tried playing a > long movement of a symphony or an audio book with the patched > mp3example, but believe me, it won't work ;-) ). > > It's not like I'm trying to re-implement the functionality of the memory > manager anyway - I'm just trying to use it. My problem was encountered > when invoking free(). ( In the worst case, there is actually something > physically wrong with my iPod ;). ) > > The way I see it, we can copy Apple's caching mechanism - have 'up to 4 > songs cached' (i.e. around 16M), and even improve on it. The > improvement would be in caching the first couple of frames of a larger > number of songs - say, the next 12 songs, and the last 12. The > improvement here is that, in my experience, one tends to skip tracks > very frequently when playing large playlists. When you skip forward two > or three tracks you get a cache miss, and the unit hangs while the disk > spins up. By caching 'heads' of the songs, we'll have a much more > responsive play queue. > > Cheers, > Jonathan. > > On Tue, 2004-04-20 at 23:36, Matthew J. Sahagian wrote: > > Forgive me if I'm mistaken about what you're trying to do, > > but would it not be possible simply to get the songs > > chosen for play, and attempt to allocate memory per song, > > and just retain a list of where these songs are in memory > > and then point to those for playing? It seems sort of > > strange that you're trying to re-implement something > > that's technically built into the memory manager. > > If there is no contiguous block large enough to hold > > the mp3 then you could attempt to split, and store > > half in one part half in another, and continue to split > > until it does fit... just an idea. > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > iPodlinux-devel mailing list > iPo...@li... > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel > |
|
From: Bernard L. <le...@bo...> - 2004-04-20 12:01:09
|
"Jonathan C. Ross" <jon...@ba...> said: > Hi again, Bernard, > > > Whoa! The entire decoder should work directly in that memory! Isn't > ~16-32K enough for the DAC buffer? Should I just reduce DMA_BASE (in > audio.c) and then 'allocate' a decoder circular buffer somewhere after > that? I reckon having the decoder struct and the bit stream buffer in > the on-chip ram will be good enough, but perhaps we'll have to get the > Huffman tables and some of the code on there too... We'll see. I'm not sure of what good values would be. Some profiling/experimentation is needed. One reason the DAC buffer is even there in the first place is that the COP/CPU have separate data caches (non-snooped) so they can see inconsistent views of SDRAM, the chip ram isn't cached so there is no problem there. This could be fixed by cache flushing (I have the basics of that sorted but not-implemented) and then that buffer could be moved to sdram. Apple's firmware definitely sticks code in there (that looks like audio stuff) but I'm not sure. If you define a special linker segment for 0x40000000 and then relocate the decoder there that might be a good speedup. What we really need though is some kind of profiling on memory usage for the decoder. Perhaps something like the Armulator does this (or could be modified). If we knew a little more about the memory usage pattern then it would be easier to optimise usage of the fast ram. > Doing it in user space definitely makes sense for now - but when we've > gotten that working, I reckon it would be smart to actually move the > decoder to the kernel. We could use the AFMT_MPEG for the > SNDCTL_DSP_SETFMT call, looks quite clean to me... ( Why isn't there an > AFMT_OGG value defined in <linux/soundcard.h> ? ;) ) And then we could > migrate it to the COP so it could do something more than feeding the > DAC.... Sure, thats the long term plan. > Before I start work, which kernel/cvs-branch would you rather I worked > in? I haven't actually migrated to 2.6 yet; should I? 2.4. 2.6 is great except that it corrupts any disk you mount read-write ;) Most of the drivers are 1-1 copies sofar and will stay that way until the IDE is sorted (at which point 2.6 will becomee my dev platform). > Next question: how is the work on a mixer device coming? It would be > neat to have a prototype 'now playing' window with volume control within > the near future. Or is there an ioctl for accessing d2a_set_vol > directly? Last night I was working on audio recording, once that is working I'll add mixer support. It should be pretty easy as the only part missing is the Linux device plumbing that connects userspace to the d2a_set_vol. > > Regarding the big malloc problem that is a little strange. The patches in the > > mp3example player malloc up a chunk large enough for the entire file so you > > can definitely malloc more than 512 bytes. The uclinux 2.4 has a special slab > > allocator (non power of 2 version) which we use to allow big mallocs. (Sofar > > 2.6 doesn't have one so I'm not sure what the plan there is). > > Yeah, I saw the malloc() in the patch... I also didn't have any > problems with an mmap of ~7M in my prototype libmad code. My problem > seems to simply be related to successive malloc/free calls. It would be > good to know if anybody can reproduce this with the code I posted > earlier. Ok, that is strange. I'll give it a go next chance I get. Are you using a particular version of uclibc? Or just the one in the toolchain? Which toolchain version? It could be worth checking the uclibc and uclinux mailing lists. > Actually I'm not so sure I was using the 2.4.24-ipod kernel any more - I > remember installing it, hearing that the mp3example playback was worse > than in the rc2 kernel and then rolling back (I probably should have let > you know this when you did the release...) I'll try reproducing the > memory problem with various permutations of stand-alone, telnet and the > various kernels if I have the time, and tell you how I get on. What was the mp3example playback problem? I didn't realise there was any difference between rc2 and the final version there... Its possible that I upgraded my toolchain for the final version but I'm fairly sure I didn't. Anyhow I realise what a PITA that type of testing is but any info you come up with would be great. > > In /proc are some files which can give you some status on the memory > > subsystem. I can't remember their exact names but they should be fairly obvious. > > anything other than /proc/meminfo I should look for? ;) /proc/slabinfo and there is a new uclinux one that shows the memory map. > > As for the -ipod0 and ftp problems the default ip address changed to > > 192.168.222.2, maybe that is causing you some problems? > > Well, as I can connect, run ls/cd etc.. No, I don't think the IP > address is the problem. All works fine except for the actual transfer. > Again, this is actually with the rc2 kernel, not 2.4.24-ipod. Oh, strange again. I normally use wget from the iPod to fetch stuff from the PC with http. I'll try with ftp... cheers, bern. |
|
From: Jonathan C. R. <jon...@ba...> - 2004-04-20 11:36:32
|
Hi again, Bernard, On Tue, 2004-04-20 at 10:43, Bernard Leach wrote: > sounds like you're making some really good progress there! It would be really > neat if we could get libmad decoding at full speed. The big win there will > probably be if we can move some of the data that is accessed frequently into > the on-chip ram. The only question is which data to move. Currently the > onchip ram is used as a circular buffer for buffering data that is to be > written to the DAC (the CPU is a produced and the COP a consumer on this > buffer). At the moment it is using the entire 96K for that purpose so if that > were reduced then some could be used by the user process. (E.g. just create a > pointer to 0x40000000 somewhere ;)). Whoa! The entire decoder should work directly in that memory! Isn't ~16-32K enough for the DAC buffer? Should I just reduce DMA_BASE (in audio.c) and then 'allocate' a decoder circular buffer somewhere after that? I reckon having the decoder struct and the bit stream buffer in the on-chip ram will be good enough, but perhaps we'll have to get the Huffman tables and some of the code on there too... We'll see. Doing it in user space definitely makes sense for now - but when we've gotten that working, I reckon it would be smart to actually move the decoder to the kernel. We could use the AFMT_MPEG for the SNDCTL_DSP_SETFMT call, looks quite clean to me... ( Why isn't there an AFMT_OGG value defined in <linux/soundcard.h> ? ;) ) And then we could migrate it to the COP so it could do something more than feeding the DAC.... Before I start work, which kernel/cvs-branch would you rather I worked in? I haven't actually migrated to 2.6 yet; should I? Next question: how is the work on a mixer device coming? It would be neat to have a prototype 'now playing' window with volume control within the near future. Or is there an ioctl for accessing d2a_set_vol directly? > Regarding the big malloc problem that is a little strange. The patches in the > mp3example player malloc up a chunk large enough for the entire file so you > can definitely malloc more than 512 bytes. The uclinux 2.4 has a special slab > allocator (non power of 2 version) which we use to allow big mallocs. (Sofar > 2.6 doesn't have one so I'm not sure what the plan there is). Yeah, I saw the malloc() in the patch... I also didn't have any problems with an mmap of ~7M in my prototype libmad code. My problem seems to simply be related to successive malloc/free calls. It would be good to know if anybody can reproduce this with the code I posted earlier. Actually I'm not so sure I was using the 2.4.24-ipod kernel any more - I remember installing it, hearing that the mp3example playback was worse than in the rc2 kernel and then rolling back (I probably should have let you know this when you did the release...) I'll try reproducing the memory problem with various permutations of stand-alone, telnet and the various kernels if I have the time, and tell you how I get on. > In /proc are some files which can give you some status on the memory > subsystem. I can't remember their exact names but they should be fairly obvious. anything other than /proc/meminfo I should look for? ;) > As for the -ipod0 and ftp problems the default ip address changed to > 192.168.222.2, maybe that is causing you some problems? Well, as I can connect, run ls/cd etc.. No, I don't think the IP address is the problem. All works fine except for the actual transfer. Again, this is actually with the rc2 kernel, not 2.4.24-ipod. Catch you soon, Jonathan. |
|
From: Jonathan C. R. <jon...@ba...> - 2004-04-20 10:26:47
|
Hi, I think you're overlooking something here... What if the track exceeds physical memory in size? (I don't know whether you've tried playing a long movement of a symphony or an audio book with the patched mp3example, but believe me, it won't work ;-) ). It's not like I'm trying to re-implement the functionality of the memory manager anyway - I'm just trying to use it. My problem was encountered when invoking free(). ( In the worst case, there is actually something physically wrong with my iPod ;). ) The way I see it, we can copy Apple's caching mechanism - have 'up to 4 songs cached' (i.e. around 16M), and even improve on it. The improvement would be in caching the first couple of frames of a larger number of songs - say, the next 12 songs, and the last 12. The improvement here is that, in my experience, one tends to skip tracks very frequently when playing large playlists. When you skip forward two or three tracks you get a cache miss, and the unit hangs while the disk spins up. By caching 'heads' of the songs, we'll have a much more responsive play queue. Cheers, Jonathan. On Tue, 2004-04-20 at 23:36, Matthew J. Sahagian wrote: > Forgive me if I'm mistaken about what you're trying to do, > but would it not be possible simply to get the songs > chosen for play, and attempt to allocate memory per song, > and just retain a list of where these songs are in memory > and then point to those for playing? It seems sort of > strange that you're trying to re-implement something > that's technically built into the memory manager. > If there is no contiguous block large enough to hold > the mp3 then you could attempt to split, and store > half in one part half in another, and continue to split > until it does fit... just an idea. |
5 messages has been excluded from this view by a project administrator.
