| 00:35:03 | rb-bluebot | Build Server message: New build round started. Revision 3b040673cc, 337 builds, 9 clients. |
| 00:35:03 | rb-bluebot | Add verification to multiboot redirect by William Wilgus |
| 00:47:31 | rb-bluebot | Build Server message: Build round completed after 748 seconds. |
| 00:47:32 | rb-bluebot | Build Server message: Revision 3b040673cc result: All green |
| 01:00 |
| 01:05:57 | | Quit othello7 (Quit: othello7) |
| 01:22:52 | *** | Saving seen data "./dancer.seen" |
| 01:24:29 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 01:46:10 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 01:46:40 | | Quit othello7 (Quit: othello7) |
| 01:50:31 | | Quit dconrad (Ping timeout: 244 seconds) |
| 03:00 |
| 03:22:53 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:21:51 | | Join pixelma [0] (marianne@p200300ea871cb700305e95fffec66ff3.dip0.t-ipconnect.de) |
| 05:00 |
| 05:22:57 | *** | No seen item changed, no save performed. |
| 05:30:53 | | Quit b0 (Quit: adiós) |
| 05:33:04 | | Join b0 [0] (~b0@user/b0) |
| 07:00 |
| 07:22:59 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 08:58:06 | speachy | time to block an entire /16. |
| 08:58:11 | speachy | sigh.. |
| 08:58:21 | speachy | ....all of bytedance. |
| 08:58:32 | speachy | since they are pathologically incapable of respecting robots.txt |
| 09:00 |
| 09:23:00 | *** | No seen item changed, no save performed. |
| 09:33:41 | edhelas_ | Hello :) ! |
| 09:54:05 | user890104 | speachy: have you tried a nginx frontend with proxy_cache? and then purge the cache daily |
| 09:54:35 | speachy | the problem is building the cache to begin with. |
| 09:54:37 | user890104 | or somehow integrate with the wiki, to purge it on page change |
| 09:54:49 | user890104 | well, it will be built on demand |
| 09:55:00 | speachy | multiple "AI" crawlers waking our entire cgit-exported repositories |
| 09:55:04 | speachy | following _every_ link. |
| 09:55:10 | user890104 | oh |
| 09:55:42 | speachy | ie every. single. file. for every. single. commit. |
| 09:55:55 | speachy | including diffs |
| 09:57:09 | speachy | that's the same problem that broke the wiki; they'd walk and rewalk and rewalk includhing histories. |
| 09:57:22 | speachy | only the wiki would wedge itself under an even moderate load. |
| 09:57:44 | user890104 | yes, this can solve the rewalking, but not the initial walk |
| 09:58:32 | speachy | we don't have effectively unlimited resources to serve unlimited crawlers. |
| 09:59:09 | speachy | (or perhaps more accurately, it significantly impacts the legitimate human-driven traffic) |
| 10:00 |
| 10:02:10 | speachy | other gems are a 40x jump in traffic to the translate site. |
| 10:04:03 | speachy | there's a IP registered in panama that has done the equivalent of crawl the translation site an avrage of three times a day so far this month.. |
| 10:04:45 | speachy | (closer to 8x a day, given teh traffic spikes) |
| 10:05:10 | jn | is there some kind of automatic rate-limiting proxy, that would be fast for the first N requests and then get progressively slower? |
| 10:05:31 | jn | bucketed per IP or something |
| 10:05:33 | speachy | naturally, but we don't have the resources to maintain the necessary state |
| 10:05:52 | speachy | well, limiting it strictly to IP addresses, sure |
| 10:06:04 | | Join thanosengine [0] (~thanos@user/thanosengine) |
| 10:06:05 | speachy | but some legit patterns are very bursty (eg the translate site) |
| 10:06:15 | speachy | (sorry, theme, not translate) |
| 10:07:51 | jn | hmm |
| 10:11:44 | speachy | and the way most of these bigger crawlers work is that they spread their load out among multiple (sometimes _many_) ip addresses. |
| 10:41:13 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 10:42:39 | | Quit _bilgus (Remote host closed the connection) |
| 10:46:13 | | Quit thanosengine (Quit: WeeChat 4.3.1) |
| 10:46:58 | | Join _bilgus [0] (~bilgus@syn-162-154-213-134.res.spectrum.com) |
| 10:50:11 | _bilgus | how about we just put a trap in there that if you hit the page you get blocked |
| 10:50:42 | _bilgus | hide the link on the main page and ley them crawl it |
| 10:53:18 | speachy | and then there are browser[plugins] that helpfully pre-fetch things |
| 10:53:21 | speachy | bah |
| 10:53:43 | _bilgus | probably worth it |
| 10:55:02 | _bilgus | make several and if hey hit more than 1 in say 10 seconds its a bot? |
| 10:56:26 | speachy | yet another task I really don't want to do. :D |
| 10:59:30 | | Join thanosengine [0] (~thanos@user/thanosengine) |
| 11:00 |
| 11:23:01 | *** | Saving seen data "./dancer.seen" |
| 11:27:14 | | Quit othello7 (Quit: othello7) |
| 11:45:57 | | Quit thanosengine (Ping timeout: 248 seconds) |
| 11:47:50 | | Join thanosengine [0] (~thanos@user/thanosengine) |
| 11:58:46 | kirvesAxe | There's a lot of things nobody wants to do but still does out of necessity :( |
| 11:59:27 | speachy | priorities and all that |
| 12:00 |
| 12:06:50 | | Join Miho [0] (cbc2d70887@v2202101139504140605.quicksrv.de) |
| 12:07:37 | | Part Miho |
| 12:08:02 | | Join edhelas [0] (cbc2d70887@2a03:4000:51:f44:4e1:2ff:fe00:4257) |
| 12:09:43 | | Part edhelas |
| 12:30:34 | | Nick skipwich_ is now known as skipwich (~skipwich@user/skipwich) |
| 12:40:29 | | Quit thanosengine (Ping timeout: 260 seconds) |
| 12:46:23 | | Join dconrad_phone [0] (~dconrad_p@205.237.113.8) |
| 12:47:25 | dconrad_phone | _bilgus were you planning on merging the boot redirect fix? it tested ok on my end |
| 12:49:04 | dconrad_phone | once it's merged I'll make a test build for the v3 LCD init changes and try to get someone with a v3 player to test it out |
| 12:50:21 | dconrad_phone | One report of it not working correctly on the forum but I have a suspicion there may be a translation issue there so not sure... it definitely is inverted when I load the v3 bl on my v2 player ¯\_(ツ)_/¯ |
| 12:54:01 | dconrad_phone | really wish we could just read the ID bytes out of the LCD controller... I may need to spend a weekend trying to dig into that at some point, maybe I can figure out how to do that |
| 12:58:20 | | Quit dconrad_phone (Quit: Connection closed) |
| 13:00 |
| 13:09:09 | | Join lebellium [0] (~lebellium@2a01cb0405d07f00d33a0da62bfc2206.ipv6.abo.wanadoo.fr) |
| 13:23:05 | *** | Saving seen data "./dancer.seen" |
| 14:00 |
| 14:16:08 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 14:31:06 | | Quit skipwich (Quit: DISCONNECT) |
| 14:33:31 | | Join Everything [0] (~Everythin@109.162.122.37) |
| 14:38:11 | | Join skipwich [0] (~skipwich@user/skipwich) |
| 14:41:23 | | Join skipwich_ [0] (~skipwich@user/skipwich) |
| 14:43:09 | | Quit skipwich (Ping timeout: 252 seconds) |
| 14:43:09 | | Nick skipwich_ is now known as skipwich (~skipwich@user/skipwich) |
| 14:53:11 | | Join dconrad_phone [0] (~dconrad_p@205.237.113.8) |
| 14:55:33 | | Quit dconrad_phone (Client Quit) |
| 15:00 |
| 15:05:05 | | Join dconrad_phone [0] (~dconrad_p@205.237.113.8) |
| 15:05:28 | dconrad_phone | speachy: would it be possible for us to keep some erosq OF bootloader backups on wiki, similar to how we have patched OF update files? I think that would be pretty useful |
| 15:06:15 | dconrad_phone | obvs it may take a while to accumulate them |
| 15:06:23 | | Join skipwich_ [0] (~skipwich@user/skipwich) |
| 15:07:00 | speachy | don't see why not. they don't necessarily have to live on the wiki; they could be a static page on the main www site or something? |
| 15:07:45 | dconrad_phone | I was thinking of having a table on the wiki page is all |
| 15:08:06 | | Quit skipwich (Ping timeout: 252 seconds) |
| 15:08:06 | | Nick skipwich_ is now known as skipwich (~skipwich@user/skipwich) |
| 15:08:08 | speachy | with the files living on the download site, or as wiki attachments? |
| 15:08:44 | speachy | (the former is preferable for longer-term maintenance, IMO..) |
| 15:09:54 | dconrad_phone | either works for me... can users (i.e. me) upload attachments to wiki? |
| 15:10:04 | speachy | I believe so? |
| 15:10:34 | dconrad_phone | I don't want to have to bother you every time we get a new file to upload, is all |
| 15:10:51 | dconrad_phone | though I guess there arent that many anyway |
| 15:11:11 | speachy | shouldn't be more than ~1:1 for fw versions. or so one would think... |
| 15:11:22 | | Quit Everything (Quit: leaving) |
| 15:11:27 | dconrad_phone | yeah that's true |
| 15:11:27 | speachy | (many of the update.upt files include a bootloader fwiw) |
| 15:12:19 | | Join skipwich_ [0] (~skipwich@user/skipwich) |
| 15:12:43 | | Quit skipwich (Ping timeout: 264 seconds) |
| 15:13:11 | dconrad_phone | that was what I thought, but I think making an easy way to "go back" will help reduce friction |
| 15:13:22 | | Nick skipwich_ is now known as skipwich (~skipwich@user/skipwich) |
| 15:13:31 | dconrad_phone | or, an easily explainable way |
| 15:17:14 | dconrad_phone | actually, I bet its technically possible to extract the OF bootloader from the upt file... maybe I'll look at that and see if I can maybe figure that out |
| 15:17:36 | dconrad_phone | if its at a fixed location maybe I can |
| 15:17:42 | speachy | but it is _critically_ important that the user flashes the correct bootloader back. |
| 15:17:58 | dconrad_phone | yes, definitely |
| 15:18:16 | speachy | I doubt it's in a fixed location; you'd have to intelligently extract the file |
| 15:18:25 | speachy | (it's just an iso9660 image after all) |
| 15:18:45 | dconrad_phone | oh, would it be a separate file in the image? |
| 15:18:56 | speachy | yeah |
| 15:19:02 | dconrad_phone | well that would be easy to do by hand then |
| 15:19:04 | speachy | let me check a couple at random |
| 15:19:58 | dconrad_phone | it's been a couple years since I went on my decompilatio excursion so I thought it was all just one big binary |
| 15:19:58 | speachy | uboot.bin? or something else? |
| 15:20:44 | speachy | (not sure if the uboot.bin includes the SPL...) |
| 15:21:15 | dconrad_phone | might be? I've got a v1.5 bootloader backup, maybe I could check with a md5sum or such and see if it matches |
| 15:22:04 | speachy | if it does that also provides an alternative mechanism for getting the native bootloader installed. |
| 15:23:06 | dconrad_phone | hmm... that seems too easy haha, I suspect there's a reason we didn't do it that way in the first place, but I'll look at that when I get home tonight |
| 15:23:09 | *** | Saving seen data "./dancer.seen" |
| 15:24:12 | dconrad_phone | along with try installing the OF over the native bl to try it out and help guide that guy on the forums trying to uninstall the native |
| 15:24:38 | speachy | the fiio m3k wasn't a hibyos platform |
| 15:24:48 | speachy | but all of our other x1000s are |
| 15:24:53 | dconrad_phone | ah, so... maybe |
| 15:25:26 | speachy | the fiio update process was... baroque, to say the least. (it was basically the stock ingenic example, didn't even change the sample crypto keys IIRC) |
| 15:26:03 | dconrad_phone | would that provide an avenue for rbutil support? I know jztool and rbutil are kind of diametrically opposed, and getting them to work together is kind of a nonstarter |
| 15:27:16 | speachy | the problem with rbutil is that it doesn't have any way of understanding the hw variations. |
| 15:27:45 | speachy | so there's no way to automagically select the correct starting point (and knowing which binary patch to apply) |
| 15:29:09 | speachy | although.. a native port could theortically just modify uboot.bin in-place and that's entirely dooable. |
| 15:29:41 | dconrad_phone | I would have figured it's just pulling pre-patched fw images? |
| 15:29:55 | dconrad_phone | does rbutil do the patching then and there? |
| 15:30:20 | speachy | no.. it pulls a bsdiff and expects the user to supply the factory upt |
| 15:30:42 | speachy | (of course, it doesn't understand that there are multiple hw/fw versions either) |
| 15:30:48 | dconrad_phone | oh, I see |
| 15:31:23 | speachy | the pre-patched images are there to reduce the support burden |
| 15:31:32 | dconrad_phone | so probably each "surfans v3.x" would be its own entry in the list |
| 15:31:59 | speachy | each OF version would potentially have its own entry. or maybe more than one for all we know. |
| 15:32:24 | speachy | (thanks to NAND chip variations, perhaps) |
| 15:32:55 | dconrad_phone | well, fortunately the bl just supports all the nand chips we know about simultaneously |
| 15:33:27 | dconrad_phone | the only weirdness right now is the v3 LCD, and I have dreams of polling it for its ID |
| 15:33:29 | speachy | yeah, but we started about being able to to back to the factory firmware. :D |
| 15:33:37 | speachy | the LCD is SPI-attached, correct? |
| 15:33:37 | dconrad_phone | yeah... lol |
| 15:33:48 | dconrad_phone | I'm not actually sure, tbh |
| 15:33:57 | dconrad_phone | I'm that unfamiliar with it |
| 15:34:30 | dconrad_phone | I kind of thought it was some special system |
| 15:35:43 | speachy | based on the lagginess of the stock firmware I suspect it's SPI (as opposed to some sort of parallel bus) |
| 15:36:53 | speachy | ok.. it uses the x1000's "lcd controller" |
| 15:38:00 | speachy | output-only |
| 15:38:07 | dconrad_phone | aw dang |
| 15:38:23 | speachy | the panel _might_ have another command path |
| 15:39:09 | speachy | backlight is PWM controlled... |
| 15:39:58 | dconrad_phone | ... wonder if we could disable the lcd controller momentarily and either use a generic spi peripheral or just bit-bang it too |
| 15:40:18 | speachy | that depends on the display controller itself |
| 15:40:52 | speachy | their controllers usually can operate in multiple modes but that doesnt' mean they're pinned out fully |
| 15:41:44 | speachy | (or tho pins that control which mode it runs in might be tied high/low, or to GPIOs) |
| 15:42:02 | speachy | need a teardown with the LCD/controller specifics. :( |
| 15:42:03 | dconrad_phone | oh... yeah its possible MISO isn't even hooked up isnt it |
| 15:43:18 | dconrad_phone | well we know the vague types, ILI 9342 and gc9a01, supposedly |
| 15:45:03 | speachy | GC9a01 seems to be a circular display? |
| 15:45:42 | speachy | the IL9432 does support bidir communication though |
| 15:46:03 | dconrad_phone | ... maybe not then, I thought it was just a controller |
| 15:46:32 | | Join skipwich_ [0] (~skipwich@user/skipwich) |
| 15:46:39 | | Quit dconrad_phone (Quit: Connection closed) |
| 15:46:50 | | Join dconrad_phone [0] (~dconrad_p@205.237.113.8) |
| 15:48:05 | | Quit skipwich (Ping timeout: 248 seconds) |
| 15:48:35 | dconrad_phone | seems like that might definitely be wrong, found a datasheet that says it's 240x240 max |
| 15:48:41 | dconrad_phone | hmm |
| 15:48:56 | speachy | all of the hits I found for the GC9A01 are for spi-attached 240x240 round displays, though they do list the controller as that GC9A01 |
| 15:48:56 | | Join skipwich [0] (~skipwich@user/skipwich) |
| 15:49:24 | dconrad_phone | yeah, I'm starting to doubt that's it |
| 15:49:33 | speachy | ah there's a datasheet finally |
| 15:49:38 | speachy | yeah, probably not it |
| 15:49:54 | speachy | do we have a linux boot log for the v3.x devices? |
| 15:49:59 | speachy | that might have something useful |
| 15:50:42 | dconrad_phone | maybe someone already uploaded one to the forums? I'm not immediately aware of it tho |
| 15:51:28 | dconrad_phone | but I should probably update things to say it's doubtful that's it |
| 15:52:27 | | Quit skipwich_ (Ping timeout: 276 seconds) |
| 15:52:40 | speachy | gotta love the forum posts that are more or less "I did the things that the documentation says to NOT do, and it didnt' work" |
| 15:53:49 | dconrad_phone | yuuuup |
| 15:59:09 | | Join skipwich_ [0] (~skipwich@user/skipwich) |
| 16:00 |
| 16:01:29 | | Quit skipwich (Ping timeout: 258 seconds) |
| 16:02:22 | | Join skipwich [0] (~skipwich@user/skipwich) |
| 16:04:33 | | Quit skipwich_ (Ping timeout: 252 seconds) |
| 16:08:33 | | Quit dconrad_phone (Quit: Connection closed) |
| 16:32:07 | | Join dconrad_phone [0] (~dconrad_p@205.237.113.8) |
| 16:33:20 | dconrad_phone | ah, that explains it. I must have seen "unknown type, partially gc9a01 compatible" and just shortened it right down to "gc9a01" haha |
| 16:40:23 | | Quit dconrad_phone (Quit: Connection closed) |
| 16:40:58 | speachy | aaah |
| 16:41:17 | speachy | but that doesn't mean it's hooked up in a way we could read someting back out. |
| 16:41:46 | | Join dconrad_phone [0] (~dconrad_p@205.237.113.8) |
| 16:41:48 | speachy | I'd be shocked if the actual PCB doesn't have a hardware version readback hooked up to some GPIOs. |
| 16:42:04 | speachy | but that's.. tough to figure out. |
| 16:42:12 | speachy | at least non-destructively. |
| 16:42:56 | dconrad_phone | it seems like they just change things by using a different firmware install though? |
| 16:43:13 | dconrad_phone | people install newer versions and it breaks things |
| 16:43:37 | speachy | there's no inherent reason why they couldn't support all of the HW versions with a single firmware image. |
| 16:43:44 | speachy | (perhaps with unique bootloaders per hw revision) |
| 16:44:11 | speachy | (but possibly even with a single bootloader, if it is capable of detecting the HW version somehow) |
| 16:45:14 | speachy | basically this "Every minor revision has a unique bespoke linux+userspace image" is pretty crappy engineering. |
| 16:45:35 | dconrad_phone | oh, yeah no argument there |
| 16:46:51 | dconrad_phone | but it kinda seems like that's precisely what they're doing |
| 16:47:42 | | Join dddddddd [0] (~dddddddd@93-86-49-113.static.isp.telekom.rs) |
| 16:48:21 | | Part dddddddd |
| 16:53:54 | | Join skipwich_ [0] (~skipwich@user/skipwich) |
| 16:54:38 | dconrad_phone | well, I suppose we know what gpio pins we currently /don't/ use, we could read them back and compare v1/v2/v3 and see if we see a pattern |
| 16:54:44 | speachy | most of the uboot bins from the UPTs I have are different. the exceptions are erosq_v1.8 == erosk_v1.3, and f20_v3.0 == h2_v1.6 |
| 16:55:11 | | Quit skipwich (Ping timeout: 255 seconds) |
| 16:55:23 | dconrad_phone | interesting |
| 16:57:10 | speachy | build strings differ, if nothing else |
| 16:57:15 | | Join skipwich [0] (~skipwich@user/skipwich) |
| 16:57:58 | dconrad_phone | is that in the bin as a string? |
| 16:58:22 | speachy | yeah |
| 16:59:11 | | Quit skipwich_ (Ping timeout: 252 seconds) |
| 16:59:17 | speachy | eg out of the F20_v3.0 uboot binary: U-Boot SPL 2013.07 (Dec 08 2023 - 16:12:11) |
| 17:00 |
| 17:02:11 | | Join skipwich_ [0] (~skipwich@user/skipwich) |
| 17:03:38 | dconrad_phone | here's an out there idea... could we extract the uboot.bin, parse for the build string, then compare that against a database of known strings and select player hw version against that? |
| 17:04:04 | dconrad_phone | or is that too wacky |
| 17:04:05 | speachy | why bother with that? just use the sha1sum of the uboot binary instead |
| 17:04:16 | dconrad_phone | oh sure, yeah |
| 17:04:30 | speachy | or just use the sha1sum of the entire update.upt image to begin with |
| 17:04:41 | | Quit skipwich (Ping timeout: 252 seconds) |
| 17:04:41 | | Nick skipwich_ is now known as skipwich (~skipwich@user/skipwich) |
| 17:16:10 | dconrad_phone | does rbutil also accept a pre-patched firmware update file then? I notice the stock images aren't linked on the wiki |
| 17:17:38 | speachy | I got rid of all of that. I guess the only sane thing to do in rbutil is to make it just use a prepatched file. |
| 17:18:02 | speachy | but it cant' automatically download the correct one, so that means each fw revision might need their own device entry.. |
| 17:21:52 | dconrad_phone | that doesn't sound too bad to me tbh |
| 17:22:38 | speachy | oh, the bootloader isn't updated as part of some/most of the various update.upt files |
| 17:22:49 | speachy | it's present but not in the update manifest. |
| 17:22:59 | speachy | and I'm mostly sure the binary includes the SPL. |
| 17:23:10 | dconrad_phone | I see |
| 17:23:12 | *** | Saving seen data "./dancer.seen" |
| 17:23:25 | speachy | adding it to the update manifest is pretty easy |
| 17:23:42 | speachy | little more than partition, filename, md5sum |
| 17:24:01 | dconrad_phone | partition? |
| 17:25:04 | | Join edhelas__ [0] (cbc2d70887@2a03:4000:51:f44:4e1:2ff:fe00:4257) |
| 17:27:17 | dconrad_phone | oh, the name field, I presume |
| 17:31:39 | | Part edhelas__ |
| 17:31:58 | | Join edhelas__ [0] (cbc2d70887@2a03:4000:51:f44:4e1:2ff:fe00:4257) |
| 17:32:17 | | Quit lebellium (Quit: Leaving) |
| 17:32:31 | | Quit dconrad_phone (Quit: Connection closed) |
| 17:32:55 | | Part edhelas__ |
| 17:36:49 | | Join miho [0] (cbc2d70887@2a03:4000:51:f44:4e1:2ff:fe00:4257) |
| 17:43:18 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 17:46:34 | | Part miho |
| 17:48:18 | | Join bilgusphone [0] (~bilguspho@166.199.114.61) |
| 17:49:04 | bilgusphone | Dconrad i pushed the boot verification patch i DONT think I have anything ELE waiting or are you asking about the v3 patch of yours? |
| 17:49:20 | bilgusphone | Else* |
| 17:49:45 | | Quit bilgusphone (Client Quit) |
| 17:52:35 | speachy | looks like Sandisk announced a 4TB SDUC card. |
| 17:54:44 | | Join bilgusphone [0] (~bilguspho@166.199.114.61) |
| 17:55:04 | | Join skipwich_ [0] (~skipwich@user/skipwich) |
| 17:55:19 | bilgusphone | Bet i wont be buying one for a few years |
| 17:56:26 | bilgusphone | Would you be able to try different displays and have the user press a button like if you see this screen press vol up |
| 17:56:44 | bilgusphone | Another could be vol DN and the third the power button or something |
| 17:57:30 | | Quit skipwich (Ping timeout: 272 seconds) |
| 17:57:31 | | Nick skipwich_ is now known as skipwich (~skipwich@user/skipwich) |
| 18:00 |
| 18:01:22 | | Quit bilgusphone (Ping timeout: 248 seconds) |
| 18:07:46 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 18:08:45 | | Join davisr [0] (~davisr@fsf/emeritus/davisr) |
| 18:08:47 | dconrad | bilgusphone g#5888 is what I was referring to, that should actually allow boot redirect to happen |
| 18:08:50 | rb-bluebot | Gerrit review #5888 at https://gerrit.rockbox.org/r/c/rockbox/+/5888 : Bootloaders: Include HAVE_MULTIVOLUME if BOOT_REDIR also present by Dana Conrad |
| 18:10:23 | speachy | I didn't dig into that to understand why that's needed; my (incorrect?) assumption is that multivolume only mattered if you were atempting to mount multiple volumes simultaneously. |
| 18:10:38 | speachy | s/multivolume/HAVE_MULTIVOLUME/ |
| 18:11:13 | speachy | is that because BOOT_REDIR uses the MV data structures to know what's what? |
| 18:11:41 | speachy | (And yes, I disabled it in bootloaders purely to save space) |
| 18:14:11 | dconrad | I imagine that's the case, yes, though I only went "well it works before this and not at this commit so..." |
| 18:18:39 | speachy | hmm, looks like it expects everything to be mounted. |
| 18:18:43 | dconrad | no surprise: our homemade bootloader backup does not md5sum match the uboot.bin included in the appropriate update UPT (or at least for my v1.5 player) |
| 18:18:45 | speachy | c'est la fie. |
| 18:18:56 | speachy | it might be differently-sized? |
| 18:19:24 | speachy | (ie the bin doesn't fill the entire flash partition) |
| 18:19:54 | dconrad | yeah, uboot.bin=349k, erosqnative-boot.bin=131k |
| 18:20:41 | speachy | uboot is definitely larger than 131k.. |
| 18:21:16 | dconrad | could be we only backup the part that we overwrite |
| 18:21:29 | speachy | unless uboot is a secondary loader; the spl loads something else which then loads uboot. |
| 18:22:56 | dconrad | I was thinking about exploring whether/how to restore the stock bootloader via the upt file, I've got an old v1 player here |
| 18:38:23 | | Quit dconrad (Remote host closed the connection) |
| 18:41:29 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 18:42:17 | dconrad | hmm, my player is rejecting our v1.3 update file as update not found, it just needs to be named "update.upt" and on the root, right? |
| 18:44:15 | dconrad | I'll let it format the card itself, maybe something is weird there |
| 18:56:20 | dconrad | eh, there's something weird with this player, it can't read the card at all somehow |
| 19:00 |
| 19:14:21 | dconrad | ah, complication: somehow the v1.3 player cannot read the SD card with the native port installed? but my v1.5 player definitely can. weird. |
| 19:17:48 | dconrad | hm. The stock updater reboots the device, which then hits our bootloader instead |
| 19:18:11 | dconrad | (I installed the current native bootloader and that fixed the weirdness) |
| 19:23:14 | *** | Saving seen data "./dancer.seen" |
| 19:36:55 | | Quit davisr (Quit: yeehaw) |
| 19:43:45 | dconrad | HOWEVER... the good news is that you can open up a hex editor, grab precisely the first 128kb (to offset 0x20000) of uboot.bin and plop it in a new .bin file and it seems to work as a backup file, at least on my hifiwalker v1.3 player |
| 19:46:29 | dconrad | however the md5sums don't match, but it's possible that "my" v1.3 is different from the v1.3 update I downloaded off the net |
| 19:55:53 | dconrad | also, if I re-enable the Aigo OF's recovery mode in our bootloader, it appears to work when it finds the update.upt on the card |
| 19:56:05 | dconrad | .... all the above is a lot to parse |
| 20:00 |
| 20:10:04 | dconrad | speachy: do you know what the entry would look like to enable overwriting the bootloader in the update.txt file? |
| 20:10:30 | dconrad | I would like to try it on this v1.3 player, see what happens |
| 20:25:55 | | Join jj5_ [0] (~jj5@100.80.216.139.dynamic.dsl.dv.iprimus.net.au) |
| 20:26:28 | | Quit jj5 (Read error: Connection reset by peer) |
| 21:00 |
| 21:04:54 | dconrad | It also seems that, to no-one's surprise, there is no reason to cut down the uboot.bin file, you can just restore it in its entirety via the native bootloader |
| 21:05:44 | dconrad | (I tried just that on the v1.3 player and it worked fine) |
| 21:23:16 | *** | Saving seen data "./dancer.seen" |
| 21:24:46 | | Join skipwich_ [0] (~skipwich@user/skipwich) |
| 21:26:42 | | Quit skipwich (Ping timeout: 248 seconds) |
| 21:26:42 | | Nick skipwich_ is now known as skipwich (~skipwich@user/skipwich) |
| 21:33:18 | dconrad | It has also crossed my mind that if we were able to use hardware volume scaling on the v2+ units, I could probably live with the hosted port... |
| 21:49:20 | dconrad | and yeah, reviewing the bootloader code, it seems that we only back up enough to fit the bootloader, and no more |
| 21:49:40 | dconrad | well, rounding up to the ...block?.... size |
| 21:59:52 | dconrad | _bilgus: if you could also merge g#5872 when you get around to doing g#5888, both are ready to go as far as I can see. |
| 21:59:59 | rb-bluebot | Gerrit review #5872 at https://gerrit.rockbox.org/r/c/rockbox/+/5872 : ErosQNative: Set extra ES9018K2M options by Dana Conrad |
| 21:59:59 | rb-bluebot | Gerrit review #5888 at https://gerrit.rockbox.org/r/c/rockbox/+/5888 : Bootloaders: Include HAVE_MULTIVOLUME if BOOT_REDIR also present by Dana Conrad |
| 22:00 |
| 22:12:17 | | Quit dconrad (Remote host closed the connection) |
| 22:33:45 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 23:00 |
| 23:23:19 | *** | Saving seen data "./dancer.seen" |
| 23:52:28 | _bilgus | dconrad, ah ok |
| 23:52:55 | _bilgus | give me a minute to look at this if we can do it without including MULTIVOLUME |
icon identifies that the person is a core developer (has commit access).