Re: building bootloader from source (h300)
For me the most important one is the possibility to handle the startup with my non-LCD remote... That works fine with the bootloader I'm using, (r14938M). That's another reason to release an updated bootloader version ;) regards, Matthias (aka Massa)
Re: building bootloader from source (h300)
Hi Daniel, it would still be nice to have solved some of the problems in the released bootloader. What issues are there currently? Look at http://www.rockbox.org/twiki/bin/view/Main/IriverBoot#H320_H340 There is a table with known issues and other TODOs and which already have been fixed / added in SVN. For me the most important one is the possibility to handle the startup with my non-LCD remote... with regards, Matthias
Re: building bootloader from source (h300)
For me the most important one is the possibility to handle the startup with my non-LCD remote... That works fine with the bootloader I'm using, (r14938M). pondlife
Re: building bootloader from source (h300)
On Wed, 9 Apr 2008, Matthias Mohr wrote: Hi Daniel, it would still be nice to have solved some of the problems in the released bootloader. What issues are there currently? Look at http://www.rockbox.org/twiki/bin/view/Main/IriverBoot#H320_H340 There is a table with known issues and other TODOs and which already have been fixed / added in SVN. I shall look... Shouldn't that stuff be in flyspray? For me the most important one is the possibility to handle the startup with my non-LCD remote... OK. I don't have one of those remotes though. -- Daniel Dalton http://members.iinet.net.au/~ddalton/ [EMAIL PROTECTED]
Re: building bootloader from source (h300)
On Mon, 7 Apr 2008, Dominik Riebeling wrote: What equipment is needed? And what is the process of unbricking a h300? Is it a long and complicated process...? You need to access the debug module of the CPU from outside, i.e. via hardware. Freescale calls this part of the hardware BDM (Background Debug Module), other manufacturers often call it JTAG (though JTAG itself is only the working group, usually it refers to IEEE 1149.1). A device for accessing this hardware port is usually processor-specific (at best family-specific) and usually not too cheap. A starting point for reading up is Sounds complicated. Not sure I'll go to all that effort since I guess I will need a lot of sighted help... I should probably stick to voice hacks instead of testing unstable bootloaders... Although I haven't done much work for around 6 months and not sure when I will be doing any more... I don't think it will be soon though sadly. http://en.wikipedia.org/wiki/In-circuit_emulator in case you're interested. I'll take a look. sure. In case of the H300 this means you need to open the player and solder several wires to connect the BDM. Due to the size of actual circuits this isn't an easy task even for sighted people. Yes I can imagine... I'm just ok at soldering... So not prepaired to start soldering my h300, I'll probably do something terribly wrong... :-) -- Daniel Dalton http://members.iinet.net.au/~ddalton/ [EMAIL PROTECTED]
Re: building bootloader from source (h300)
On Mon, 7 Apr 2008, Nils wrote: Is there a way to extract a usable copy of the existing bootloader first? Having changed PCs I've misplaced both the h300.hex file and the list of which modifications I included. pondlife Dump ROM contents creates a 4MiB bin file in the root, just scramble it again and the of should be able to flash it. Oh so I just get the bin file and basically use the instructions on the wiki to create a new hex file? That will work just like before? And it will support the dual boot and alarm and everything? I did the same thing, I went to linux and missed placed my hex file... The scramble script is in the tools directory? -- Daniel Dalton http://members.iinet.net.au/~ddalton/ [EMAIL PROTECTED]
Re: building bootloader from source (h300)
On Mon, 7 Apr 2008, Linus Nielsen Feltzing wrote: pondlife wrote: But not for my H300... I have the same 80GB drive as petur (I think, mine's a Toshiba MK8007GAH), and am happily using r14938M (modified, but I can't recall how - probably just the RTC alarm now you mention it). Hmmm, so it *might* be an issue with petur's device rather than a general Rockbox bug? In that case, we should perhaps consider releasing it after all. Yes. Does anyone else see this issue? Do other versions (older revs) work on his player? -- Daniel Dalton http://members.iinet.net.au/~ddalton/ [EMAIL PROTECTED]
Re: building bootloader from source (h300)
On Tue, 8 Apr 2008, Nils wrote: though, that said I don't know why you would want to do this (I might have misunderstood). It would be much easier/safer to get a fresh .hex file and Because I lost my .hex file for the alarm... (alarm support in the bootloader...) so it can wakeup the player. Anyway I guess I could just build it from source. I thought that would have been easier than compiling... Oh well when I need to do this I'll just build it from source... patch that. Well now you say this I guess I could use something from svn... -- Daniel Dalton http://members.iinet.net.au/~ddalton/ [EMAIL PROTECTED]
Re: building bootloader from source (h300)
Because I lost my .hex file for the alarm... (alarm support in the bootloader...) so it can wakeup the player. If you want I can send you my known-working bootloader.
Re: building bootloader from source (h300)
On Wed, 9 Apr 2008, XavierGr wrote: Because I lost my .hex file for the alarm... (alarm support in the bootloader...) so it can wakeup the player. If you want I can send you my known-working bootloader. Yes please. Could you also send along a sha1 check sum? And will this be a hex file patched with the rockbox bootloader and the OF? Thanks, -- Daniel Dalton http://members.iinet.net.au/~ddalton/ [EMAIL PROTECTED]
Re: building bootloader from source (h300)
pondlife wrote: But not for my H300... I have the same 80GB drive as petur (I think, mine's a Toshiba MK8007GAH), and am happily using r14938M (modified, but I can't recall how - probably just the RTC alarm now you mention it). Hmmm, so it *might* be an issue with petur's device rather than a general Rockbox bug? In that case, we should perhaps consider releasing it after all. Linus
Re: building bootloader from source (h300)
On Mon, 7 Apr 2008, Peter D'Hoye wrote: Maybe I can abuse Linus to test changes on his BDM equipped player ;) Hey, that's not abuse, that's our regular use! ;-) -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: building bootloader from source (h300)
On Mon, Apr 7, 2008 at 11:45 AM, pondlife [EMAIL PROTECTED] wrote: you'd have to try current svn to be really sure though... the svn version at the time of devcon07 booted 50% of the time, the newer ones less, so the behaviour changes with revisions Sure, I'll give it a go tonight, hopefully. Is there a way to extract a usable copy of the existing bootloader first? Having changed PCs I've misplaced both the h300.hex file and the list of which modifications I included. pondlife Dump ROM contents creates a 4MiB bin file in the root, just scramble it again and the of should be able to flash it.
Re: building bootloader from source (h300)
On Mon, Apr 7, 2008 at 12:18 AM, Daniel Dalton [EMAIL PROTECTED] wrote: That is the problem. You can't reanimate a bricked h300 without special equipment. What equipment is needed? And what is the process of unbricking a h300? Is it a long and complicated process...? You need to access the debug module of the CPU from outside, i.e. via hardware. Freescale calls this part of the hardware BDM (Background Debug Module), other manufacturers often call it JTAG (though JTAG itself is only the working group, usually it refers to IEEE 1149.1). A device for accessing this hardware port is usually processor-specific (at best family-specific) and usually not too cheap. A starting point for reading up is http://en.wikipedia.org/wiki/In-circuit_emulator in case you're interested. In case of the H300 this means you need to open the player and solder several wires to connect the BDM. Due to the size of actual circuits this isn't an easy task even for sighted people. - Dominik
Re: building bootloader from source (h300)
Hi Daniel, Also, if the svn has a bug in the bootloader, it can make your target unbootable even if it's not your fault. That's why Rockbox releases bootloader. The last released H300 bootloader is from july, 2006! Regarding the TODO list at the above page, a lot of things have been fixed since then. So it would be really nice if somebody (who is able to reanimate a bricked device) would be able to test a current SVN bootloader and create a new release. Unfortunately it seems that only Linus is able to do this - and it seems he doesn't have enough time or isn't in the mood to do it... Wouldn't this be something for a developer meeting? Developers want to make sure that a specific and tested bootloader will be issued to all users. So be extra careful before attempting anything. If you still want to try it - please report about your attemptions and results ;) with regards, Matthias (aka Massa)
Re: building bootloader from source (h300)
Matthias Mohr wrote: Unfortunately it seems that only Linus is able to do this - and it seems he doesn't have enough time or isn't in the mood to do it... The thing is that the current SVN bootloader still has issues with some hard drives, and I don't want to release a bootloader that doesn't work. Unfortunately, none of my players experience this problem, so I am depending on others to resolve this issue. Linus
Re: building bootloader from source (h300)
Unfortunately it seems that only Linus is able to do this - and it seems he doesn't have enough time or isn't in the mood to do it... The thing is that the current SVN bootloader still has issues with some hard drives, and I don't want to release a bootloader that doesn't work. Unfortunately, none of my players experience this problem, so I am depending on others to resolve this issue. Yes I know I should put some more time to check this but it is not simple (both time wise and debugging it). It looked like a timing issue, but it turned out that adding debug prints merely changed the timing in a subtle way for the bug to happen more or less. Adding sleeps does not do this, in fact I can add sleeps at certain points and get a nice crash. When it crashes, it is always in threading code, giving me I03 or I04 (AddrErr and IllInstr) in thread.o or its data area. Will try to debug it some more, could use some hints though ;) Peter
Re: building bootloader from source (h300)
Hi Linus, The thing is that the current SVN bootloader still has issues with some hard drives, and I don't want to release a bootloader that doesn't work. And the released bootloader don't have this issues? - If they also have the issues, the SVN bootloader should still be better than the old release - so making a new release would not solve all issues, but it would still be nice to have solved some of the problems in the released bootloader. - If they don't have the issues - an analysis of the differences could possibly show where the problem is. Unfortunately, none of my players experience this problem, so I am depending on others to resolve this issue. If the risk of bricking my device isn't big (or if it's possible for me to reanimate a bricked H300) I would try to put a current SVN version of the bootloader on my device... Matthias
Re: building bootloader from source (h300)
Matthias Mohr wrote: If the risk of bricking my device isn't big (or if it's possible for me to reanimate a bricked H300) I would try to put a current SVN version of the bootloader on my device... That is the problem. You can't reanimate a bricked h300 without special equipment. Linus
Re: building bootloader from source (h300)
If the risk of bricking my device isn't big (or if it's possible for me to reanimate a bricked H300) I would try to put a current SVN version of the bootloader on my device... I wouldn't say that the risk is very high, but it is there. In the past I tried to enable H110 flashing so I had to compile and flash various bootloaders. I discovered an error that couldn't load the rockbox firmware but hopefully I could boot on OF and reflash. After that I saw that the exact same issue was present for the H300. I flashed my H110 and H300 more than 20 times at that point and at all times I could boot to OF and save the unit. Luckily the code that boots to OF is in very early stages so I guess it is more bug resistant. That shows that you have to be very very unlucky to brick it, still... a chance is a chance so I can't recommend flashing it, because if it fails you will come after me. :P On a side note: Last working svn bootloader I built for me and about 7 (IIRC) people, was r14945 (with added alarm support).
Re: building bootloader from source (h300)
On Sun, 6 Apr 2008, XavierGr wrote: On a side note: Last working svn bootloader I built for me and about 7 (IIRC) people, was r14945 (with added alarm support). Does that revission contain any bugs what so ever in the bootloader code? Like does it work with all the different hard drives or whatever? Or has this bug been introduced? If it worked fine for everyone, then couldn't we just find the rev that contained the bug and revert the diff? Or look for errors in the diff? -- Daniel Dalton http://members.iinet.net.au/~ddalton/ [EMAIL PROTECTED]
Re: building bootloader from source (h300)
On Sun, 6 Apr 2008, Matthias Mohr wrote: Hi Linus, The thing is that the current SVN bootloader still has issues with some hard drives, and I don't want to release a bootloader that doesn't work. And the released bootloader don't have this issues? - If they also have the issues, the SVN bootloader should still be better thanthe old release - so making a new release would not solve all issues, but it would still be nice to have solved some of the problems in the released bootloader. What issues are there currently? - If they don't have the issues - an analysis of the differences could possibly show where the problem is. I thought the same, couldn't we just do an svn diff from the broken rev to the good and working rev? Unfortunately, none of my players experience this problem, so I am depending on others to resolve this issue. If the risk of bricking my device isn't big (or if it's possible for me to reanimate a bricked H300) I would try to put a current SVN version of the bootloader on my device... I'm not doing it for that reason, I believe you need certain equipment to do this and I would imagine it would be a complicated process. Being totally blind myself, if it requires me to open the player and be looking for different connectors on the mother board I think I would have some trouble... -- Daniel Dalton http://members.iinet.net.au/~ddalton/ [EMAIL PROTECTED]
Re: building bootloader from source (h300)
On 07/04/2008, Daniel Dalton [EMAIL PROTECTED] wrote: On Sun, 6 Apr 2008, XavierGr wrote: Does that revission contain any bugs what so ever in the bootloader code? Like does it work with all the different hard drives or whatever? Or has this bug been introduced? If it worked fine for everyone, then couldn't we just find the rev that contained the bug and revert the diff? Or look for errors in the diff? Actually you are among those users Daniel, I gave you a prepatched firmware with this bootloader in IRC some weeks ago. The bug that petur encounters is still there, but AFAIK it only appears with an 80GB drive. What equipment is needed? And what is the process of unbricking a h300? Is it a long and complicated process...? I would say forget it. Even sighted people will have trouble doing it. I, for myself, don't have either the equipment needed or the knowledge.
building bootloader from source (h300)
I have an iriver h320, do I build the bootloader from source like this? ../tools/configure 11 b make Or does make want a special argument? Then what is the output file called? And then do I just need to patch this file into an iriver firmware? Is it safe currently to build the bootloader from the latest svn? Thanks, -- Daniel Dalton http://members.iinet.net.au/~ddalton/ [EMAIL PROTECTED]
