Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2017-02-03

00:01:49pamauryyeah, except for confused users
00:02:44Mihailmany 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:56pamauryMost users don't even know what it means to unpack a zip at the root of the device
00:07:27pamauryI 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:38pamauryI think this is a good feature for advanced users
00:07:52pamauryI'm just worried about the consequences for other users
00:08:10[Saint]"Rockbox kicked my dog"
00:09:15Mihailit 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:29pamauryin 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:43Mihailit can help update rockbox even with broken usb
00:10:44pamauryie 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:15pamauryit won't apply to app
00:16:22pamaurythey don't even have a bootloader usually
00:28:04 Join thehyde [0] (
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: - 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] (
00:59:44 Quit xorly (Ping timeout: 264 seconds)
01:02:18 Quit alexweissman (Ping timeout: 255 seconds)
01:04:18 Join Bilgus_ph [0] (~Bilgus_ph@
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] (
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:05:46 Quit ZincAlloy (Quit: Leaving.)
02:06:01Bilgus_well I think we should have a define for Boot from sd capable devices in config anyways
02:39:19 Join thehyde [0] (
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:37Bilgus_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] (
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:28Bilgus_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: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:50Bilgus_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
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:33Bilgus_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:10Bilgus_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:38Bilgus_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:08Bilgus_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:37Bilgus_entirely transparent could cause some very confused users
03:08:04Bilgus_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:01Bilgus_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:19Bilgus_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:57Bilgus_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:23Bilgus_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:11Bilgus_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:33Bilgus_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:35Bilgus_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:37Bilgus_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:35Bilgus_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:05Bilgus_hmm I suppose it would still be possible I was thinking more along the lines of a file in use
03:21:38Bilgus_nah if you didn't have an install on the SD card you would never even know
03:22:01Bilgus_even if it was a 60 second delay
03:22:29Bilgus_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:51Bilgus_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:33Bilgus_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:53Bilgus_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:46Bilgus_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:32Bilgus_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:23Bilgus_how in the world will you check that though
03:31:35Bilgus_parse the FW?
03:32:06Bilgus_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:59Bilgus_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:24Bilgus_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:32Bilgus_probably a good IDea just have to be a magic string so we could detect absence
03:37:00Bilgus_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], 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:24Bilgus_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] (
03:44:20Bilgus_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:27Bilgus_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:05Bilgus_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:51Bilgus_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:45Bilgus_until you get a situation of two with the same version
03:48:08Bilgus_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:59Bilgus_but what happens when you have everything set up with the latest ver and want to boot ext
03:49:36Bilgus_see I think the ext should be preferred since that is the one you have control over
03:49:56 Join alexweissman [0] (
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:08Bilgus_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:36Bilgus_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:38Bilgus_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:15Bilgus_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:25[Saint]I suppose the question remains though, is that a user case that needs to be communicated to the user?
03:54:09Bilgus_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:13Bilgus_and then you get back to when prompted how do you communicate with the visually impaired user?
03:56:45Bilgus_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:13Bilgus_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:48Bilgus_boot from usb?
03:59:08[Saint]you're onto it, I was just typing that out in a more long winded fashion.
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:55Bilgus_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:38Bilgus_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] (
04:02:46[Saint]pretty much all of which just completely and absolutely fails for visually impaired users.
04:02:50Bilgus_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:49Bilgus_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:54Bilgus_wouldn't you need OTG to dfo that though
04:05:21Bilgus_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:04Bilgus_yeah map usb to a file
04:06:22Bilgus_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:30Bilgus_the ext boot makes that pretty easy too
04:07:58Bilgus_maybe not quite taht seamless but close
04:08:33[Saint]that way you could just symbolically link your $OUT/rockbox.$device or $OUT/ 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:01Bilgus_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: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:10Bilgus_well we will see what amaury and mihail think and anyone else and maybe we can work out something that works
04:11:56Bilgus_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:39Bilgus_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] (
04:49:27 Join thehyde [0] (
04:50:16***Saving seen data "./dancer.seen"
04:59:01 Quit thehyde (Ping timeout: 245 seconds)
04:59:27dongsdid anything ever happened of those amazing made-for-rockbox mediaplayer designs?
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:27dongsso its the i.mx23 one?
05:43:54 Join Strife1989 [0] (
05:46:34 Quit Strife89 (Ping timeout: 240 seconds)
05:54:59 Join thehyde [0] (
05:58:15fs-bluebotBuild Server message: New build round started. Revision 4d4b0c5, 255 builds, 16 clients.
06:04:07 Quit thehyde (Ping timeout: 240 seconds)
06:07:15fs-bluebotBuild Server message: Build round completed after 541 seconds.
06:07:16fs-bluebotBuild 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] (
06:50:19***Saving seen data "./dancer.seen"
07:07:40 Join johnb2 [0] (
07:23:29 Join Bray90820 [0] (
07:50:02 Quit amiconn (Quit: - 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:28:44 Join ender` [0] (
08:31:29 Join mutnai [0] (6db90a3e@gateway/web/freenode/ip.
08:31:51 Quit mutnai (Client Quit)
08:48:18 Join wodz [0] (
08:48:29 Quit wodz (Client Quit)
08:48:47 Join wodz [0] (
08:50:22***Saving seen data "./dancer.seen"
09:26:13 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
09:44:25pamaury[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:37pamauryand 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:57pamauryyou are raising a very good point with impaired users
09:49:59 Join PurlingNayuki [0] (~Thunderbi@
09:50:58pamaurymy 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:45pamauryalso, 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:23pamauryif 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:05pamauryand 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:09pamauryjust some ideas
10:07:28 Quit alexweissman (Read error: Connection reset by peer)
10:08:00 Join alexweissman [0] (
10:11:39 Join petur [0] (~petur@rockbox/developer/petur)
10:14:11pamauryor 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:35pamauryit can actually be very useful for devs/tests, you load several versions in distincts dirs and use this file to select
10:18:19wodzbootloader 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:07:27 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
11:18:43 Join mutnai [0] (6db91733@gateway/web/freenode/ip.
11:19:02 Quit mutnai (Client Quit)
11:51:01 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:14fc:3bdb:f787:155e)
12:03:27 Quit jhMikeS (Ping timeout: 248 seconds)
12:16:29 Join johnb2 [0] (
12:22:19 Join paulk-blaze [0] (~paulk@
12:33:56 Join Mihail [0] (252d6d31@gateway/web/cgi-irc/
12:34:04MihailI 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:30MihailI not sure that we should always boot latest version - as we can want downgrade to latest stable version or do bisect.
12:34:45MihailAlso 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:01MihailAlso 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] (
12:44:02johnb2then any config settings etc. would also be written atuomatically to .rockbox_main?
12:50:29***Saving seen data "./dancer.seen"
12:51:40 Join xorly [0] (
12:53:32johnb2Wouldn't .rockbox_SD be more intuitive?
12:57:23Mihailmaybe or not. rockbox_main says "it main, so will be booted first"
13:02:02pixelmathere 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:11:22Bilgus_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:21Bilgus_just require it to be in root
14:16:02Bilgus_plus it really simplifies logic for the bootloader
14:19:16MihailIMHO much easy for user just rename dir than create/edit file
14:23:48Bilgus_you could have rbutil create the file
14:24:18Bilgus_it also allows that director to be anywhere
14:26:09Mihailbut is we really need "to be anywhere"?
14:27:39Bilgus_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:55Bilgus_or fuze_main.rockbox
14:29:56Mihailwe can do this automatically as bootloader know name of player
14:30:04Bilgus_or even /sansa.rockbox/ but iI see that being a problem with players that share the same FW name
14:30:32Bilgus_yeah we have the player name
14:32:03Mihailonly one good point todo this: we can prepare special file that will just point to ".rockbox". So user should unpack and put this file in root of SD.
14:34:04Bilgus_as long as it follows the player name
14:36:23Bilgus_need to make sure we either disallow the directive on internal storage or just apply precedence to removable storage
14:37:12Bilgus_I can see the use case on internal for this but wouldn't want it to interfere
14:42:30MihailOr 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:14wodzMihail: rockbox binary is protected by device ID so bootloader will refuse to load binary for other player
14:48:17Bilgus_I think its about the same and the folder way seems less cluttered
14:48:55Bilgus_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:03:32Bilgus_now we need a way to get the book volume back to the FW file
15:04:39Bilgus_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:05Mihailwhy? if it will be same search - I don't see problem
15:11:20Bilgus_how do you insure it was though
15:12:05Bilgus_itd be if you cange it in fw you have to go back to bootloader and change it too
15:13:51Bilgus_nm I don't think it'd be that big of a deal as long as you were always right
15:14:00Mihailyes, but we already do this for internal disk - if we want change .rockbox to .rb we should update both bootloder and fw
15:15:03Bilgus_we need a way that will work with existing bootloader too
15:16:21Bilgus_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:54Bilgus_whereas a mechinism for boot volume if it didn't exist you would know it was an old boot loader
15:17:36Bilgus_and to load internal/.rockbox/
15:21:45MihailBut 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:08shrizza_Oh hey Mihail.
15:22:16shrizza_Thanks for the post on the forums.
15:22:55shrizza_I'm still kind of trying to figure out how to futureproof my clip zip.
15:23:04shrizza_But I will refer to your posts.
15:25:40Mihailshrizza_: what post it was?
15:25:57shrizza_The ones here:,51304.0.html
15:27:01Mihailah, ok
15:30:24 Quit Mihail (Quit: - A hand crafted IRC client)
15:38:35 Join furrywolf [0] (
15:47:24pamauryBilgus_: Mihail: my proposal was NOT to rename .rockbox to .rockbox_main
15:49:50pamaurymy 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:50pamaurySo if rockbox.xxxx is empty, it means load rockbox from /microsd/.rockbox
15:49:50pamaurybut if the file contains BLA then it means load from /microsd/BLA/.rockbox
15:49:50DBUGEnqueued KICK pamaury
15:49:50pamaurythis way you still just unzip 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:04pamaurypotentially BLA would be an arbitrary path even
15:59:25pamauryideally 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:25pamauryAnother 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:20:48 Join johnb2 [0] (
16:32:47 Quit johnb2 (Quit: Nettalk6 -
16:38:05 Join johnb3 [0] (
16:39:45 Nick johnb3 is now known as johnb2 (
16:44:28 Quit APLU (Quit: !suicide)
16:48:17 Join Bilgus_ph [0] (~Bilgus_ph@
16:48:40 Join APLU [0] (
16:50:33***Saving seen data "./dancer.seen"
16:51:35Bilgus_phI 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:05Bilgus_phPamaury 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:19pamauryBilgus_: 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:19pamauryif exists on SD card and is empty, then boot .rockbox from SD card
16:59:37pamauryso yeah, if there is no file it is ignored, as you said
17:00:04pamaurywhat 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] (
17:20:46 Quit Bilgus_ph (Remote host closed the connection)
17:21:02 Join Bilgus_ph [0] (
17:26:37Bilgus_phI 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:28pamauryyeah 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:50pamauryA 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:03pamaurybut that means changing all linker scripts so....
17:32:54 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury)
17:41:13 Join shh [0] (~me@
17:45:00 Join Bilgus_ph [0] (
17:47:50Bilgus_phIt 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:30Bilgus_phI 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:21pamaury_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:32pamaury_some targets don't even use a crc checked file
17:58:44 Join shhh [0] (~me@
17:58:53 Quit shh (Ping timeout: 258 seconds)
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] (
18:30:04 Join jhMikeS [0] (
18:31:46 Quit jhMikeS (Client Quit)
18:32:02 Join jhMikeS [0] (
18:35:30 Quit jhMikeS (Client Quit)
18:36:19 Join jhMikeS [0] (
18:43:12 Join johnb3 [0] (
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] (
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:19DEBUGEOF from server (Success) (snapshot: netstuff.c line 545)
18:56:19***Saving seen data "./dancer.seen"
18:56:21***Started Dancer V4.16
18:56:21***Connected to on port 6667
18:56:21***Logfile for #rockbox started
18:56:21Mode"logbot :+i" by logbot
18:56:27***Server message 501: 'logbot :Unknown MODE flag'
18:56:27 Join logbot [0] (
18:56:27 Join maraz [0] (
18:56:27 Join beveradb [0] (
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] (
18:56:27 Join girafe [0] (
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] (
18:56:27 Join furrywolf [0] (
18:56:27 Join xorly [0] (
18:56:27 Join diox [0] (
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@
18:56:27 Join ender` [0] (
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] (
18:56:27 Join Strife89 [0] (
18:56:27 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
18:56:27 Join fs-bluebot [0] (
18:56:27 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
18:56:27 Join Acou_Bass [0] (
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] (
18:56:27 Join saratoga [0] (123e11e0@gateway/web/freenode/ip.
18:56:27 Join idonob_ [0] (
18:56:27 Join smoke_fumus [0] (
18:56:27 Join JanC [0] (~janc@lugwv/member/JanC)
18:56:27 Join mercutio [0] (
18:56:27 Join MrZeus__ [0] (~MrZeus@
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] (
18:56:27 Join Moarc [0] (
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] (
18:56:27 Join Guest42960 [0] (
18:56:27 Join olspookishmagus [0] (
18:56:27 Join bzed [0] (
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] (
18:56:27 Join jvoisin [0] (
18:56:27 Join Ruhan [0] (uid76353@gateway/web/
18:56:27 Join derf [0] (
18:56:27 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf)
18:56:27 Join amayer [0] (
18:56:27 Join Rower [0] (
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] (
18:56:27 Join Marex [0] (~Marex@
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] (
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] (
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] (
18:56:27 Join Rondom [0] (
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] (
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] (
18:56:27 Join yosafbridge [0] (
18:56:27 Join CustosL1men [0] (~CustosLim@unaffiliated/cust0slim3n)
18:56:27 Join shmibs [0] (
18:56:27 Join atsampson [0] (
18:56:27 Join snow_bckspc [0] (
18:56:27 Join prg318 [0] (~prg318@deadcodersociety/prg318)
18:56:27 Join Topy44 [0] (
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] (
18:56:27 Join fIorz [0] (
18:56:27 Join cttttt [0] (sid135570@gateway/web/
18:56:27 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7)
18:56:27 Join Kohlrabi [0] (
18:56:27 Join x56 [0] (0x56@unaffiliated/x56)
18:56:27 Join ved_ [0] (
18:56:27 Join puckipedia [0] (
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] (
18:56:27 Join man_in_shack [0] (~chat@unaffiliated/man-in-shack/x-4279753)
18:56:27 Join anonus [0] (
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@
18:56:28 Join madk [0] (~noneofyou@
18:56:28 Join utrack [0] (
18:56:28 Join dan- [0] (~d@freenode/corporate-sponsor/
18:56:28 Join Slasheri [0] (miipekk@rockbox/developer/Slasheri)
18:56:28 Join mikroflops [0] (~yogurt@
18:56:28 Join zu [0] (
18:56:28 Join @ChanServ [0] (ChanServ@services.)
18:56:28 Join vifino [0] (
18:56:28 Join shrizza_ [0] (
18:56:28 Join CommunistWitchDr [0] (
18:56:28 Join marex-cloud [0] (sid137234@gateway/web/
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] (
18:56:38 Join sbach [0] (~sbach@
18:56:46 Join shrizza_ [0] (
18:56:47 Join madk [0] (~noneofyou@2604:a880:0:1010::93d:2001)
18:56:48 Join vifino [0] (
18:56:54 Join dan- [0] (~d@
18:56:54 Quit dan- (Changing host)
18:56:55 Join dan- [0] (~d@freenode/corporate-sponsor/
18:56:56 Join utrack [0] (
18:57:32 Quit MrZeus__ (Read error: Connection reset by peer)
18:59:46 Quit pamaury_ (Ping timeout: 240 seconds)
19:01:42 Join johnb3 [0] (
19:17:18 Quit johnb3 (Ping timeout: 255 seconds)
19:33:42 Join lebellium [0] (
19:42:57 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
19:50:34 Join johnb3 [0] (
19:51:20 Quit alexweissman (Remote host closed the connection)
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@
20:46:45 Quit johnb3 (Quit: Nettalk6 -
20:47:40Bilgus_phAh 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] (
20:49:33 Join StaticAmbience [0] (
20:51:33pamauryBilgus_ph: not sure what you mean
20:56:23***Saving seen data "./dancer.seen"
20:56:23Bilgus_phCompiler specific directives.. does gcc have directives for placing variables in specific places or does it have to be in the link file?
20:57:55pamaurylinker script
20:59:22 Quit Bilgus_ph (Read error: Connection reset by peer)
21:01:37 Join Bilgus_ph [0] (~Bilgus_ph@
21:02:35Bilgus_phNM 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:47fs-bluebotBuild Server message: New build round started. Revision 248bff5, 255 builds, 17 clients.
21:36:19 Join johnb2 [0] (
21:44:11fs-bluebotBuild Server message: Build round completed after 504 seconds.
21:44:12fs-bluebotBuild 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] (
22:01:00johnb3Mihail: it seems my son's clip+' internal storage has also turned to read-only *%%!&!
22:02:00johnb3unfortunately this one doesn't have the SD_only patch yet, nor the boot from SD precedence
22:02:09johnb3bad timing ...
22:02:36 Join mutnai [0] (6db91733@gateway/web/freenode/ip.
22:21:39 Quit johnb3 (Ping timeout: 276 seconds)
22:25:41 Quit johnb2 (Ping timeout: 255 seconds)
22:25:46 Join alexweissman [0] (
22:26:33 Join Senji [0] (~Senji@
22:26:45 Quit Senji (Read error: Connection reset by peer)
22:28:13 Join Senji [0] (~Senji@
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 (
22:45:06dyspamaury: interesting, they appear to set up the CAN peripheral w/DMA
22:45:17dysthe PSoC also has CAN support
22:48:21dyspamaury: here's a script that adds MMIO register names to the objdump-generated disassembly
22:50:34 Quit petur (Remote host closed the connection)
22:54:34pamaurydys: 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:00pamauryI wonder if adding blackfin support to radare isn't better long term, cause objdump is really not great
22:55:03dyspamaury: no worries, I'm well prepared now thanks to your bootcode to elf converter
22:56:00pamaurydys: one advanteg you have is that the bootcode second elf seems to be a succesion of data, bss, data, bss, etc
22:56:18pamaurywhich means functions are most probably grouped by file, and thus are logically related
22:56:24***Saving seen data "./dancer.seen"
23:02:09 Join Bilgus [0] (~Bilgus@gateway/tor-sasl/bilgus)
23:25:40BilgusPamaury 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] (
23:35:30 Join Senji_ [0] (~Senji@
23:38:18 Join Senj_ [0] (~Senji@
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:38pamauryBilgus: 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:40pamauryI think the compiler must allocate storage if its address is used, otherwise not necessarily
23:47:41 Join Senji [0] (~Senji@
23:48:04Bilgusi 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:22pamauryyeah 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:47pamauryjust make sure the magic is long enough so that it is impossible that it appears by mistake
23:53:41Bilgusgood point
23:55:09pamauryI'm still not convinced by the "search through the whole firmware to find a string" though, that's potentially long
23:56:12pamauryideally, 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:35pamaurythe problem with that is that it would mean changing the current size of the header and that's a breaking change

Previous day | Next day