| 00:01:49 | pamaury | yeah, except for confused users |
| 00:02:44 | Mihail | many user still don't know how boot OF or bootloader USB :) |
| 00:03:59 | [Saint] | well, that's our fault, to be honest. |
| 00:04:02 | [Saint] | not theirs. |
| 00:06:56 | pamaury | Most users don't even know what it means to unpack a zip at the root of the device |
| 00:07:27 | pamaury | I can only imagine what happens when they extract it on the microsd, and then it boots it, and then update the one main storage, but then it keeps booting from sd. |
| 00:07:38 | pamaury | I think this is a good feature for advanced users |
| 00:07:52 | pamaury | I'm just worried about the consequences for other users |
| 00:08:10 | [Saint] | "Rockbox kicked my dog" |
| 00:09:15 | Mihail | it easy recovery way, so it should be easy for use by end users |
| 00:10:06 | [Saint] | "should be easy" is a bit of a misconception from our point of view I think. |
| 00:10:23 | [Saint] | I met a guy yesterday that didn't know context menus existed. |
| 00:10:29 | pamaury | in any case, what I 200% agree is that it should be as easy as extract the zip to sd card |
| 00:10:36 | * | [Saint] nods |
| 00:10:43 | Mihail | it can help update rockbox even with broken usb |
| 00:10:44 | pamaury | ie no funny renaming involved |
| 00:13:41 | [Saint] | Mihail: that's a very good point... |
| 00:13:55 | [Saint] | I think this is going to get _very_ fucky for Android. |
| 00:14:07 | [Saint] | But, to be perfectly honest, I don't see why we still build that. |
| 00:14:11 | | Quit skapazzo (Quit: leaving) |
| 00:14:35 | [Saint] | In Android "internal", "external", and "sdcard" are all very ambiguous and not easily detectable things. |
| 00:15:03 | [Saint] | "sdcard" is basically meaningless in Android, and internal and external storage almost equally so. |
| 00:16:00 | [Saint] | so if this was to go global if anyone wanted to pretend Android didn't exist I wouldn't blame them. |
| 00:16:00 | [Saint] | Not one bit. |
| 00:16:15 | pamaury | it won't apply to app |
| 00:16:22 | pamaury | they don't even have a bootloader usually |
| 00:28:04 | | Join thehyde [0] (~martin@x4d04dd14.dyn.telefonica.de) |
| 00:28:21 | | Quit [Saint] (Remote host closed the connection) |
| 00:29:56 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
| 00:36:27 | | Quit Mihail (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 00:37:45 | | Quit thehyde (Ping timeout: 276 seconds) |
| 00:39:40 | | Quit pamaury (Ping timeout: 258 seconds) |
| 00:46:20 | | Quit edhelas (Quit: Leaving.) |
| 00:50:14 | *** | Saving seen data "./dancer.seen" |
| 00:57:47 | | Join alexweissman [0] (~alexweiss@149-160-165-164.dhcp-bl.indiana.edu) |
| 00:59:44 | | Quit xorly (Ping timeout: 264 seconds) |
| 01:00 |
| 01:02:18 | | Quit alexweissman (Ping timeout: 255 seconds) |
| 01:04:18 | | Join Bilgus_ph [0] (~Bilgus_ph@108.120.221.214) |
| 01:04:21 | | Quit Bilgus_ph (Remote host closed the connection) |
| 01:15:37 | | Quit ender` (Quit: It is the nature of the human species to reject what is true but unpleasant and to embrace what is obviously false but comforting. — H.L. Mencken) |
| 01:20:26 | | Quit Acou_Bass (Ping timeout: 240 seconds) |
| 01:33:32 | | Join thehyde [0] (~martin@x4d04dd14.dyn.telefonica.de) |
| 01:38:08 | | Quit __builtin (Ping timeout: 256 seconds) |
| 01:38:48 | | Join __builtin [0] (~xray@rockbox/developer/builtin) |
| 01:42:47 | | Quit thehyde (Ping timeout: 255 seconds) |
| 01:53:43 | | Quit girafe (Read error: Connection reset by peer) |
| 01:53:45 | | Quit MrZeus (Ping timeout: 255 seconds) |
| 02:00 |
| 02:05:46 | | Quit ZincAlloy (Quit: Leaving.) |
| 02:06:01 | Bilgus_ | well I think we should have a define for Boot from sd capable devices in config anyways |
| 02:39:19 | | Join thehyde [0] (~martin@x4d04dd14.dyn.telefonica.de) |
| 02:40:35 | [Saint] | Bilgus_: I don't think so, honestly. |
| 02:40:50 | [Saint] | And, let me explain my rationale for this before you bite at it. |
| 02:41:19 | [Saint] | I don't think there's any reason to have a define for this for a couple of reasons, but I can roll them in to one: |
| 02:41:51 | [Saint] | - If properly implemented, there would be no want or need to ever disable it, and it should be enabled by default. |
| 02:43:11 | [Saint] | If this was done in a sane, safe, and reliable fashion there wouldn't ever be any need to disable it. |
| 02:44:21 | [Saint] | If properly implemented users who are using the conventional (current) layout would see absolutely no difference in behavior even if they did update their bootloader and Rockbox binaries. |
| 02:44:21 | | Quit chrisjj (Quit: Page closed) |
| 02:44:37 | Bilgus_ | well then make a define to allow it to be disabled then I'm sure there will/are targets where it won't work |
| 02:45:16 | [Saint] | Again if properly implemented there would be no need for this in my opinion. |
| 02:45:34 | [Saint] | The logic for it would handle this automatically, and it would behave exactly as it does now. |
| 02:46:19 | [Saint] | I really see no need for this behavior to have a compile time define. |
| 02:46:28 | | Join Acou_Bass [0] (~Acou_Bass@host-89-241-250-248.as13285.net) |
| 02:46:37 | [Saint] | It doesn't even need to have a user facing setting. |
| 02:47:33 | | Quit thehyde (Ping timeout: 240 seconds) |
| 02:48:29 | | Quit gbl08ma (Remote host closed the connection) |
| 02:49:14 | [Saint] | If there's something you think I'm missing, then by all means, I would like to hear it. |
| 02:49:14 | [Saint] | I think if this was implemented properly users should see no difference in behavior at all, the only meaningful difference would be where either they or RbUtil elects to extract the Rockbox archive to. |
| 02:50:15 | *** | Saving seen data "./dancer.seen" |
| 02:51:22 | [Saint] | If the logic is robust enough for this function to be safe and useful, and to make it into RbUtil, RoLo, and the bootloaders of almost all targets with external storage...which it damn well should be, then it should default to being enabled. |
| 02:52:03 | [Saint] | With a thing like this, by the time you _need_ it to be enabled, there's a very good chance on some targets that you wouldn't be able to do so. |
| 02:52:46 | [Saint] | So it should just be enabled by default, seeing as how users will see no immediate difference if they continue to use their device and update it as they were. |
| 02:59:28 | Bilgus_ | agree but pamaury does have a point in needing an option to not do it presented to user I think even a countdown press anykey to stop external load |
| 03:00 |
| 03:03:11 | [Saint] | I really don't think either of you thought about that very hard. |
| 03:03:29 | [Saint] | There's absolutely no way to do that with a user facing setting and it should be very obvious as to why. |
| 03:03:50 | Bilgus_ | also once it is done uploading here is a dump of the Theme site for anyone desperate enough to download it (172 MB) (all downloads work from index.htm) if you click on the theme and try to download the link needs changed to .zip eg. download(716).htm > download(716).zip https://www.mediafire.com/folder/bkjpq1ifshc4z/THEME_DUMP |
| 03:04:32 | [Saint] | It would still require manual intervention to get the Rockbox binaries onto the opposing storage anyway, and the logic should be smart enough to have sane fallbaks precisely so the user doesn't have to think about it. |
| 03:04:33 | Bilgus_ | the bootloader has buttons and printf I'm not finding it obvious as to why? |
| 03:04:56 | [Saint] | Because you would need to put the Rockbox binaries onto the opposing storage manually. |
| 03:05:10 | Bilgus_ | so essentially the user chooses to place it on the storage therefore it is their choice? |
| 03:05:28 | [Saint] | just having a switch that says "boot from here" is meaningless if there's no binaries in "here" to boot from. |
| 03:05:38 | Bilgus_ | in that case I think it needs to only work if in the .rockbox folder and not on root |
| 03:05:56 | [Saint] | thew logic should be smart enough to just derive what to boot from based on the presence or absence of binaries in either storage. |
| 03:06:08 | Bilgus_ | no I was suggesting it only pop up a prompt if there was one found in addition to internal storage |
| 03:06:16 | [Saint] | and to default to external in the case where there's binaries present in both. |
| 03:06:47 | [Saint] | well, I see that as part of "being properly implemented" and something the user has no business being involved in personally. |
| 03:06:57 | [Saint] | It should be entirely transparent to them. |
| 03:07:37 | Bilgus_ | entirely transparent could cause some very confused users |
| 03:08:04 | Bilgus_ | It needs to at least Say BOOTING FROM <MICROSD1>\ |
| 03:08:11 | [Saint] | so: boot from the storage medium that contains the Rockbox binaries by default, and boot from external if there's Rockbox binaries contained in both internal and external. |
| 03:08:39 | [Saint] | because if you think about it the user may have lost the ability to be able to trivially access the internal storage, despite it containing Rockbox binaries. |
| 03:09:11 | [Saint] | So they should be able to just eject the removable storage, extract an archive to it, pop it back in, and have it "Just Work". |
| 03:09:48 | [Saint] | I think settings because settings are more confusing than potentially ambiguous behavior that required some degree of manual intervention to make happen in the first place. |
| 03:10:01 | Bilgus_ | I still think there should be Booting from SD in 3 2 1 hold select to cancel |
| 03:11:06 | [Saint] | there's a non-zero chance that would be engaged accidentally. |
| 03:11:19 | Bilgus_ | and whats the harm? |
| 03:11:57 | [Saint] | The logic to ensure that only happens when there are Rockbox binaries detected on both storage mediums would bloat out the bootloader needlessly. |
| 03:11:57 | Bilgus_ | It boots to internal and implodes? |
| 03:12:28 | [Saint] | In my opinion if a user has set up to be able to boot from external stoage it would have required very deliberate and manual intervention anyway. |
| 03:12:52 | [Saint] | We don't need to babysit the users 24/7, give them /some/ credit. |
| 03:13:17 | Bilgus_ | PPPPBBBtttt |
| 03:13:23 | Bilgus_ | yeah lol |
| 03:13:44 | [Saint] | The very obvious downside is that unless you add yet another user facing setting that has no good reason to exist, you're delaying boot by an order of magnitude. |
| 03:14:11 | Bilgus_ | true it would delay in case of external fw detected |
| 03:14:14 | [Saint] | boot takes miliseconds, and you want to extend it to, to actually be useful, multiple seconds...just because you don't trust the user. |
| 03:14:42 | [Saint] | To give them enough time to jump on it, you'd be talking at least 10 seconds. |
| 03:15:00 | [Saint] | three seconds is not an appropriate amount of time for such a function. |
| 03:15:33 | Bilgus_ | it's instant without a way to stop it |
| 03:15:37 | [Saint] | It also can't be voiced or displayed in a meaningful way to visually impaired users. |
| 03:16:28 | [Saint] | and, yeah, it would be. we need to make the assumption that if the necessary requirements for this to even happen have occured, that it is deliberate. |
| 03:16:35 | Bilgus_ | neither can the fact that it is booting externally |
| 03:16:57 | [Saint] | but again, that revolves around very deliberate user action. |
| 03:17:37 | [Saint] | I just see this as being needlessly annoying for the majority of users who frankly will not give a flying fuck that this feature exists. |
| 03:17:37 | Bilgus_ | I'm just thinking of the case where I have an install on my SD card to copy to the device and I can't because it keeps booting the damn thing |
| 03:18:06 | [Saint] | to /maybe/ benefit the users who do want it to exist, who if they do want or need it to exist, are perfectly capable of managing it. |
| 03:18:35 | Bilgus_ | then make them have a dummy file liek BOOTFROMHERE |
| 03:18:53 | [Saint] | Bilgus_: why would you not be able to? are you still thinking of disabling the alternate storage (the one you didn't boot from) for some ungodly reason? |
| 03:19:32 | [Saint] | there's absolutely no logical reason for the situation you just presented to occur. |
| 03:20:58 | * | [Saint] swears that sometimes he's the only one that actually bothers thinking about UX and how these esoteric settings that like...two people are ever going to use, are going to negatively affect the majority of people who won't ever use it |
| 03:21:05 | Bilgus_ | hmm I suppose it would still be possible I was thinking more along the lines of a file in use |
| 03:21:38 | Bilgus_ | nah if you didn't have an install on the SD card you would never even know |
| 03:22:01 | Bilgus_ | even if it was a 60 second delay |
| 03:22:29 | Bilgus_ | you are double talking there on one hand its only user intervention and then its everyone |
| 03:22:48 | [Saint] | No, I'm not. |
| 03:23:51 | Bilgus_ | ok so we have joe user with RB on internal he boots and it acts like normal then we have joseph user that puts rb on his external drive it boots and asks him if he wants to boot from his internal instead? |
| 03:24:33 | Bilgus_ | joe could give a flying fuck because as far as he knows the feature doesn't exist at all |
| 03:24:59 | [Saint] | I'm saying that the majority of people are literally never going to make use of this. I don't honestly think that can be disputed by any rational person. I am /also/ saying that those who are going to make use of this feature, are those who are perfectly capable and won't need their hands held, and won't be surprised or need a user-facing way out if it happens when they don't intend it to. |
| 03:25:13 | [Saint] | Because the fact that it is able to happen should be a very deliberate thing. |
| 03:25:53 | Bilgus_ | then you have chris who for some ungodly reason carries an install around on his sd card he places it in and it boots to the external and he spews all over flyspray how it never even prompted him |
| 03:27:01 | [Saint] | But he wouldn't, though, because he wouldn't even know it happened unless he payed very close attention, and the behavior would be absolutely identical. |
| 03:27:30 | [Saint] | the only things that should display that this happened are a very quick flash during the bootloader, and the debug menu. |
| 03:27:46 | Bilgus_ | I'd be happy enough with that |
| 03:28:02 | [Saint] | you could pretty easily deploy logic to prevent it from downgrading itself. |
| 03:28:26 | [Saint] | but that I'd be willing to accept /might/ need a user-facing setting to allow it to be overridden. |
| 03:29:03 | [Saint] | also - chris, lol...lets pretend that was a totally random name. ;) |
| 03:29:32 | Bilgus_ | thin air |
| 03:30:38 | [Saint] | I think there is a very good reason to present a user facing prompt in the bootloader if the installation is being downgraded. |
| 03:31:08 | [Saint] | ie. if there are binaries on both internal and external storage, and the version on external storage is older than the version on internal. |
| 03:31:20 | [Saint] | that complicates matters but I think it is a valuable distinction to make. |
| 03:31:23 | Bilgus_ | how in the world will you check that though |
| 03:31:35 | Bilgus_ | parse the FW? |
| 03:32:06 | Bilgus_ | well I suppose we know the offset |
| 03:32:34 | [Saint] | Well...we know it for any given binary after the fact, but we can't predict it reliably. |
| 03:32:59 | Bilgus_ | would it really matter though you'd just have to pull ext to 'upgrade' |
| 03:33:02 | [Saint] | I was thinking much simpler, and just reading from the rockboxinfo plaintect file in .rockbox |
| 03:33:24 | Bilgus_ | thats a pretty flaky mechinism |
| 03:33:45 | [Saint] | That should be relatively safe to rely on as long as the user doesn't do a piece-meal upgrade and only replace rockbox.* |
| 03:34:14 | [Saint] | and if the user only upgrades the main binary and nothing else pretty much everything else will be broken anyway. |
| 03:34:38 | [Saint] | Joe User would never accidentally only upgrade the main binary. |
| 03:35:34 | [Saint] | But I guess we could append a couple of bytes for an independent version string to the main rockbox.$device binary. |
| 03:35:49 | [Saint] | then we would be able to predict the offset with absolute precision. |
| 03:36:22 | [Saint] | just, say, minus four bytes from the end of the main binary. |
| 03:36:32 | Bilgus_ | probably a good IDea just have to be a magic string so we could detect absence |
| 03:37:00 | Bilgus_ | Or integrate it into the checksum since we already pull it |
| 03:37:06 | [Saint] | yeah, I was just going to say that then it works as well even if that string wasn't present. |
| 03:37:18 | [Saint] | because we could derive that the binary was older solely from the absence of it. |
| 03:38:01 | [Saint] | It might be an edge case, but I think that making sure that the user actually does want to boot a downgraded Rockbox is a valuable distinction to make. |
| 03:38:57 | [Saint] | I'm thinking about more in terms of the fairly distant future, where it might be possible for the user to hotswap sdcards that may contain a much older .rockbox |
| 03:39:29 | [Saint] | and there's no way of knowing whether or not their operating system, or even Rockbox itself, would be configured to display the hidden file(s) to them. |
| 03:39:58 | [Saint] | so...like, a couple of years from now when this is a long established feature I mean. |
| 03:40:22 | [Saint] | If a user was to exchange sdcards for whatever reason and it had a .rockbox folder on it already. |
| 03:40:41 | [Saint] | We would need to be able to ensure that the downgrade was communicated to the user in an obvious way. |
| 03:41:02 | [Saint] | I would even maybe go so far as to halt boot entirely until the user confirmed it. |
| 03:41:11 | [Saint] | As opposed to having a countdown. |
| 03:42:19 | [Saint] | Appending a few bytes to the end of the rockbox.$device binary isn't going to meaningfully affect the binsize in such a way that it is going to prevent any targets that are capable of making use of this from booting. |
| 03:43:24 | Bilgus_ | probably a good idea to have version in there anyways |
| 03:43:39 | [Saint] | Bilgus_: another natural follow-on question and/or philosophical discussion is whether or not this behavior should be extended to not just MULTI_DRIVE targets but also to MULTI_VOLUME targets. |
| 03:43:44 | | Join thehyde [0] (~martin@x4d04dd14.dyn.telefonica.de) |
| 03:44:20 | Bilgus_ | well FWICT is the act the same Max_volume is drives * volume per drive |
| 03:44:22 | [Saint] | though it's hard to imagine truly valid use cases for MULTI_VOLUME |
| 03:45:27 | Bilgus_ | that brings up the next question what happens when there are 3 valid fw files |
| 03:45:37 | [Saint] | And, yeah, you're right. It is a good idea. It's actually something I thought about years and years and years ago but never really had much cause to think about it again now. |
| 03:46:05 | Bilgus_ | pick the newest or highest indexed |
| 03:46:16 | [Saint] | It honestly surprised me when I went looking for a hardcoded version indicator for the main binary and couldn't find one. |
| 03:46:51 | Bilgus_ | maybe it should always boot the newest version found |
| 03:47:08 | [Saint] | Bilgus_: I think it makes sense to always pick the latest installation, as we can assume for most cases that it is going to be deliberate. |
| 03:47:45 | Bilgus_ | until you get a situation of two with the same version |
| 03:48:08 | Bilgus_ | then I guess you fallback to highest index |
| 03:48:11 | [Saint] | If there's two of the same version I think internal storage should be preferred. |
| 03:48:49 | [Saint] | whatever we do we need to ensure that the logic is bullet proof and that this is communicated very clearly to the end user in the manual. |
| 03:48:59 | Bilgus_ | but what happens when you have everything set up with the latest ver and want to boot ext |
| 03:49:36 | Bilgus_ | see I think the ext should be preferred since that is the one you have control over |
| 03:49:56 | | Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) |
| 03:50:05 | [Saint] | would would the use case be there? |
| 03:50:05 | [Saint] | If I read you correctly, you're talking about both internal and external storage having the same version...and the user for whatever reason wanting to make a distinction between internal and external? |
| 03:50:08 | Bilgus_ | and in that case I think multi volumes need to be ignored |
| 03:50:17 | [Saint] | ...what would the reasoning behind that decision be? |
| 03:51:09 | [Saint] | I mean I can imagine it happening, but I can't imagine the reasoning to prefer one volume over the other if it did. |
| 03:51:36 | Bilgus_ | well as you said it is a deliberate decision to place FW on the ext drive so should be honored |
| 03:52:19 | [Saint] | Well, yes. That's a fair point. I hadn't really considered that. |
| 03:52:38 | Bilgus_ | esp in the situation tht you can't change the ver on the internal at least you could remove the sd card |
| 03:52:56 | [Saint] | In that case I think I will retract the above and say it makes sense to prefer external. |
| 03:53:15 | Bilgus_ | Idk I'll mull it over and we'll get some more thoughts on this |
| 03:53:17 | | Quit thehyde (Ping timeout: 255 seconds) |
| 03:53:21 | Bilgus_ | night |
| 03:53:25 | [Saint] | I suppose the question remains though, is that a user case that needs to be communicated to the user? |
| 03:54:09 | Bilgus_ | well I think it all needs to be communicated to the user at very least BOOTING FROM <MICROSD1> |
| 03:54:16 | [Saint] | If there's two identical versions, and we prefer external in this case (which I'll admit makes sense), do we communicate that to the user, and if so, why, and if not, is there a downside to it if we didn't? |
| 03:54:54 | [Saint] | and by 'communicate to the user' I mean in a fashion that requires prompting or hinting. |
| 03:55:13 | [Saint] | you're right, and I think we both agree that, we should _always_ display what volume we're booting from. |
| 03:55:22 | [Saint] | regardless as to the logic that got us to that point. |
| 03:56:13 | Bilgus_ | and then you get back to when prompted how do you communicate with the visually impaired user? |
| 03:56:45 | Bilgus_ | he is still sitting there waiting for the main menu |
| 03:58:10 | [Saint] | It just occurred to me that there's potentially a fourth boot option available. |
| 03:58:13 | Bilgus_ | Idk maybe a patch is the better way to go put the logic into the boot loader and require a ext boot FW to be installed |
| 03:58:33 | [Saint] | and I'm honestly surprised that no one has tried to implement it. |
| 03:58:48 | Bilgus_ | boot from usb? |
| 03:58:53 | [Saint] | right. |
| 03:59:08 | [Saint] | you're onto it, I was just typing that out in a more long winded fashion. |
| 04:00 |
| 04:00:08 | [Saint] | if there's no valid binary on either internal or external, or perhaps even if there is by way of some hardware key trigger, booting from USB would be interesting. |
| 04:00:55 | Bilgus_ | the ext boot FW can just have a E appended to the aforementioned version string and then It becomes entirely deliberate no if ands buts |
| 04:01:38 | Bilgus_ | nah nm bc itd just end up being installed on internal and then it is the same situation |
| 04:01:55 | [Saint] | right, beat me to it. |
| 04:02:11 | [Saint] | this really involves rather a lot of pretty fucky and non-obvious logic. |
| 04:02:45 | | Join Strife89 [0] (~quassel@adsl-98-80-185-244.mcn.bellsouth.net) |
| 04:02:46 | [Saint] | pretty much all of which just completely and absolutely fails for visually impaired users. |
| 04:02:50 | Bilgus_ | I really don't see a good use case for usb boot except maybe repair but if your player is that screwed I think its trash bin time |
| 04:03:12 | [Saint] | Bilgus_: debugging and actively development. |
| 04:03:39 | [Saint] | though I suppose that actually _does_ have business being a compile time flag. |
| 04:03:48 | [Saint] | seeing as how it would be developers making use of it. |
| 04:03:49 | Bilgus_ | the sim plays out pretty well for taht except a few niche cases |
| 04:04:15 | [Saint] | eh...there's a bunch of cases where the sim is pretty much useless for debugging. |
| 04:04:28 | | Quit Strife1989 (Ping timeout: 276 seconds) |
| 04:04:40 | [Saint] | anything that involves specific timing, for instance. |
| 04:04:52 | [Saint] | anything that involves cache/buffer over or underruns. |
| 04:04:54 | Bilgus_ | wouldn't you need OTG to dfo that though |
| 04:04:58 | Bilgus_ | do* |
| 04:05:21 | Bilgus_ | or at the very least a driver of some sort |
| 04:05:27 | [Saint] | Not necessarily. |
| 04:05:35 | [Saint] | right, you could do it with a client side driver. |
| 04:06:04 | Bilgus_ | yeah map usb to a file |
| 04:06:22 | Bilgus_ | folder I suppose |
| 04:07:10 | [Saint] | there's been more than a few times I have wanted to be able to boot from USB to test things more easily on real hardware. |
| 04:07:30 | Bilgus_ | the ext boot makes that pretty easy too |
| 04:07:58 | Bilgus_ | maybe not quite taht seamless but close |
| 04:08:33 | [Saint] | that way you could just symbolically link your $OUT/rockbox.$device or $OUT/rockbox.zip to a known location and have it boot from that. |
| 04:08:51 | [Saint] | so all you needed to do was compile a new build with the player plugged and power cycle. |
| 04:09:01 | Bilgus_ | already have rolo |
| 04:09:34 | [Saint] | role involves having to actually copy the media to the device by some means first. |
| 04:09:54 | [Saint] | which adds an albeit tiny, but annoying (if you're doing it several dozen times) step. |
| 04:09:59 | [Saint] | s/role/role/ |
| 04:10:05 | [Saint] | fuuuck* |
| 04:10:06 | Bilgus_ | lol |
| 04:10:08 | [Saint] | *rolo |
| 04:11:04 | [Saint] | It's complex and annoying enough to not be worth it though I think, but I'm genuinely surprised no one's considered it in the past. |
| 04:11:10 | Bilgus_ | well we will see what amaury and mihail think and anyone else and maybe we can work out something that works |
| 04:11:56 | Bilgus_ | and if not it becomes another patch for users who can figure it out to apply |
| 04:12:00 | [Saint] | As usual I'm more than happy to define the verbiage for the manuals very clearly, as long as someone can communicate to me that logic effectively. |
| 04:12:28 | [Saint] | I do think this very much shouldn't be another patch to languish on Gerrit. |
| 04:12:39 | [Saint] | This is not only useful, but near-universally wanted. |
| 04:13:14 | [Saint] | The only ambiguous things are the implementation and how to step through the logic with sane fallbacks and catches. |
| 04:13:39 | Bilgus_ | always lol |
| 04:14:35 | [Saint] | We know damn well that this is something users want and need, even when they don't know they want or need it. Because as I said, they often don't know they want or need it until they do need it and can't apply it because their player is irrecoverable without extensive manual intervention. |
| 04:15:08 | [Saint] | that's the main reason I think it needs to not be a compile-time function and should default to always-on. |
| 04:15:09 | | Quit bluebrother (Read error: Connection reset by peer) |
| 04:15:09 | | Quit fs-bluebot (Read error: Connection reset by peer) |
| 04:15:25 | [Saint] | But doing it that way means it requires a complex string of logic. |
| 04:15:41 | [Saint] | anyhooo...this needs more than just two voices I think. |
| 04:18:47 | | Quit duo8 (Ping timeout: 240 seconds) |
| 04:21:03 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 04:23:10 | | Quit Bray90820 (Ping timeout: 258 seconds) |
| 04:33:43 | | Join fs-bluebot [0] (~fs-bluebo@xd9bafee5.dyn.telefonica.de) |
| 04:49:27 | | Join thehyde [0] (~martin@x4d04dd14.dyn.telefonica.de) |
| 04:50:16 | *** | Saving seen data "./dancer.seen" |
| 04:59:01 | | Quit thehyde (Ping timeout: 245 seconds) |
| 04:59:27 | dongs | did anything ever happened of those amazing made-for-rockbox mediaplayer designs? |
| 05:00 |
| 05:24:07 | [Saint] | There has only ever been one. |
| 05:24:24 | [Saint] | And it is still in very much active development in terms of the hardware phase. |
| 05:28:57 | [Saint] | dongs: ^ |
| 05:29:22 | dongs | oh |
| 05:29:27 | dongs | so its the i.mx23 one? |
| 05:43:54 | | Join Strife1989 [0] (~quassel@adsl-98-67-59-213.mcn.bellsouth.net) |
| 05:46:34 | | Quit Strife89 (Ping timeout: 240 seconds) |
| 05:54:59 | | Join thehyde [0] (~martin@x4d04dd14.dyn.telefonica.de) |
| 05:58:15 | fs-bluebot | Build Server message: New build round started. Revision 4d4b0c5, 255 builds, 16 clients. |
| 06:00 |
| 06:04:07 | | Quit thehyde (Ping timeout: 240 seconds) |
| 06:07:15 | fs-bluebot | Build Server message: Build round completed after 541 seconds. |
| 06:07:16 | fs-bluebot | Build Server message: Revision 4d4b0c5 result: All green |
| 06:09:51 | | Quit TheSeven (Ping timeout: 245 seconds) |
| 06:10:37 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:27:27 | | Quit furrywolf (Ping timeout: 240 seconds) |
| 06:31:04 | | Quit Strife1989 (Ping timeout: 240 seconds) |
| 06:31:09 | | Join Strife89 [0] (~quassel@adsl-98-80-195-193.mcn.bellsouth.net) |
| 06:50:19 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:07:40 | | Join johnb2 [0] (~johnb2@p57B4568A.dip0.t-ipconnect.de) |
| 07:23:29 | | Join Bray90820 [0] (~bray90820@173-25-204-30.client.mchsi.com) |
| 07:50:02 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 07:50:02 | | Quit pixelma (Quit: .) |
| 07:53:57 | | Join amiconn [0] (amiconn@rockbox/developer/amiconn) |
| 07:53:58 | | Join pixelma [0] (pixelma@rockbox/staff/pixelma) |
| 07:59:14 | | Quit johnb2 (Ping timeout: 260 seconds) |
| 08:00 |
| 08:28:44 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:31:29 | | Join mutnai [0] (6db90a3e@gateway/web/freenode/ip.109.185.10.62) |
| 08:31:51 | | Quit mutnai (Client Quit) |
| 08:48:18 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 08:48:29 | | Quit wodz (Client Quit) |
| 08:48:47 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 08:50:22 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:26:13 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 09:44:25 | pamaury | [Saint]: Bilgus_: I'm reading the logs and I'm not sure how you would compare versions. You can't easily compare commits, you could compare stable version (3.13 > 3.12) but that only works for stable, and dates comparison are not a good idea imo |
| 09:47:37 | pamaury | and I don't see the point of booting from usb: any usb capable bootloader should present the disk over usb if plugged so you can always put something on the disk. |
| 09:48:19 | | Quit PurlingNayuki (Read error: Connection reset by peer) |
| 09:48:57 | pamaury | you are raising a very good point with impaired users |
| 09:49:59 | | Join PurlingNayuki [0] (~Thunderbi@113.82.116.170) |
| 09:50:58 | pamaury | my main concern is that this feature should be active by default (otherwise it's useless) but hard to trigger by accident (ie user extract to sd by mistake) |
| 09:52:45 | pamaury | also, if we decide (which I think it's quite obvious) that only advanced users are ever going to use this function, then why not have a mecanism like booting from SD if it contains a file named "rockbox_main" ? This way no mistake possible: you have to explicitely tell the bootloadet you want to boot from it essentially |
| 09:58:23 | pamaury | if you can actually refine this into "rockbox_main.clip+" if you are paranoid and share your sd card between players and only want to override on one player |
| 09:59:05 | pamaury | and if you really really want to even have several rockbox on the sd card, then maybe "rockbox_main.clip+.dir" means "look for rockbox in directory "dir/" |
| 09:59:09 | pamaury | just some ideas |
| 10:00 |
| 10:07:28 | | Quit alexweissman (Read error: Connection reset by peer) |
| 10:08:00 | | Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) |
| 10:11:39 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 10:14:11 | pamaury | or maybe just one file "rockbox_main.clip+" and if empty, boot from /microSD/.rockbox, and if it contains a string XXX, boot from /microSD/XXX/.rockbox |
| 10:14:35 | pamaury | it can actually be very useful for devs/tests, you load several versions in distincts dirs and use this file to select |
| 10:18:19 | wodz | bootloader checking some magic config file was my idea also |
| 10:25:09 | | Quit pamaury (Ping timeout: 240 seconds) |
| 10:50:25 | *** | Saving seen data "./dancer.seen" |
| 10:54:33 | | Quit paulk-collins (Remote host closed the connection) |
| 11:00 |
| 11:07:27 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 11:18:43 | | Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) |
| 11:19:02 | | Quit mutnai (Client Quit) |
| 11:51:01 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:14fc:3bdb:f787:155e) |
| 12:00 |
| 12:03:27 | | Quit jhMikeS (Ping timeout: 248 seconds) |
| 12:16:29 | | Join johnb2 [0] (~johnb2@p57B4568A.dip0.t-ipconnect.de) |
| 12:22:19 | | Join paulk-blaze [0] (~paulk@37.160.255.46) |
| 12:33:56 | | Join Mihail [0] (252d6d31@gateway/web/cgi-irc/kiwiirc.com/ip.37.45.109.49) |
| 12:34:04 | Mihail | I agree with renaming ".rockbox" to ".rockbox_main" on SD to activate. For users we have RBUtil and it can automatically rename dir if user choose "install to SD card". If we have only one drive (internal drive corrupted and can't be mounted) we should first try boot from ".rockbox_main" and than ".rockbox". |
| 12:34:30 | Mihail | I not sure that we should always boot latest version - as we can want downgrade to latest stable version or do bisect. |
| 12:34:45 | Mihail | Also we should not add new features in bootloader if it possible. Bootloader size in git already bigger than we need for AMSv1. I have some size optimization for bootloader but it still not enough. |
| 12:35:01 | Mihail | Also we should add info (to "Rockbox Info") from which exactly drive we load. |
| 12:37:44 | | Quit paulk-blaze (Quit: Leaving) |
| 12:41:08 | | Quit diox (Ping timeout: 264 seconds) |
| 12:43:46 | | Join diox [0] (~u@c80-216-199-59.bredband.comhem.se) |
| 12:44:02 | johnb2 | then any config settings etc. would also be written atuomatically to .rockbox_main? |
| 12:44:33 | Mihail | yes |
| 12:50:29 | *** | Saving seen data "./dancer.seen" |
| 12:51:40 | | Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 12:53:32 | johnb2 | Wouldn't .rockbox_SD be more intuitive? |
| 12:57:23 | Mihail | maybe or not. rockbox_main says "it main, so will be booted first" |
| 13:00 |
| 13:02:02 | pixelma | there is at least one other target with multivolume where the card is not an SD but an MMC (not sure if we want a new bootloader for this one though...) |
| 13:06:38 | | Quit johnb2 (Ping timeout: 256 seconds) |
| 14:00 |
| 14:11:22 | Bilgus_ | I think the boot file is probably the way to go then it removes all chance of accident plus with the directory defined inside you could actually use it to move your install anywhere |
| 14:13:21 | Bilgus_ | just require it to be in root |
| 14:16:02 | Bilgus_ | plus it really simplifies logic for the bootloader |
| 14:19:16 | Mihail | IMHO much easy for user just rename dir than create/edit file |
| 14:23:48 | Bilgus_ | you could have rbutil create the file |
| 14:24:18 | Bilgus_ | it also allows that director to be anywhere |
| 14:26:09 | Mihail | but is we really need "to be anywhere"? |
| 14:27:39 | Bilgus_ | conceivably you could have different installs on that card but you could also do it in naming the folder as well .rockbox.fuze+_main |
| 14:27:55 | Bilgus_ | or fuze_main.rockbox |
| 14:29:56 | Mihail | we can do this automatically as bootloader know name of player |
| 14:30:04 | Bilgus_ | or even /sansa.rockbox/ but iI see that being a problem with players that share the same FW name |
| 14:30:32 | Bilgus_ | yeah we have the player name |
| 14:32:03 | Mihail | only one good point todo this: we can prepare special file that will just point to ".rockbox". So user should unpack rockbox.zip and put this file in root of SD. |
| 14:34:04 | Bilgus_ | as long as it follows the player name |
| 14:36:23 | Bilgus_ | need to make sure we either disallow the directive on internal storage or just apply precedence to removable storage |
| 14:37:12 | Bilgus_ | I can see the use case on internal for this but wouldn't want it to interfere |
| 14:42:30 | Mihail | Or we can check on SD only dirs with name of player - ".rockbox.clip+", ".rockbox.clipzip" and etc. So we solve two problems - rockbox will not loaded accidentally and we can have rockbox for different players on same SD card. |
| 14:48:14 | wodz | Mihail: rockbox binary is protected by device ID so bootloader will refuse to load binary for other player |
| 14:48:17 | Bilgus_ | I think its about the same and the folder way seems less cluttered |
| 14:48:55 | Bilgus_ | we want a way to specify which though at least that makes it safer |
| 14:50:30 | *** | Saving seen data "./dancer.seen" |
| 14:56:12 | | Quit wodz (Quit: Ex-Chat) |
| 15:00 |
| 15:03:32 | Bilgus_ | now we need a way to get the book volume back to the FW file |
| 15:03:37 | Bilgus_ | boot* |
| 15:04:39 | Bilgus_ | we could have it do the same search as the bootloader but that seems prone to mistakes really it needs to be absolute |
| 15:06:05 | Mihail | why? if it will be same search - I don't see problem |
| 15:11:20 | Bilgus_ | how do you insure it was though |
| 15:12:05 | Bilgus_ | itd be if you cange it in fw you have to go back to bootloader and change it too |
| 15:12:12 | Bilgus_ | change* |
| 15:13:51 | Bilgus_ | nm I don't think it'd be that big of a deal as long as you were always right |
| 15:14:00 | Mihail | yes, but we already do this for internal disk - if we want change .rockbox to .rb we should update both bootloder and fw |
| 15:15:03 | Bilgus_ | we need a way that will work with existing bootloader too |
| 15:16:21 | Bilgus_ | I was thinking if you fw did a search and found a folder that your bootloader didn't they then have the wrong info between them |
| 15:16:54 | Bilgus_ | whereas a mechinism for boot volume if it didn't exist you would know it was an old boot loader |
| 15:17:36 | Bilgus_ | and to load internal/.rockbox/ |
| 15:17:59 | Bilgus_ | bbl |
| 15:21:45 | Mihail | But it still better than nothing: one my zip switch to internal disk to read only. So if bootloader boot old rockbox.sansa and load .rockbox.clipzip from sd it still good behavior for recovery: I can put same rockbox to .rockbox.clipzip as it was on internal drive and all my setting will be saved to SD. Player will be still useful. |
| 15:22:08 | shrizza_ | Oh hey Mihail. |
| 15:22:16 | shrizza_ | Thanks for the post on the forums. |
| 15:22:55 | shrizza_ | I'm still kind of trying to figure out how to futureproof my clip zip. |
| 15:23:04 | shrizza_ | But I will refer to your posts. |
| 15:25:40 | Mihail | shrizza_: what post it was? |
| 15:25:57 | shrizza_ | The ones here: http://forums.rockbox.org/index.php/topic,51304.0.html |
| 15:27:01 | Mihail | ah, ok |
| 15:30:24 | | Quit Mihail (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 15:38:35 | | Join furrywolf [0] (~randyg@72-57-73-12.pools.spcsdns.net) |
| 15:47:24 | pamaury | Bilgus_: Mihail: my proposal was NOT to rename .rockbox to .rockbox_main |
| 15:49:50 | pamaury | my proposal was to have a file called (for example) rockbox.xxxx (where xxxx is the target name, ie clip+, fuze+) that indicates that rockbox has to be loaded from this disk. Furthermore, the content of this file gives the subdirectory where to find .rockbox. |
| 15:49:50 | pamaury | So if rockbox.xxxx is empty, it means load rockbox from /microsd/.rockbox |
| 15:49:50 | pamaury | but if the file contains BLA then it means load from /microsd/BLA/.rockbox |
| 15:49:50 | DBUG | Enqueued KICK pamaury |
| 15:49:50 | pamaury | this way you still just unzip rockbox.zip but either at the root of microsd, or in a subdirectory if you want to have several of them on the same sd card (potentially useful if you share SD cards with several players or want to test different firmwares) |
| 15:50:04 | pamaury | potentially BLA would be an arbitrary path even |
| 15:59:25 | pamaury | ideally the bootloader should give the info to rockbox about the boot volume. But this is non-trivial to implement. One way is for the bootloader to give a pointer to a structure giving this information (like grub), but then each crt0.S needs to make sure to safely copy it on boot (nontrivial since rockbox self-relocate and clears bss, etc). |
| 15:59:25 | pamaury | Another approach is to have rockbox binary embed the structure, with a magic header easily findeable by the bootloader, that is filled by the bootloader |
| 16:00 |
| 16:20:48 | | Join johnb2 [0] (~johnb2@p57B4568A.dip0.t-ipconnect.de) |
| 16:32:47 | | Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) |
| 16:38:05 | | Join johnb3 [0] (~johnb3@p57B4568A.dip0.t-ipconnect.de) |
| 16:39:45 | | Nick johnb3 is now known as johnb2 (~johnb3@p57B4568A.dip0.t-ipconnect.de) |
| 16:44:28 | | Quit APLU (Quit: !suicide) |
| 16:48:17 | | Join Bilgus_ph [0] (~Bilgus_ph@108.101.164.110) |
| 16:48:40 | | Join APLU [0] (~mulx@eva.aplu.fr) |
| 16:50:33 | *** | Saving seen data "./dancer.seen" |
| 16:51:35 | Bilgus_ph | I think magic header would be the best idea if it is missing you only boot internal as the fw is too old. imo you only really need the boot volume to be passed and the rest can be handled by the fw |
| 16:53:05 | Bilgus_ph | Pamaury so you want it to always boot .rockbox in a sd card? I think it is a good requirement to have the file otherwise it is ignored |
| 16:53:09 | | Quit alexweissman (Remote host closed the connection) |
| 16:54:34 | | Quit Bilgus_ph (Read error: Connection reset by peer) |
| 16:59:19 | pamaury | Bilgus_: no, re-read what I said. I boot /BLA/.rockbox from SD card card if it contains a file called rockbox_main.clip+ that contains BLA. So the simplest use case is |
| 16:59:19 | pamaury | if rockbox_main.xxx exists on SD card and is empty, then boot .rockbox from SD card |
| 16:59:37 | pamaury | so yeah, if there is no file it is ignored, as you said |
| 17:00 |
| 17:00:04 | pamaury | what I don't like about the magic header is that it is a big unclean |
| 17:00:33 | | Quit johnb2 (Ping timeout: 260 seconds) |
| 17:20:26 | | Join Bilgus_ph [0] (~Bilgus_ph@184-227-108-56.pools.spcsdns.net) |
| 17:20:46 | | Quit Bilgus_ph (Remote host closed the connection) |
| 17:21:02 | | Join Bilgus_ph [0] (~Bilgus_ph@184-227-108-56.pools.spcsdns.net) |
| 17:26:37 | Bilgus_ph | I think any other way is going to be pretty messy as well. isn't the boot loader always loaded could you have a call back in the bootloader? I'm not sure if i like that though due to the older bootloaders i guess you could give the fw a dummy function |
| 17:30:28 | pamaury | yeah a callback doesn't seem like a plausible idea. As much as I don't like the magic header, I have to admit it's probably the simplest solution. |
| 17:30:50 | pamaury | A possibility would be to make sure (with the linker script) that this structure is at the very end of the binary |
| 17:30:53 | | Quit Bilgus_ph (Read error: Connection reset by peer) |
| 17:31:03 | pamaury | but that means changing all linker scripts so.... |
| 17:32:54 | | Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) |
| 17:41:13 | | Join shh [0] (~me@145.132.155.235) |
| 17:45:00 | | Join Bilgus_ph [0] (~Bilgus_ph@184-227-108-56.pools.spcsdns.net) |
| 17:47:50 | Bilgus_ph | It could be done the same as the crc and file data with a known offset and magic number right? Int with the boot volume or'd or xor'd to the value |
| 17:52:30 | Bilgus_ph | I don't know if it would ever be necessary but you could also make a FW that couldnt be off internal as well |
| 17:52:35 | | Quit Bilgus_ph (Remote host closed the connection) |
| 17:53:21 | pamaury_ | Bilgus_ph: it's not that easy, the crc of the file is not part of the firmware, it is only checked the bootloader and discarded basically. From the point of view of rockbox.sansa for example, the crc does not exists |
| 17:53:32 | pamaury_ | some targets don't even use a crc checked file |
| 17:58:44 | | Join shhh [0] (~me@145.132.155.235) |
| 17:58:53 | | Quit shh (Ping timeout: 258 seconds) |
| 18:00 |
| 18:03:36 | | Join alexweissman [0] (~alexweiss@2001:18e8:2:28b6:f13f:1039:a82a:632a) |
| 18:08:11 | | Quit alexweissman (Ping timeout: 245 seconds) |
| 18:14:51 | | Join alexweissman [0] (~alexweiss@2001:18e8:2:28b6:a81c:ce9e:ff89:d3e8) |
| 18:16:18 | | Quit shhh (Ping timeout: 252 seconds) |
| 18:19:42 | | Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) |
| 18:30:04 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 18:31:46 | | Quit jhMikeS (Client Quit) |
| 18:32:02 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 18:35:30 | | Quit jhMikeS (Client Quit) |
| 18:36:19 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 18:43:12 | | Join johnb3 [0] (~johnb2@p57B4568A.dip0.t-ipconnect.de) |
| 18:47:42 | | Quit johnb3 (Ping timeout: 248 seconds) |
| 18:50:35 | *** | Saving seen data "./dancer.seen" |
| 18:55:54 | | Quit pamaury (Remote host closed the connection) |
| 18:56:01 | | Quit knittl (*.net *.split) |
| 18:56:01 | | Quit beveradb (*.net *.split) |
| 18:56:01 | | Quit rasher (*.net *.split) |
| 18:56:08 | | Join knittl [0] (~knittl@fucktheforce.de) |
| 18:56:09 | | Quit knittl (Changing host) |
| 18:56:09 | | Join knittl [0] (~knittl@unaffiliated/knittl) |
| 18:56:11 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
| 18:56:19 | DEBUG | EOF from server (Success) (snapshot: netstuff.c line 545) |
| 18:56:19 | *** | Cleanup |
| 18:56:19 | *** | Cleanup |
| 18:56:19 | *** | Saving seen data "./dancer.seen" |
| 18:56:19 | *** | Exit |
| 18:56:21 | *** | Started Dancer V4.16 |
| 18:56:21 | *** | Connected to irc.freenode.net on port 6667 |
| 18:56:21 | *** | Logfile for #rockbox started |
| 18:56:21 | Mode | "logbot :+i" by logbot |
| 18:56:27 | *** | Server message 501: 'logbot :Unknown MODE flag' |
| 18:56:27 | | Join logbot [0] (~rockbox@giant.haxx.se) |
| 18:56:27 | | Join maraz [0] (maraz@kapsi.fi) |
| 18:56:27 | | Join beveradb [0] (~beveradb@irc.beveridge.uk) |
| 18:56:27 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
| 18:56:27 | | Join knittl [0] (~knittl@unaffiliated/knittl) |
| 18:56:27 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 18:56:27 | | Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) |
| 18:56:27 | | Join alexweissman [0] (~alexweiss@2001:18e8:2:28b6:a81c:ce9e:ff89:d3e8) |
| 18:56:27 | | Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) |
| 18:56:27 | | Join APLU [0] (~mulx@eva.aplu.fr) |
| 18:56:27 | | Join furrywolf [0] (~randyg@72-57-73-12.pools.spcsdns.net) |
| 18:56:27 | | Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 18:56:27 | | Join diox [0] (~u@c80-216-199-59.bredband.comhem.se) |
| 18:56:27 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:14fc:3bdb:f787:155e) |
| 18:56:27 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 18:56:27 | | Join PurlingNayuki [0] (~Thunderbi@113.82.116.170) |
| 18:56:27 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 18:56:27 | | Join pixelma [0] (pixelma@rockbox/staff/pixelma) |
| 18:56:27 | | Join amiconn [0] (amiconn@rockbox/developer/amiconn) |
| 18:56:27 | | Join Bray90820 [0] (~bray90820@173-25-204-30.client.mchsi.com) |
| 18:56:27 | | Join Strife89 [0] (~quassel@adsl-98-80-195-193.mcn.bellsouth.net) |
| 18:56:27 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 18:56:27 | | Join fs-bluebot [0] (~fs-bluebo@xd9bafee5.dyn.telefonica.de) |
| 18:56:27 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 18:56:27 | | Join Acou_Bass [0] (~Acou_Bass@host-89-241-250-248.as13285.net) |
| 18:56:27 | | Join __builtin [0] (~xray@rockbox/developer/builtin) |
| 18:56:27 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
| 18:56:27 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
| 18:56:27 | | Join saratoga [0] (123e11e0@gateway/web/freenode/ip.18.62.17.224) |
| 18:56:27 | | Join idonob_ [0] (~Owner@S010610c37b922980.vs.shawcable.net) |
| 18:56:27 | | Join smoke_fumus [0] (~smoke_fum@dynamic-vpdn-93-125-62-122.telecom.by) |
| 18:56:27 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 18:56:27 | | Join mercutio [0] (ben@pearl.meh.net.nz) |
| 18:56:27 | | Join MrZeus__ [0] (~MrZeus@81.144.218.162) |
| 18:56:27 | | Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) |
| 18:56:27 | | Join soap [0] (~soap@rockbox/staff/soap) |
| 18:56:27 | | Join Galois [0] (djao@efnet.math.uwaterloo.ca) |
| 18:56:27 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 18:56:27 | | Join amazoniantoad [0] (~golden@2603:3018:600:a000:c48b:22ef:b5b3:be9b) |
| 18:56:27 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 18:56:27 | | Join dys [0] (~dys@ip-109-40-3-122.web.vodafone.de) |
| 18:56:27 | | Join Guest42960 [0] (~alex@testificate.xen.prgmr.com) |
| 18:56:27 | | Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) |
| 18:56:27 | | Join bzed [0] (~bzed@shell.bzed.at) |
| 18:56:27 | | Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) |
| 18:56:27 | | Join rela [0] (~x@pdpc/supporter/active/rela) |
| 18:56:27 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 18:56:27 | | Join Bilgus_ [0] (~Bilgus@gateway/tor-sasl/bilgus) |
| 18:56:27 | | Join preglow [0] (~thomj@2001:840:4243:3::101) |
| 18:56:27 | | Join uwe_ [0] (~uwe_@dslb-084-056-053-066.084.056.pools.vodafone-ip.de) |
| 18:56:27 | | Join jvoisin [0] (~jvoisin@dustri.org) |
| 18:56:27 | | Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-bfwftzvtxhseylai) |
| 18:56:27 | | Join derf [0] (~derf@static-108-18-126-14.washdc.fios.verizon.net) |
| 18:56:27 | | Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) |
| 18:56:27 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
| 18:56:27 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 18:56:27 | | Join scorche [0] (~scorche@rockbox/administrator/scorche) |
| 18:56:27 | | Join alucryd [0] (~quassel@archlinux/developer/alucryd) |
| 18:56:27 | | Join ranmachan [0] (~ranma@yumi.uguu.de) |
| 18:56:27 | | Join Marex [0] (~Marex@195.140.253.167) |
| 18:56:27 | | Join Cu5tosLimen [0] (~CustosLim@unaffiliated/cust0slim3n) |
| 18:56:27 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 18:56:27 | | Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com) |
| 18:56:27 | | Join TorC [0] (~TorC@fsf/member/TorC) |
| 18:56:27 | | Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow) |
| 18:56:27 | | Join uwe_android [0] (~uwe_andro@static.173.76.9.176.clients.your-server.de) |
| 18:56:27 | | Join GodEater [0] (~whoknows@rockbox/staff/GodEater) |
| 18:56:27 | | Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) |
| 18:56:27 | | Join megal0maniac [0] (~megal0man@unaffiliated/megal0maniac) |
| 18:56:27 | | Join Jack87 [0] (Jack87@nasadmin/admin/jack87) |
| 18:56:27 | | Join dunx [0] (~yulax@edinhacklab/member/duncan) |
| 18:56:27 | | Join Petri152 [0] (~Petri@petritrebs.ca) |
| 18:56:27 | | Join Rondom [0] (~rondom@modo.nonmodosedetiam.net) |
| 18:56:27 | | Join ender| [0] (krneki@2a01:260:4094:1:42:42:42:42) |
| 18:56:27 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 18:56:27 | | Join sparetire [0] (~sparetire@unaffiliated/sparetire) |
| 18:56:27 | | Join vflyson [0] (~vflyson@cupcake.uberspace.net) |
| 18:56:27 | | Join zoid [0] (~zoid@unaffiliated/taxationistheft) |
| 18:56:27 | | Join gevaerts [0] (~fg@rockbox/developer/gevaerts) |
| 18:56:27 | | Join evilnick [0] (~evilnick@rockbox/staff/evilnick) |
| 18:56:27 | | Join rogeliodh [0] (~rogeliodh@ec2-52-90-241-120.compute-1.amazonaws.com) |
| 18:56:27 | | Join yosafbridge [0] (~yosafbrid@68.ip-149-56-14.net) |
| 18:56:27 | | Join CustosL1men [0] (~CustosLim@unaffiliated/cust0slim3n) |
| 18:56:27 | | Join shmibs [0] (~shmibs@shmibbles.me) |
| 18:56:27 | | Join atsampson [0] (~ats@cartman.offog.org) |
| 18:56:27 | | Join snow_bckspc [0] (~snow_bcks@ganon.dot-server.net) |
| 18:56:27 | | Join prg318 [0] (~prg318@deadcodersociety/prg318) |
| 18:56:27 | | Join Topy44 [0] (topy@ns3.kurz.pw) |
| 18:56:27 | | Join Horrorcat [0] (~unknown@unaffiliated/horrorcat) |
| 18:56:27 | | Join TD-Linux [0] (~Thomas@about/essy/indecisive/TD-Linux) |
| 18:56:27 | | Join n17ikh [0] (~n17ikh@unaffiliated/n17ikh) |
| 18:56:27 | | Join ParkerR [0] (ParkerR@unaffiliated/parkerr) |
| 18:56:27 | | Join igitoor_ [0] (igitur@unaffiliated/contempt) |
| 18:56:27 | | Join aevin [0] (eivindsy@unaffiliated/aevin) |
| 18:56:27 | | Join user890104 [0] (Venci@unaffiliated/user890104) |
| 18:56:27 | | Join rudi_s [0] (~simon@kraftwerk.ruderich.eu) |
| 18:56:27 | | Join fIorz [0] (nobody@rain.florz.de) |
| 18:56:27 | | Join cttttt [0] (sid135570@gateway/web/irccloud.com/x-jdzwceualnhqexuy) |
| 18:56:27 | | Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) |
| 18:56:27 | | Join Kohlrabi [0] (~kohlrabi@kohlio.de) |
| 18:56:27 | | Join x56 [0] (0x56@unaffiliated/x56) |
| 18:56:27 | | Join ved_ [0] (ved@ddsbox.tk) |
| 18:56:27 | | Join puckipedia [0] (puck@puckipedia.com) |
| 18:56:27 | | Join munch [0] (pls@gateway/shell/elitebnc/x-drqhuslrjsgdzwnx) |
| 18:56:27 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 18:56:27 | | Join dongs [0] (~dongs@bcas.tv) |
| 18:56:27 | | Join man_in_shack [0] (~chat@unaffiliated/man-in-shack/x-4279753) |
| 18:56:27 | | Join anonus [0] (~anonymous@citadel.niflheim.info) |
| 18:56:27 | | Join froggyman [0] (~frogs@unaffiliated/froggyman) |
| 18:56:27 | | Join K1773R [0] (~K1773R@unaffiliated/k1773r) |
| 18:56:27 | | Join benedikt93 [0] (~quassel@unaffiliated/benedikt93) |
| 18:56:28 | | Join sbach [0] (~sbach@107.189.42.74) |
| 18:56:28 | | Join madk [0] (~noneofyou@107.170.140.154) |
| 18:56:28 | | Join utrack [0] (~utrack@21422.s.t4vps.eu) |
| 18:56:28 | | Join dan- [0] (~d@freenode/corporate-sponsor/privateinternetaccess.com/doaks) |
| 18:56:28 | | Join Slasheri [0] (miipekk@rockbox/developer/Slasheri) |
| 18:56:28 | | Join mikroflops [0] (~yogurt@178.174.137.46) |
| 18:56:28 | | Join zu [0] (~zu@ks387228.kimsufi.com) |
| 18:56:28 | | Join @ChanServ [0] (ChanServ@services.) |
| 18:56:28 | | Join vifino [0] (~vifino@tty.sh) |
| 18:56:28 | | Join shrizza_ [0] (~shrizza@oki-dc-urasoe01-187.glbb.ne.jp) |
| 18:56:28 | | Join CommunistWitchDr [0] (quasselcor@97-87-177-85.dhcp.stls.mo.charter.com) |
| 18:56:28 | | Join marex-cloud [0] (sid137234@gateway/web/irccloud.com/x-dcbrqfjzpbndzxhs) |
| 18:56:28 | | Join ruskie [0] (~ruskie@sourcemage/mage/ruskie) |
| 18:56:28 | | Join tomflint [0] (~tomflint@unaffiliated/tomflint) |
| 18:56:30 | | Quit shrizza_ (*.net *.split) |
| 18:56:30 | | Quit vifino (*.net *.split) |
| 18:56:30 | | Quit dan- (*.net *.split) |
| 18:56:30 | | Quit utrack (*.net *.split) |
| 18:56:30 | | Quit madk (*.net *.split) |
| 18:56:30 | | Quit sbach (*.net *.split) |
| 18:56:34 | | Join ps-auxw [0] (~arneb@p5B0FB259.dip0.t-ipconnect.de) |
| 18:56:38 | | Join sbach [0] (~sbach@107.189.42.74) |
| 18:56:46 | | Join shrizza_ [0] (~shrizza@oki-dc-urasoe01-187.glbb.ne.jp) |
| 18:56:47 | | Join madk [0] (~noneofyou@2604:a880:0:1010::93d:2001) |
| 18:56:48 | | Join vifino [0] (~vifino@tty.sh) |
| 18:56:54 | | Join dan- [0] (~d@101.165.168.135) |
| 18:56:54 | | Quit dan- (Changing host) |
| 18:56:55 | | Join dan- [0] (~d@freenode/corporate-sponsor/privateinternetaccess.com/doaks) |
| 18:56:56 | | Join utrack [0] (~utrack@21422.s.t4vps.eu) |
| 18:57:32 | | Quit MrZeus__ (Read error: Connection reset by peer) |
| 18:59:46 | | Quit pamaury_ (Ping timeout: 240 seconds) |
| 19:00 |
| 19:01:42 | | Join johnb3 [0] (~johnb2@p57B4568A.dip0.t-ipconnect.de) |
| 19:17:18 | | Quit johnb3 (Ping timeout: 255 seconds) |
| 19:33:42 | | Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) |
| 19:42:57 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 19:50:34 | | Join johnb3 [0] (~johnb2@p57B4568A.dip0.t-ipconnect.de) |
| 19:51:20 | | Quit alexweissman (Remote host closed the connection) |
| 20:00 |
| 20:15:47 | | Join alexweissman [0] (~alexweiss@2001:18e8:2:28b6:502:5f53:1465:ded1) |
| 20:30:17 | | Quit alexweissman (Read error: Connection reset by peer) |
| 20:30:23 | | Join TheLemonMan [0] (~root@irssi/staff/TheLemonMan) |
| 20:41:17 | | Join Bilgus_ph [0] (~Bilgus_ph@108.100.58.47) |
| 20:46:45 | | Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) |
| 20:47:40 | Bilgus_ph | Ah ok so then placing at the EOF would make the most sense from a searching standpoint are there any other specific to gcc calls we are already using? |
| 20:48:23 | | Join alexweissman [0] (~alexweiss@149-160-165-164.dhcp-bl.indiana.edu) |
| 20:49:33 | | Join StaticAmbience [0] (~Quassel@host217-42-102-110.range217-42.btcentralplus.com) |
| 20:51:33 | pamaury | Bilgus_ph: not sure what you mean |
| 20:56:23 | *** | Saving seen data "./dancer.seen" |
| 20:56:23 | Bilgus_ph | Compiler specific directives.. does gcc have directives for placing variables in specific places or does it have to be in the link file? |
| 20:57:55 | pamaury | linker script |
| 20:59:22 | | Quit Bilgus_ph (Read error: Connection reset by peer) |
| 21:00 |
| 21:01:37 | | Join Bilgus_ph [0] (~Bilgus_ph@108.100.58.47) |
| 21:02:35 | Bilgus_ph | NM it appears you still have to set it up in the linker file |
| 21:02:40 | | Quit Bilgus_ph (Remote host closed the connection) |
| 21:15:18 | | Quit alexweissman (Remote host closed the connection) |
| 21:35:47 | fs-bluebot | Build Server message: New build round started. Revision 248bff5, 255 builds, 17 clients. |
| 21:36:19 | | Join johnb2 [0] (~johnb2@p57B4568A.dip0.t-ipconnect.de) |
| 21:44:11 | fs-bluebot | Build Server message: Build round completed after 504 seconds. |
| 21:44:12 | fs-bluebot | Build Server message: Revision 248bff5 result: All green |
| 21:54:38 | | Join MrZeus [0] (~MrZeus@2a02:c7f:7008:3400:1489:894d:2718:769c) |
| 21:58:46 | | Join johnb3 [0] (~johnb2@p57B4568A.dip0.t-ipconnect.de) |
| 22:00 |
| 22:01:00 | johnb3 | Mihail: it seems my son's clip+' internal storage has also turned to read-only *%%!&! |
| 22:02:00 | johnb3 | unfortunately this one doesn't have the SD_only patch yet, nor the boot from SD precedence |
| 22:02:09 | johnb3 | bad timing ... |
| 22:02:36 | | Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) |
| 22:21:39 | | Quit johnb3 (Ping timeout: 276 seconds) |
| 22:25:41 | | Quit johnb2 (Ping timeout: 255 seconds) |
| 22:25:46 | | Join alexweissman [0] (~alexweiss@149-160-165-164.dhcp-bl.indiana.edu) |
| 22:26:33 | | Join Senji [0] (~Senji@85.187.103.250) |
| 22:26:45 | | Quit Senji (Read error: Connection reset by peer) |
| 22:28:13 | | Join Senji [0] (~Senji@85.187.103.250) |
| 22:30:38 | | Quit alexweissman (Ping timeout: 255 seconds) |
| 22:37:28 | | Quit Bilgus_ (Remote host closed the connection) |
| 22:40:09 | | Nick Guest42960 is now known as alexbobp (~alex@testificate.xen.prgmr.com) |
| 22:45:06 | dys | pamaury: interesting, they appear to set up the CAN peripheral w/DMA |
| 22:45:17 | dys | the PSoC also has CAN support |
| 22:48:21 | dys | pamaury: here's a script that adds MMIO register names to the objdump-generated disassembly |
| 22:48:22 | dys | http://paste.debian.net/912709/ |
| 22:50:34 | | Quit petur (Remote host closed the connection) |
| 22:54:34 | pamaury | dys: I'm kind of busy with two ports already, I'm not sure I want to start porting to another one just yet ;) |
| 22:55:00 | pamaury | I wonder if adding blackfin support to radare isn't better long term, cause objdump is really not great |
| 22:55:03 | dys | pamaury: no worries, I'm well prepared now thanks to your bootcode to elf converter |
| 22:56:00 | pamaury | dys: one advanteg you have is that the bootcode second elf seems to be a succesion of data, bss, data, bss, etc |
| 22:56:18 | pamaury | which means functions are most probably grouped by file, and thus are logically related |
| 22:56:24 | *** | Saving seen data "./dancer.seen" |
| 23:00 |
| 23:02:09 | | Join Bilgus [0] (~Bilgus@gateway/tor-sasl/bilgus) |
| 23:25:40 | Bilgus | Pamaury since we would be writing this variable before the firmware is actually loaded couldn't I make it a const in the actual code without having an issue writing it from the boot loader? |
| 23:27:03 | | Quit StaticAmbience (Ping timeout: 240 seconds) |
| 23:29:04 | | Join StaticAmbience [0] (~Quassel@host217-42-102-110.range217-42.btcentralplus.com) |
| 23:35:30 | | Join Senji_ [0] (~Senji@85.187.103.250) |
| 23:38:18 | | Join Senj_ [0] (~Senji@85.187.103.250) |
| 23:38:44 | | Quit Senji (Ping timeout: 264 seconds) |
| 23:40:11 | | Join alexweissman [0] (~alexweiss@2001:18e8:2:28b6:6498:4a42:77a:f39d) |
| 23:40:38 | | Quit Senji_ (Ping timeout: 240 seconds) |
| 23:44:38 | pamaury | Bilgus: I guess you could, but you have to be careful because that would mean making it const and initialised to 0 (from the point of view of the compiler). Thus if you want the compiler not to optimize it away, I suspect you need to make sure it's address is used somwhere, or make it extern const so the compiler is forced to allocate storage for it |
| 23:45:14 | * | pamaury does not remember what the C spec says about const global variables |
| 23:45:40 | pamaury | I think the compiler must allocate storage if its address is used, otherwise not necessarily |
| 23:47:41 | | Join Senji [0] (~Senji@85.187.103.250) |
| 23:48:04 | Bilgus | i was thinking of filling it with a magic# within the section and extern in the fw |
| 23:48:40 | | Quit Senj_ (Ping timeout: 256 seconds) |
| 23:49:22 | pamaury | yeah I think as long as you for example make it extern const in a header, use it somewhere and have a c file that declares it, filling some header with magic that's fine |
| 23:49:47 | pamaury | just make sure the magic is long enough so that it is impossible that it appears by mistake |
| 23:53:41 | Bilgus | good point |
| 23:55:09 | pamaury | I'm still not convinced by the "search through the whole firmware to find a string" though, that's potentially long |
| 23:56:12 | pamaury | ideally, the offset to this table should be in the firmware, for example computed offline when creating the file and store in the small header which already contains the crc and player type |
| 23:56:35 | pamaury | the problem with that is that it would mean changing the current size of the header and that's a breaking change |
icon identifies that the person is a core developer (has commit access).