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).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2021-08-21

00:12:45***Saving seen data "./dancer.seen"
02:00
02:12:47***No seen item changed, no save performed.
03:00
03:30:36 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de)
04:00
04:12:50***No seen item changed, no save performed.
05:00
05:28:38 Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:4423:4dcc:dba8:6f39)
06:00
06:11:13 Join akaWolf [0] (~akaWolf@2a05:3580:df03:1a00:21e:8cff:fe18:61)
06:12:53***No seen item changed, no save performed.
07:00
07:19:43 Quit akaWolf (Remote host closed the connection)
07:23:23 Join akaWolf [0] (~akaWolf@akawolf.org)
08:00
08:12:56***Saving seen data "./dancer.seen"
08:52:45 Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net)
10:00
10:12:57***No seen item changed, no save performed.
10:35:45 Quit tomato (Ping timeout: 248 seconds)
10:49:01 Join tomato [0] (~tomato@user/tomato)
11:00
11:11:04 Join F3l1x_10m [0] (~Al3x_10m@user/f3l1x-10m/x-3393542)
12:00
12:09:14 Quit speachy (Quit: WeeChat 3.2)
12:13:00***Saving seen data "./dancer.seen"
13:00
13:14:27 Join speachy [0] (~speachy@209.2.65.77)
13:14:27 Quit speachy (Changing host)
13:14:27 Join speachy [0] (~speachy@rockbox/developer/speachy)
13:14:27Mode"#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat)
13:39:05 Join look [0] (~look@e200114.upc-e.chello.nl)
13:39:42lookhello! can rockbox run on the sandisk clip sport plus?
13:41:36lookor does it only work on older models?
13:42:04 Join johnb2 [0] (~johnb2@p4fd1050e.dip0.t-ipconnect.de)
13:42:11johnb2No
13:42:28johnb2only what is listed on the front page
13:42:37lookwell, too bad, thanks for the quick reply :)
13:59:52 Quit johnb2 (Ping timeout: 250 seconds)
14:00
14:13:01***Saving seen data "./dancer.seen"
14:24:50 Join ats [0] (~ats@cartman.offog.org)
14:36:04 Quit cb (Ping timeout: 272 seconds)
16:00
16:07:39 Join cb [0] (~calvin@fctnnbsc38w-47-55-90-145.dhcp-dynamic.fibreop.nb.bellaliant.net)
16:13:02***Saving seen data "./dancer.seen"
17:00
17:08:59 Nick emacsoma1 is now known as emacsomancer (~emacsoman@136.60.128.68)
17:09:16 Join dconrad [0] (~dconrad@208.38.228.17)
17:23:39 Quit dconrad (Remote host closed the connection)
17:45:18 Quit lebellium (Quit: Leaving)
18:00
18:13:05***Saving seen data "./dancer.seen"
18:20:08braewoodsspeachy: i got an xduoo x3 but USB isn't working that I can tell. is this normal? it only seems to perform charging.
18:20:21braewoodsmaybe it's the cable. i'll try a different one.
18:21:37braewoodsoh joy. it's a charge only cable. no data lines.
18:23:01braewoodsweird. it makes a clicking sound or something when i turn it on.
18:32:16 Join dconrad [0] (~dconrad@208.38.228.17)
18:52:03 Join JanC_ [0] (~janc@user/janc)
18:54:10 Quit JanC (Ping timeout: 240 seconds)
18:55:07 Nick JanC_ is now known as JanC (~janc@user/janc)
19:00
19:15:22 Quit tchan (Ping timeout: 268 seconds)
19:15:42 Join tchan [0] (~tchan@c-98-206-141-238.hsd1.il.comcast.net)
19:25:12speachyyep, relays in the power supply section
19:26:53braewoodsspeachy: pretty solid device but mine is a bit weird. i have to use a tool to get my sd card to lock into place.
19:27:12braewoodsalso, does rockbox care which sd card it is stored on?
19:28:04speachynope, but IIRC the bootloader won't fail over to the second card if both are inserted at startup
19:28:35braewoodsinteresting.
19:29:14speachyold old bootloader build, lots of bugs fixed since then but didn't have the ability to generate a new flashable image
19:29:38braewoodswhy's that?
19:29:58braewoodsthe process isn't understood?
19:30:01braewoodstoo large?
19:30:15speachyit was manually put together by xvortex.
19:30:20braewoodsoh.
19:30:27braewoodsso you don't know how to do it.
19:31:01braewoodsspeachy: what bugs were fixed that pertain to the bootloader?
19:32:01speachywe can piggyback on the x1000 work done by amachronic. rework the build to generate the spl at the same time, then figure out how to retain dualboot
19:32:35braewoodsthis would work for the X3? even though it's a different SOC?
19:32:54speachyfundamental low-level issues in the clocking and sd code, plus a lot of minor niggles in the bootloader itself
19:33:02braewoodsah i see.
19:33:38speachythe low-level platform code (startup, asm routines, etc) also had a lot of issues I've since fixed.
19:34:04braewoodswe should probably patch it then but how?
19:34:18speachythis was about the time the hardware turned into mostly unobtanium
19:34:27braewoodsi got my hands on one.
19:34:30braewoodsrecently
19:34:32braewoodsbut yea
19:34:37braewoodsit's rare to find on ebay
19:34:40speachyand my motivation to keep at it dwindled considerably.
19:35:03speachythe x1000 is an evolution of the jz47xx series
19:35:27braewoodsso how can we generate a new flash image?
19:36:06braewoodsis there even any interest in trying to fix this now?
19:36:24speachyhave to generate a new flashable image, which means generating the spl (ie 1st-stage bootloader) that can then bootstrap the rest out of NAND
19:36:44braewoodsis part of that already handled by rockbox tool chain?
19:37:41speachyIIRC what actually was done is that the OF bootloader was hacked to load rockbox instead of the main linux system
19:38:00speachy(I mean the rockbock bootloader binary)
19:38:16speachyusnig the lock switch to determine which one was invoked
19:38:39braewoodsbasically the same trigger used on the gigabeat S
19:38:52speachyxvortex was kinda vague on how he did it and couldn't provide any technical details/scripts
19:39:07speachyand I didn't have the bandwidth to reverse-engineer things further
19:39:59speachyhe then took the stock OF firmware update image, and hacked in scripts/etc to ensure the patched bootloader flash partition was properly updated.
19:41:56speachythat latter stuff is easy to reuse but the trick is to fix up
19:42:40braewoodsso i need to find a place to launch the bootloader from
19:42:46speachythe original bootloader image. IIRC xduoo never provided a pristine bootloader to work from
19:43:01speachy(or sources)
19:43:41speachybut in theory the new rockbox bootloader binary could be patched into the correct place of that binary and things will JustWork(tm)
19:43:58speachyjust a matter of motivation+time
19:45:44braewoodsi wonder if we can use uboot to launch it.
19:46:47braewoodsaccording to the wiki there's two options
19:47:03braewoodsafter linux boots is probably untenable unless kexec or similar is a choice
19:50:31speachyI believe the real work is done in the stage1 spl. based on the switch it reads either the rockbox or uboot.
19:51:31braewoodsit suggests the first tier bootloader is 8KB
19:52:02braewoodssays nothing about where it is loaded from.
19:52:16braewoodsjust from the NAND.
19:52:33speachyyep, looks like the rb bootloader binary is at offset 0x2000
19:53:30braewoodsthere's no attempt to document the NAND
19:53:37braewoodsso hard to say
19:54:24braewoodshm
19:54:39braewoodswe need a better way to install the bootloader
19:54:54braewoodssomething like beastpatcher for the xduo
19:55:16speachyit's easy enough to modify the hacked update image.
19:55:33speachyas that piggybacks on the existing xduoo update process
19:55:57braewoodsi know just would like a better solution than binary diff
19:56:00braewoodsif that makes sense
19:56:28speachywe only bother with a binary diff due to the technically-not-allowed distribution of xduoo firmware images
19:57:40braewoodsanother option is to figure out how to repack it.
19:57:59speachyand the uboot binary starts at offset 0x22004
19:58:01braewoodsbut in any case there's no way to update it until we can figure out how the existing hack works.
19:58:16speachyso we have 128K to play with.
19:58:44braewoodsit looks like we can recover if we botch it
19:58:47braewoodsis that correct?
19:59:13braewoods" The JZ4760 chip has a usb recovery mode documented in the datasheet. The xDuoo X3 can be put in this mode by the following procedure: "
19:59:17speachyyes but it's going to involve using jztool
19:59:26speachyso it's not straightforward.
19:59:42braewoodswell that'll help if i need to recover from a bad attempt
20:00
20:00:10braewoodsthis is a pretty good unit
20:00:39braewoodsin any case
20:01:04braewoodsit sounds like you're saying i should work off the existing update payload
20:01:22braewoodsand see if i can hack the bootloader over the existing spot.
20:01:36speachyyep. don't see why that won't work, aside from the ususal bootloader bugs
20:01:56braewoodsif the entry point is retained it should work
20:02:20braewoodslet's see if the bootloader still compiles
20:02:36speachyit does.
20:03:03braewoodso.O i see
20:03:14braewoodsi need to recompile my toolchains since i lack mips
20:03:29braewoodsspeachy: looks like i've found my next project once i finish with gigabeat S
20:04:19braewoodsi think the xduo should get a fix up. it's hard to find but it still pops up so it's not like the hd300. :P
20:04:47braewoodsspeachy: btw, where did you get these numbers?
20:05:02speachyinspecting the binary
20:05:05braewoodsOh.
20:05:27braewoodsso rockbox bootloader is placed right after the first 8K?
20:05:33speachyappears that way
20:05:35braewoodsstarting at location 0x2000 or 8192
20:05:54braewoodsinteresting
20:06:16braewoodswell given what i'm reading it could be as simple as overlaying a new bootloader binary at that location
20:06:25braewoodsas long as it doesn't touch ubot
20:06:42braewoodsyou know what's funny?
20:06:47speachyas long as the binary is 128KB or less
20:06:58braewoodsyea, no different than how coldfire is.
20:07:05braewoodsit's placed at the last 64K of the ROM
20:07:14speachybtw this is rearranged from the the OF. u-boot must have been compiled to be relocatable.
20:07:40braewoodsif i get a working update zip
20:07:54braewoodswill you want to setup a new bdiff for it?
20:08:20braewoodsit's probably easiest to try to work off the existing one
20:08:24speachyyep, there are definitely issues with the ancient snapshot that binary was generated from
20:08:44braewoodsyou mean the bootloader we have?
20:08:50braewoodsthat's the main thing we got
20:09:04braewoodsthe rest should largely just be the OF
20:09:07braewoodswarts and all
20:09:20speachyyep
20:09:40speachygimme a few to confirm this
20:09:46speachybefore you possibly brick things
20:10:35braewoodsok
20:13:05 Quit ZincAlloy (Quit: Leaving.)
20:13:08***Saving seen data "./dancer.seen"
20:18:05 Quit dconrad (Remote host closed the connection)
20:23:00braewoodsseems the rootfs image was modified
20:23:03braewoodswhat else
20:23:29*braewoods boggles.
20:23:36braewoodsthe linux kernels are also different
20:29:31 Join dconrad [0] (~dconrad@208.38.228.17)
20:54:41speachybraewoods: it looks like that should be safe
20:55:03braewoodsit looks like they patched the uboot kernel
20:55:07braewoodsgiven the script differences
20:55:11braewoodserr
20:55:13braewoodsuboot image
20:56:59speachyI'm still missing where it skips over the spl when it copies the data out of nand but otherwise yeah, it's clearly just blindly reading at one offset or the other based on the lock switch
20:58:17speachyso it's safe to blindly replace the rockbox binary at 128K at offset 2K.
20:58:45braewoodsi don't know why he changed the linux kernels
20:58:52braewoodsit may have just been changes to their containers
20:59:01speachydunno.
20:59:37speachywe can strip out the kernels & rootfs so the update image only mangles the bootloader partition.
21:00
21:12:30braewoodswould there be a point to that?
21:12:37braewoodsin any case i'll do some research into it
21:12:53speachymakes for a much smaller image only containing what's needed.
21:13:11speachythe bootloader definitely needs work.
21:13:35braewoodswell i'd want to know what the original changed and why
21:13:48braewoodsi'm going to look at the linux kernel and see how it differs
21:13:58speachydon't bother with the linux side of things
21:14:05speachywe genuinely don't care.
21:14:16speachysince it has no effect on anything we actually execute.
21:14:27braewoodsthe uboot part does
21:14:34braewoodsto a degree
21:15:09speachyhmm. I suppose it's possible they rejiggered the flash layout
21:15:23speachyto make room for the rockbox bootloader binaru
21:33:38 Quit look (Read error: Connection reset by peer)
21:49:57braewoodsspeachy: i think i see why he modded it.
21:50:07braewoodsi compared the actual files in it
21:50:14braewoodsthere's hooks for arbitrary code execution.
21:50:36braewoodsin the final product this should not be needed.
21:50:56braewoodslikewise the kernels can probably be kept unmodded
21:52:23braewoodsgiven the lack of original source i want to keep the OF as pure as possible
21:52:41braewoodsthis bootloader smells of messy bits
21:52:52 Join cockroach [0] (~blattodea@user/cockroach)
21:53:54braewoodsthough it's weird how the OF wastes space on stuff it doesn't really need
21:54:07braewoodslike networking software when the SoC has no NICs
21:54:40speachyeh, would be extra effort to remove it
21:54:54speachythink of generic devlelopment boards
21:55:03speachyit's not like they needed flash space
21:56:32rb-bluebotBuild Server message: New build round started. Revision e07c460eef, 303 builds, 8 clients.
21:56:47speachyok, this will bring the essential bootloader fixups
21:57:20 Quit dconrad (Remote host closed the connection)
21:57:45speachythere's more work to be done (eg don't initialize the display unless there's an error or we're entering USB mode)
22:00
22:08:00braewoodsso far it seems the main changes under tools is the additions of 2 programs and the script
22:08:18braewoodsso i think we might be able to get away with just keeping those changes and updating uboot blob
22:08:34braewoodslet me see how the script is different
22:09:26braewoodsah just some script code to reprogram uboot
22:09:39braewoodsi can't see any reason to retain the changes to the rest of it
22:09:46braewoodsthe linux files anyway
22:10:01braewoodsprobably best to leave it alone since we're a hosted port now
22:10:07braewoodserr native
22:10:24 Quit cockroach (Ping timeout: 250 seconds)
22:10:29rb-bluebotBuild Server message: Build round completed after 838 seconds.
22:10:31rb-bluebotBuild Server message: Revision e07c460eef result: 4 errors 0 warnings
22:13:09***Saving seen data "./dancer.seen"
22:14:22braewoodsspeachy: DANGER WILL ROBINSON
22:22:47speachygrr. gonna have to blacklist uzziyah-munkis
22:23:08rb-bluebotBuild Server message: New build round started. Revision 2c9e2db721, 303 builds, 8 clients.
22:23:20speachyok, another commit of bootloader things.
22:23:51speachyat the point where I'd consider it ready to do the binary cut-n-paste
22:34:01 Quit advcomp2019 (Ping timeout: 252 seconds)
22:38:12rb-bluebotBuild Server message: Build round completed after 904 seconds.
22:38:14rb-bluebotBuild Server message: Revision 2c9e2db721 result: 4 errors 0 warnings
22:41:35braewoodsspeachy: same?
22:59:15 Join dconrad [0] (~dconrad@208.38.228.17)
23:00
23:01:41 Quit dconrad (Read error: Connection reset by peer)
23:01:52 Join dconrad [0] (~dconrad@208.38.228.17)
23:05:37 Quit skipwich (Ping timeout: 248 seconds)
23:08:16speachyI'll deal with the blacklist tomorrow if he dpesn't fix it by then
23:37:57braewoodsoh
23:47:03braewoodslol. xduoo x3 OF manual...
23:47:10braewoods"charing the battery"
23:47:33 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-f540-b6ad-b3a7-74ac.res6.spectrum.com)
23:54:01 Join Saijin_Naib_ [0] (~Saijin_Na@2603-7081-1d05-7230-a8f8-1a2e-1942-ed6e.res6.spectrum.com)
23:54:13 Join Saijin_Naib__ [0] (~Saijin_Na@2603-7081-1d05-7230-f540-b6ad-b3a7-74ac.res6.spectrum.com)
23:56:08 Quit Saijin_Naib (Ping timeout: 250 seconds)
23:58:18 Quit Saijin_Naib_ (Ping timeout: 250 seconds)

Previous day | Next day