| 01:00 |
| 01:37:22 | *** | No seen item changed, no save performed. |
| 01:40:34 | | Quit massiveH (Quit: Leaving) |
| 02:00 |
| 02:32:53 | | Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:d929:5489:91a5:dbdd) |
| 03:00 |
| 03:37:26 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:48:53 | | Quit emacsomancer (*.net *.split) |
| 04:48:53 | | Quit benjaoming (*.net *.split) |
| 04:49:05 | | Join benjaoming [0] (~benjaomin@37.139.19.237) |
| 04:49:38 | | Join emacsomancer [0] (~emacsoman@c-174-52-88-123.hsd1.ut.comcast.net) |
| 05:00 |
| 05:01:57 | DEBUG | EOF from server (Success) (snapshot: netstuff.c line 545) |
| 05:01:57 | *** | Cleanup |
| 05:01:57 | *** | Cleanup |
| 05:01:57 | *** | Saving seen data "./dancer.seen" |
| 05:01:57 | *** | Exit |
| 05:01:58 | *** | Started Dancer V4.16 |
| 05:01:58 | *** | Connected to irc.libera.chat on port 6667 |
| 05:01:58 | *** | Logfile for #rockbox started |
| 05:02:00 | Mode | "rb-logbot_ :+i" by rb-logbot_ |
| 05:02:06 | *** | Server message 501: 'rb-logbot_ :Unknown MODE flag' |
| 05:02:06 | | Join rb-logbot_ [0] (~rockbox@stuffed.shaftnet.org) |
| 05:02:06 | | Join Lain_ [0] (~toruvinn@77-255-90-179.adsl.inetia.pl) |
| 05:02:06 | | Join emacsomancer [0] (~emacsoman@c-174-52-88-123.hsd1.ut.comcast.net) |
| 05:02:06 | | Join benjaoming [0] (~benjaomin@37.139.19.237) |
| 05:02:06 | | Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:d929:5489:91a5:dbdd) |
| 05:02:06 | | Join _bilgus [0] (~bilgus@162.154.213.134) |
| 05:02:06 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 05:02:06 | | Join F3l1x_10m [0] (~Al3x_10m@user/f3l1x-10m/x-3393542) |
| 05:02:06 | | Join f1refly [0] (~f1refly@pd954c410.dip0.t-ipconnect.de) |
| 05:02:06 | | Join tomf [0] (tomf@our.lady.of.perpetual.faith) |
| 05:02:06 | | Join MarcAndersen [0] (~no_znepna@193.169.154.231) |
| 05:02:06 | | Join asaba [0] (~asabas@103.113.159.184) |
| 05:02:06 | | Join wisperwind [0] (~quassel@user/wisperwind) |
| 05:02:06 | | Join Topy44 [0] (1fWVmwmjHs@bellatrix.uberspace.de) |
| 05:02:06 | | Join aquijoule_ [0] (~richbridg@213-225-5-235.nat.highway.a1.net) |
| 05:02:06 | | Join j-r [0] (~j-r@p2003000621560754404207fffefd0a65.dip0.t-ipconnect.de) |
| 05:02:06 | | Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) |
| 05:02:06 | | Join amiconn [0] (jens@p2e55b6bb.dip0.t-ipconnect.de) |
| 05:02:06 | | Join pixelma [0] (marianne@p2e55b6bb.dip0.t-ipconnect.de) |
| 05:02:06 | | Join yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de) |
| 05:02:06 | | Join braewoods [0] (~braewoods@user/braewoods) |
| 05:02:06 | | Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7) |
| 05:02:06 | | Join kadoban [0] (~kadoban@user/kadoban) |
| 05:02:06 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 05:02:06 | | Join markun [0] (~markun@178-84-100-63.dynamic.upc.nl) |
| 05:02:06 | | Join spork [0] (topic@31-151-2-135.dynamic.upc.nl) |
| 05:02:06 | | Join JanC [0] (~janc@user/janc) |
| 05:02:06 | | Join hook54321 [0] (sid149355@user/hook54321) |
| 05:02:06 | | Join rasher [0] (~rasher@user/rasher) |
| 05:02:06 | | Join rb-logbot [0] (~rockbox@stuffed.shaftnet.org) |
| 05:02:06 | | Join toruvinn [0] (~toruvinn@77-255-90-179.adsl.inetia.pl) |
| 05:02:06 | | Join vup [0] (~~~~@46.101.193.235) |
| 05:02:06 | | Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) |
| 05:02:06 | | Join Xeha [0] (~Xeha@dynamic-82-220-88-142.ftth.solnet.ch) |
| 05:02:06 | | Join desowin [0] (~linux@078088109026.wroclaw.vectranet.pl) |
| 05:02:06 | | Join jschwart [0] (~quassel@2001:985:2c6e:0:b00b:32ff:fe28:5567) |
| 05:02:06 | | Join ats [0] (~ats@cartman.offog.org) |
| 05:02:06 | | Join jackie [0] (~jackie@banana-new.kilobyte22.de) |
| 05:02:06 | | Join leachim6 [0] (~leachim6@user/leachim6) |
| 05:02:06 | | Join Natch [0] (~natch@c-e070e255.014-297-73746f25.bbcust.telenor.se) |
| 05:02:06 | | Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) |
| 05:02:06 | | Join Galois [0] (djao@efnet.math.uwaterloo.ca) |
| 05:02:06 | | Join CasBot1 [0] (~matrixirc@connolly.tech) |
| 05:02:06 | | Join dys [0] (~dys@user/dys) |
| 05:02:06 | | Join __builtin [0] (~quassel@204.48.30.120) |
| 05:02:06 | | Join dbohdan [0] (~dbohdan@user/dbohdan) |
| 05:02:06 | | Join scorche [0] (~scorche@user/scorche) |
| 05:02:06 | | Join ddevault [0] (znc@sourcehut/staff/ddevault) |
| 05:02:06 | | Join gsora_ [0] (~gsora@140.238.174.213) |
| 05:02:06 | | Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g) |
| 05:02:06 | | Join Airwave [0] (~Airwave@ti0006a400-1599.bb.online.no) |
| 05:02:06 | | Join munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 05:02:06 | | Join SammysHP [0] (~SammysHP@faol.sammyshp.de) |
| 05:02:06 | | Join Retr0id [0] (~Retr0id@user/retr0id) |
| 05:02:06 | | Join tchan [0] (~tchan@c-98-206-141-238.hsd1.il.comcast.net) |
| 05:02:06 | | Join wolfshappen [0] (~waff@irc.furworks.de) |
| 05:02:06 | | Join Piece_Maker [0] (~Piece_Mak@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net) |
| 05:02:06 | | Join fmlatghor [0] (~lcoogan@2601:5cd:8100:2890:9220:3aff:fe1a:350d) |
| 05:02:06 | | Join TorC [0] (~Tor@fsf/member/TorC) |
| 05:02:06 | | Join pablocastellanos [0] (~pidgin@user/pablocastellanos) |
| 05:02:06 | | Join gevaerts [0] (~fg@user/gevaerts) |
| 05:02:06 | | Join user890104 [0] (~Venci@quassel.slackwa.re) |
| 05:02:06 | | Join Arsen [0] (~arsen@managarm/dev/Arsen) |
| 05:02:06 | | Join Rondom [0] (~rondom@user/rondom) |
| 05:02:06 | | Join rudi_s [0] (~simon@user/rudi-s/x-7673890) |
| 05:02:06 | | Join aevin [0] (eivindsy@microbel.pvv.ntnu.no) |
| 05:02:06 | | Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) |
| 05:02:06 | | Join tomato [0] (~tomato@user/tomato) |
| 05:02:06 | | Join jbgg_ [0] (~jbgg@95.179.159.229) |
| 05:02:06 | | Join rb-bluebot [0] (~rb-bluebo@55d4247c.access.ecotel.net) |
| 05:02:06 | | Join bluebrother [0] (~dom@55d4247c.access.ecotel.net) |
| 05:02:06 | | Join Romster [0] (~romster@user/romster) |
| 05:02:07 | | Join kirvesAxe [0] (kirvesaxe@user/kirvesaxe) |
| 05:02:07 | | Join ParkerR [0] (ParkerR@znc.withg.org) |
| 05:02:07 | | Join funman [0] (~fun@chui-pas.net) |
| 05:02:08 | | Quit toruvinn (*.net *.split) |
| 05:02:09 | | Quit rb-logbot (*.net *.split) |
| 05:02:09 | | Quit rasher (*.net *.split) |
| 05:02:09 | | Join rasher_ [0] (~rasher@diti.rasher.dk) |
| 05:42:21 | | Nick rasher_ is now known as rasher (~rasher@diti.rasher.dk) |
| 05:42:41 | | Quit rasher (Changing host) |
| 05:42:41 | | Join rasher [0] (~rasher@user/rasher) |
| 06:00 |
| 06:25:43 | rb-bluebot | Build Server message: New build round started. Revision a4ab636423, 297 builds, 8 clients. |
| 06:44:38 | rb-bluebot | Build Server message: Build round completed after 1134 seconds. |
| 06:44:42 | rb-bluebot | Build Server message: Revision a4ab636423 result: All green |
| 07:00 |
| 07:02:00 | *** | Saving seen data "./dancer.seen" |
| 07:19:34 | rb-bluebot | Build Server message: New build round started. Revision 1b81bd8a61, 297 builds, 8 clients. |
| 07:35:55 | rb-bluebot | Build Server message: Build round completed after 981 seconds. |
| 07:35:57 | rb-bluebot | Build Server message: Revision 1b81bd8a61 result: All green |
| 07:42:17 | rb-bluebot | Build Server message: New build round started. Revision 3c7c71030f, 297 builds, 8 clients. |
| 07:42:48 | desowin | I cannot get any more startup glitches now |
| 07:43:42 | braewoods | desowin: try harder! they must still be there! :P |
| 07:45:02 | desowin | well, atleast the ones with >1% probability are not there anymore |
| 07:46:19 | desowin | too bad the OF takes around 5 seconds before exploit kicking in, as it severly slows down on/off tests |
| 07:47:02 | braewoods | gigabeat S is in a similar boat with OF dual boot support |
| 07:47:05 | desowin | USB seems to fail when I pass the device to vmware image when the USB HID is enabled. Disabling USB HID solves the issue. |
| 07:47:32 | desowin | well, workaround the issue, is more appropriate |
| 07:47:35 | braewoods | well passthrough to virtual machines is unlikely to be something actual users will do |
| 07:47:47 | braewoods | i'd be more concerned if it was a problem on real hardware |
| 07:48:22 | desowin | that's reproducible way to get the CPPI handling code going nuts, so I would consider it to be a problem with the driver |
| 07:55:32 | rb-bluebot | Build Server message: Build round completed after 795 seconds. |
| 07:55:34 | rb-bluebot | Build Server message: Revision 3c7c71030f result: All green |
| 09:00 |
| 09:02:02 | *** | No seen item changed, no save performed. |
| 09:33:06 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 09:51:31 | | Join skipwich [0] (~skipwich@user/skipwich) |
| 11:00 |
| 11:02:03 | *** | No seen item changed, no save performed. |
| 11:18:54 | braewoods | g#3510 |
| 11:18:56 | rb-bluebot | Gerrit review #3510 at https://gerrit.rockbox.org/r/c/rockbox/+/3510 : mkzenboot: fix implicit function warning by James Buren |
| 11:18:57 | braewoods | g#3511 |
| 11:18:58 | rb-bluebot | Gerrit review #3511 at https://gerrit.rockbox.org/r/c/rockbox/+/3511 : rbspeex: fix shared linkage on newer Linux distributions by James Buren |
| 11:19:21 | braewoods | whoever feels like reviewing this simple fixes |
| 11:19:59 | braewoods | MarcAndersen: i found the cause of rbspeex failing to build. thanks for the report. |
| 11:43:55 | | Quit akaWolf (Ping timeout: 265 seconds) |
| 11:52:40 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 12:00 |
| 12:04:35 | | Join amachronic [0] (~amachroni@user/amachronic) |
| 12:09:14 | rb-bluebot | Build Server message: New build round started. Revision 9246cbc65e, 297 builds, 8 clients. |
| 12:14:08 | MarcAndersen | braewoods: Thanks for the rbspeex fix |
| 12:22:02 | rb-bluebot | Build Server message: Build round completed after 767 seconds. |
| 12:22:04 | rb-bluebot | Build Server message: Revision 9246cbc65e result: All green |
| 12:24:12 | MarcAndersen | Is there a way to exclude some rock plugins from a build? I have problems with calculator.c in a windows sim, something about a definition of strtod. |
| 12:25:45 | | Join hombrelaser [0] (~sebastian@187-167-217-35.static.axtel.net) |
| 12:26:11 | braewoods | MarcAndersen: do you have the exact log output? |
| 12:26:31 | MarcAndersen | I will pull a fresh git and try again. |
| 12:27:03 | hombrelaser | Hello, I'm planning on installing 128 gb on my ipod 5th gen with an iFlash adapter. Is it necessary for the iPod to have been "restored" by itunes to first use Rockbox or can I install rockbox after installing the iflash adapter? |
| 12:28:47 | braewoods | hombrelaser: i don't know the ipod ports but most targets require an OF reinstall when replacing the storage. it varies heavily though. |
| 12:29:45 | braewoods | there's some where the OF isn't needed; in any case it does need to be formatted in whatever manner the OF expects since rockbox usually piggy backs off of the OF bootloader |
| 12:30:15 | hombrelaser | Oh, so the important part of the OF installation is the bootloader |
| 12:30:46 | braewoods | yes, depends heavily though. on most PP targets the OF doesn't actually have to be present. you can just install the RB bootloader on the disk as is. |
| 12:31:29 | braewoods | i think it's save to assume that it's needed here though. |
| 12:31:33 | hombrelaser | So you recommend me trying rockbox the moment I install the drive or it's better to be safe and install the OF? |
| 12:31:54 | hombrelaser | Oh I see, I'll see what can I do, I don't have access to a w10 pc at the moment |
| 12:31:56 | * | braewoods shrugs. |
| 12:32:01 | braewoods | apple tends to be very weird and specific. |
| 12:32:11 | hombrelaser | Absolutely |
| 12:32:27 | braewoods | most other mp3 players of the same era just expected a simple layout but not ipods last i checked |
| 12:32:56 | braewoods | meaning, single partition formatted with FAT32, type c partition |
| 12:33:50 | braewoods | linux doesn't care about the partition type code but most other proprietary systems do |
| 12:34:07 | braewoods | rockbox doesn't care either |
| 12:48:09 | MarcAndersen | It's building now |
| 12:57:35 | MarcAndersen | Here is a log: https://www.dropbox.com/s/b9xay6lxx24d0mw/error.txt?dl=1 |
| 12:58:10 | braewoods | as i thought. |
| 13:00 |
| 13:02:07 | *** | Saving seen data "./dancer.seen" |
| 13:02:43 | braewoods | MarcAndersen: you can workaround it for now by removing strtod function from the source code |
| 13:03:06 | MarcAndersen | from calculator.c? |
| 13:03:11 | braewoods | yes |
| 13:03:21 | braewoods | it's there because native targets lack strtod |
| 13:04:03 | braewoods | it needs to be conditionally included |
| 13:04:11 | braewoods | but not sure how that should be done |
| 13:04:30 | MarcAndersen | So if I do that I can't build native anymore? Isn't there a way to skip plugins? |
| 13:04:53 | * | braewoods sighs. |
| 13:05:29 | braewoods | you can always restore it via a git reset |
| 13:05:38 | MarcAndersen | The calculator doesn't have speech anyway, but that would infact be a nice thing to have |
| 13:08:27 | desowin | MarcAndersen: actually, the chances are you'll be able to install rockbox on sansa connect without sighted assistance |
| 13:09:10 | desowin | the only potential problem is if you have device with bootlaoder that for some reason is not working with the exploit, then you'd be stuck in recovery mode |
| 13:09:26 | desowin | to get out of recovery mode, OF needs to be loaded if that's the case |
| 13:10:06 | desowin | so if you wish to proceed, then backup any files you have on the device and press and hold power button for 10 seconds |
| 13:11:25 | MarcAndersen | Another error: https://www.dropbox.com/s/90go79o6eixkbar/error2.txt?dl=1 |
| 13:11:49 | desowin | then press and hold the button on the right slightly above the wheel, hold volume up button (upper button on the left) and press power button |
| 13:12:29 | desowin | the volume up and right button have to be held, power needs to be pressed and shortly released |
| 13:12:43 | MarcAndersen | I'm not with the device right now |
| 13:13:50 | desowin | are you building this on windows in mingw? |
| 13:14:08 | MarcAndersen | No, I'm building a simulator |
| 13:14:42 | MarcAndersen | But now I have this mikmod error |
| 13:15:50 | MarcAndersen | I can't use rockboy anyway |
| 13:15:53 | desowin | is this on ubuntu? |
| 13:15:56 | MarcAndersen | Yes |
| 13:17:14 | desowin | but why mingw is being included? Are you targetting windows? |
| 13:17:29 | MarcAndersen | Yes. I'm building a windows simulator |
| 13:35:34 | | Quit amachronic (Ping timeout: 265 seconds) |
| 13:38:09 | MarcAndersen | Can you reproduce it? |
| 13:52:55 | | Quit hombrelaser (Remote host closed the connection) |
| 14:00 |
| 14:04:06 | | Quit dconrad (Remote host closed the connection) |
| 14:07:44 | | Join amachronic [0] (~amachroni@user/amachronic) |
| 14:09:16 | rb-bluebot | Build Server message: New build round started. Revision 9f950d8bbf, 297 builds, 8 clients. |
| 14:22:52 | rb-bluebot | Build Server message: Build round completed after 816 seconds. |
| 14:22:54 | rb-bluebot | Build Server message: Revision 9f950d8bbf result: All green |
| 14:31:05 | desowin | the virtual machine pass through might not be a bug in sansa connect usb driver after all |
| 14:31:29 | desowin | this issue happens only if it is connected via (cheap) usb hub |
| 14:31:53 | desowin | if connected directly, everything works fine |
| 14:32:39 | desowin | when the issue happens, with OpenVizsla I can see that the device really gets everything that was actually sent on the bus |
| 14:34:01 | desowin | there's some IN tokens being sent to non-existent device, and also I can see split starts for other ports |
| 14:34:53 | desowin | I am not sure if the spec even allows to broadcast the split start to all hub downstream ports that have high-speed device connected |
| 14:35:59 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 14:40:49 | | Quit dconrad (Ping timeout: 268 seconds) |
| 14:42:38 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 14:50:36 | desowin | when connected to docking station everything works fine, and so does when connected to decent usb hub |
| 14:51:57 | braewoods | desowin: ryzen host? |
| 14:53:43 | desowin | no, intel i9 |
| 14:54:34 | desowin | but I odubt host has anything to do with it, it just looks like the cheap hub is indeed cheap |
| 15:00 |
| 15:02:08 | *** | Saving seen data "./dancer.seen" |
| 15:04:22 | braewoods | ok, ryzen hosts have a known issue with USB currently |
| 15:13:46 | | Quit advcomp2019_ (Ping timeout: 268 seconds) |
| 16:00 |
| 16:18:17 | amachronic | dconrad: I saw your post, it does look like memory is being mapped wrongly. |
| 16:18:39 | dconrad | great! well, not great, but y'know |
| 16:19:18 | | Quit f1refly (Quit: see ya in hell) |
| 16:19:29 | dconrad | I'm afraid I really don't know what I'm doing with stuff this low-level |
| 16:19:36 | amachronic | those numbers being little endian... it seems there's something happening around 1k in size |
| 16:20:26 | amachronic | hmm lemme check the remappings |
| 16:20:49 | dconrad | that pattern is repeatable too, except it appears that the 00 xx 00 00 values skip, but the xx 00 00 00 and 00 00 xx 00 values don't, if that makes any sense |
| 16:23:01 | amachronic | well, you see the REG_DDRC_REMAP settings in spl-x1000.c? |
| 16:23:20 | dconrad | yeah |
| 16:23:21 | amachronic | I think those control the mapping of physical addresses on the AHB bus to the DRAM |
| 16:23:39 | amachronic | the ones for 32M RAM size might be wrong since I had to pull them out in a odd way |
| 16:23:47 | dconrad | I see |
| 16:23:47 | amachronic | try this |
| 16:23:56 | amachronic | https://pastebin.com/hCDXKM9c |
| 16:24:13 | amachronic | for some reason they encoded the remapping as a loop instead of straight setting of registers. |
| 16:24:23 | amachronic | so I had to decompile the loop and run it to figure out the values |
| 16:25:14 | MarcAndersen | Is there a fix for my previous error with mikmod? |
| 16:25:47 | | Join f1refly [0] (~f1refly@pd954c410.dip0.t-ipconnect.de) |
| 16:26:01 | dconrad | I'll give it a shot! |
| 16:26:23 | dconrad | though I am curious how you get to those values |
| 16:26:35 | amachronic | I'm not sure what to expect, but this is the default mapping which should be 1 to 1 between bus and memory |
| 16:26:37 | dconrad | or, rather what they do |
| 16:27:10 | amachronic | see section 9.2.9 of x1000 manual |
| 16:28:41 | dconrad | It appears to have had no impact? |
| 16:28:49 | dconrad | I'll have to look a little closer |
| 16:29:28 | dconrad | maybe I have the SPL_DDR_MEMORYSIZE somehow defined wrong |
| 16:31:23 | dconrad | yeah somehow that didn't have an effect at all |
| 16:31:42 | amachronic | okaay... I'm not sure what's happening here. |
| 16:31:51 | dconrad | ... I'm going to eliminate the #ifdef stuff just as a sanity check |
| 16:32:06 | amachronic | the remapping passes through the lower 12 bits (= 4k pages) |
| 16:32:22 | amachronic | but you seem to have a "periodic" pattern which is 1k in size? |
| 16:33:08 | dconrad | yeah, here let me upload the .bin |
| 16:33:28 | amachronic | try halving the loop iteration count until the effect goes away |
| 16:35:35 | dconrad | https://dconrad.neocities.org/assorted_files/retry3_mem00.bin |
| 16:35:49 | dconrad | and I'll do that |
| 16:42:37 | amachronic | this one might be faster |
| 16:42:39 | amachronic | https://pastebin.com/W505ZiwU |
| 16:44:03 | dconrad | I'll try it, same expected output? |
| 16:44:29 | amachronic | well, the idea is write two different values 1kb apart and see what comes of it. |
| 16:44:52 | amachronic | this should be unaffected by the remapping bits |
| 16:45:46 | amachronic | what I don't get, in your dump you _should_ see "xx 00 00 00" with xx ranging from 00h to FFh in the first 1kb |
| 16:46:00 | amachronic | but instead you see "xx 01 00 00" |
| 16:46:44 | amachronic | the next 1kb from offset 400h is right but then from 800h it's wrong again |
| 16:47:06 | amachronic | weird |
| 16:48:28 | dconrad | ah, I'll upload the new file, but I get 0xbb in both addr 0 and addr 00000400 |
| 16:48:47 | dconrad | so, it overwrote it in addr 0? |
| 16:49:07 | amachronic | yeah that's what I was afraid of |
| 16:49:09 | dconrad | but no other addresses are written to |
| 16:49:12 | amachronic | try swapping the order of the writes |
| 16:49:36 | amachronic | the results should be the same but with 0xaa in both addrs |
| 16:50:46 | dconrad | you got it, exactly |
| 16:50:54 | amachronic | :/ |
| 16:51:02 | dconrad | how on earth... |
| 16:51:29 | amachronic | I'm looking at REG_DDRC_MMAP |
| 16:51:47 | amachronic | try using the values from the 64M version |
| 16:51:50 | amachronic | keep the rest the same |
| 16:52:53 | amachronic | (this is totally arbitrary −− I am having a hard time understanding the manual to understand why the current value would be wrong) |
| 16:54:28 | dconrad | yeah, looks like it had no effect |
| 16:58:40 | | Join sadjhflj333 [0] (~sadjhflj3@097-088-119-211.res.spectrum.com) |
| 17:00 |
| 17:00:04 | | Quit sadjhflj333 (Client Quit) |
| 17:00:14 | dconrad | in fact, I can use the 64k versions of both MMAP and REMAP registers and I get the exact same results |
| 17:00:39 | amachronic | yeah because they're only dealing with the upper bits of the address |
| 17:02:01 | | Join sadjhflj333 [0] (~sadjhflj3@097-088-119-211.res.spectrum.com) |
| 17:02:11 | *** | Saving seen data "./dancer.seen" |
| 17:02:12 | amachronic | crap, maybe it's because of REG_DDRC_CFG |
| 17:02:41 | amachronic | DDR controller > register definition > DCFG (9.2.2) |
| 17:04:32 | dconrad | CSxEN? |
| 17:04:51 | amachronic | or maybe not... I thought maybe the CS bits were set for two RAM chips but it looks like only one is set |
| 17:05:36 | dconrad | could it be Data width 32-bit vs 16-bit? |
| 17:05:52 | dconrad | no, we're dealing with addressing rather than data, huh |
| 17:06:49 | amachronic | btw there's a datasheet for the DRAM here |
| 17:06:50 | amachronic | https://github.com/YuanhuanLiang/X1000/blob/master/bootloader/x-loader/documents/lpddr/X1000_EMD56164PC%20_45nm_256M_LPDDR_1.8V_rev1.2.pdf |
| 17:07:20 | amachronic | unfortunately I'm not too familiar with any of this either |
| 17:09:15 | dconrad | huh... come to think of it, I don't remember seeing a chip I would identify as RAM? |
| 17:09:54 | amachronic | I assume it's all in the chip package. sometimes the packaging can be melted off and there's a mini-PCB inside |
| 17:10:14 | dconrad | dang, I had no idea |
| 17:10:17 | amachronic | not something I've done myself, but I've seen pictures of it |
| 17:13:55 | | Quit lebellium (Quit: Leaving) |
| 17:14:57 | amachronic | well maybe this is a clue: |
| 17:15:02 | amachronic | "Each 67,108,864 bits bank is organized as 8,192 rows by 512 columns by 16 bits" |
| 17:15:16 | amachronic | and 16 bits * 512 columns = 8192 bits = 1024 bytes |
| 17:15:35 | dconrad | accessing data... in a 2d table? |
| 17:15:57 | dconrad | do we have the wrong row/column values? |
| 17:21:37 | amachronic | AHA! |
| 17:21:43 | dconrad | ?? |
| 17:21:46 | amachronic | it's DCFG.COL0 |
| 17:22:05 | amachronic | col0 = 2 = 10 bit column address |
| 17:22:19 | amachronic | the 32M chip has 9 bit column addresess |
| 17:23:15 | dconrad | what's our label for that, REG_DDRC_CFG? |
| 17:23:20 | amachronic | yeah |
| 17:23:38 | amachronic | (it was pretty silly of me to be renaming registers like this, in retrospect) |
| 17:23:49 | * | amachronic shrugs |
| 17:23:54 | dconrad | ah well |
| 17:24:06 | dconrad | looks like it's set in 3 places for some reason? |
| 17:25:16 | amachronic | well I hope I calculated this right... change 0xa468a6c -> 0xa46896c and 0xa468aec -> 0xa4689ec |
| 17:27:20 | dconrad | ok, I was going to see if I could verify the values but I'll just give it a try |
| 17:27:38 | dconrad | (at work, we tend to use straight binary values, and now I see why...) |
| 17:28:39 | amachronic | well, even better to use human readable names |
| 17:28:57 | dconrad | yeah, but who wants to type all that in? :-P |
| 17:29:24 | amachronic | ... I just didn't bother because I figured, "who's ever going to have to touch this again?" |
| 17:29:28 | dconrad | ok, cross your fingers |
| 17:30:36 | dconrad | ta-daaaa |
| 17:31:01 | dconrad | 0xAA in 0, and 0xBB in 400 |
| 17:31:18 | dconrad | let me try the sequential values test now... |
| 17:31:24 | dconrad | (btw, good job!!!) |
| 17:32:17 | amachronic | alright! seems like you might be getting somewhere |
| 17:32:57 | dconrad | I'm thinking... I might work on making the registers human-readable with defines, I'm good at that kind of systematic stuff |
| 17:33:06 | amachronic | I already have a system for that |
| 17:33:07 | dconrad | well, later |
| 17:33:11 | dconrad | to do that |
| 17:33:21 | amachronic | utils/reggen-ng/x1000.reggen |
| 17:33:26 | dconrad | I see! |
| 17:33:55 | amachronic | The rest of the codebase uses this, that's where all the jz_writef magic comes from. |
| 17:34:11 | | Join advcomp2019 [0] (~advcomp20@user/advcomp2019) |
| 17:35:27 | dconrad | yeah, the sequential stuff looks correct now, let me upload a .bin just for fun |
| 17:36:08 | dconrad | https://dconrad.neocities.org/assorted_files/sequential0.bin |
| 17:37:21 | dconrad | now... I think the next step is just to go ahead and see if I can get das blinken lightsen on the 2nd stage |
| 17:37:46 | dconrad | weird how the 1st stage seemed unaffected by this though |
| 17:38:41 | amachronic | if you update the reggen files, this script may help |
| 17:38:43 | amachronic | https://gist.github.com/amachronic/4aa28e42a244f82f1f9d7a21874fb023 |
| 17:39:35 | dconrad | aha, the bootloader upload now flashes! |
| 17:40:00 | dconrad | ok, sweet! |
| 17:40:41 | amachronic | the 1st stage SPL is not affected, btw, because it doesn't run from DRAM. |
| 17:41:11 | amachronic | it runs from a 16k on-chip SRAM (maybe part of the l2 cache?) |
| 17:42:04 | dconrad | I see, is that kind of the whole reason there's 2 stages anyway? |
| 17:42:19 | amachronic | pretty much. |
| 17:44:16 | amachronic | the question is now, how far does rockbox get? (just for kicks) |
| 17:44:49 | dconrad | hah, well if I add spl_error() to the beginning of system_init(), I get a flashing backlight, but if I remove it, I get nothing |
| 17:45:03 | dconrad | so I'm still hanging somewhere |
| 17:45:08 | dconrad | but, after that point |
| 17:46:59 | amachronic | all you can do is keep bisecting until you locate the problem |
| 17:47:35 | dconrad | well, it's nice to have a systematic way to debug it though for sure |
| 17:48:07 | dconrad | so does that DDR CFG register now need to be set differently for 32 vs 64m targets as well? |
| 17:48:25 | amachronic | yeah |
| 17:48:42 | amachronic | I guess that extra bit is what makes the difference between 32m and 64m |
| 17:49:12 | dconrad | weird that they would actually change the number of addressing bits though |
| 17:49:36 | dconrad | that seems like a fundamental thing |
| 17:51:21 | dconrad | well, we're getting through system_init() ok, so... just gotta keep going |
| 17:52:29 | amachronic | LCD is the most likely flaky part |
| 17:56:23 | dconrad | yup, no surprise there |
| 17:56:32 | dconrad | we can't get through lcd_init(); |
| 17:57:06 | braewoods | _bilgus: think i'm going to redesign my ZIP approach. i realized that i should probably cache the CD table to reduce how much seeking i have to do. otherwise it'll probably kill performance jumping around all over the file. |
| 18:00 |
| 18:00:38 | amachronic | dconrad: try setting LCD_CONTROL pingroup bits 0x1f instead of 0x1a |
| 18:01:28 | amachronic | it's 0x1a on the m3k because those other pins need to be controlled manually as part of the reset sequence |
| 18:02:01 | amachronic | which makes me wonder, is it true that the erosq doesn't need to do a similar thing? |
| 18:02:38 | dconrad | was that in the lcd init functions in the m3k's OF? |
| 18:03:13 | amachronic | yeah it's supposed to be the chip select pin |
| 18:03:43 | dconrad | well, no change using 0x1f unfortunately |
| 18:04:15 | | Quit aquijoule_ (Remote host closed the connection) |
| 18:05:08 | amachronic | odd, it shouldn't hang, even if everything goes horribly wrong. It's only DMAs out of memory so at worst the LCD gets scrambled garbage, but the rest of the system should be ok. |
| 18:06:56 | amachronic | unless the LCD never acks which could very well cause a hang. in which case, it should hang at lcd_tgt_enable() but not before. |
| 18:09:14 | dconrad | hah, you got it |
| 18:09:19 | dconrad | on down the rabbit hole we go |
| 18:12:38 | dconrad | yep, it hangs when calling the lcd_cmd_enable[] commands |
| 18:13:03 | dconrad | ... who'd have seen that coming??? |
| 18:13:34 | amachronic | so it'd appear (1) your LCD module is not init'd or (2) maybe the CS pin level is wrong |
| 18:14:17 | amachronic | PB18 is supposed to be the chip select pin |
| 18:14:30 | dconrad | does the hardware not take care of the chip select automatically? guess not... |
| 18:15:08 | amachronic | it does when you assign it to the GPIOF_DEVICE function but who knows what it actually does? they don't actually document this... |
| 18:15:41 | dconrad | turns out, if you want someone to use your processors, you have to write down how they work, lol |
| 18:16:42 | amachronic | ...and who needs to know how they work when the vendor provides a magic kernel blob? |
| 18:16:47 | amachronic | :P |
| 18:16:58 | dconrad | well, yeah that's it isn't it |
| 18:17:27 | dconrad | so LCD_CE is chip select, right? what's RD? |
| 18:18:11 | amachronic | RD is a read signal, it's not used because the HW has no way to read data from the panel |
| 18:18:18 | dconrad | ok, sweet |
| 18:18:44 | amachronic | so the M3K keeps it high (which is the inactive level) |
| 18:24:50 | dconrad | aha! |
| 18:25:21 | dconrad | ... I just kinda aped the lcd_set_clock() call from the m3k and we got through the lcd_exec_commands() call! |
| 18:26:00 | amachronic | ah, well that was obvious |
| 18:26:09 | dconrad | yeah, in retrospect |
| 18:26:21 | amachronic | I can't believe I missed that. |
| 18:27:07 | dconrad | I guess I was confused and thought it was covered by the EXTC (external clock?) commands in the command set, but that's a completely different thing isn't it |
| 18:27:40 | amachronic | alright, I knew you posted this |
| 18:27:49 | amachronic | your raw "pixclock" is 0xC350 |
| 18:28:07 | amachronic | that's convertible to a clock frequency but you have to chase down the KHZ2PICOS macro and undo it |
| 18:28:42 | amachronic | (at least I think that's what the macro is called.) |
| 18:29:28 | amachronic | which is... 20,000 khz |
| 18:29:53 | dconrad | can I not set it directly with this X1000_CLK_SCLK_A call? |
| 18:30:17 | dconrad | or, 20mhz is the value to put in there |
| 18:30:42 | amachronic | yeah |
| 18:30:48 | dconrad | I see |
| 18:31:19 | amachronic | SCLK_A is the clock source, which is actually just APLL |
| 18:31:45 | amachronic | your other option is MPLL, but right now Rockbox is set up to not use it |
| 18:42:36 | dconrad | looks like now it can't get through show_logo(), which makes sense if the lcd isn't initialized properly |
| 18:42:49 | dconrad | though I'm confused why the backlight isn't at least coming on |
| 18:43:12 | dconrad | ... though maybe I should put this down and go eat some supper |
| 18:43:50 | dconrad | amachronic, thanks a bunch for helping me! |
| 18:44:53 | dconrad | ...oh, the backlight is initialized farther down, that's why |
| 18:51:20 | amachronic | dconrad: no problem. I should probably be going myself though. |
| 18:54:23 | | Quit amachronic (Quit: amachronic) |
| 18:59:34 | | Quit dconrad () |
| 18:59:42 | | Join richbridger [0] (~richbridg@213-225-5-235.nat.highway.a1.net) |
| 19:00 |
| 19:02:12 | *** | Saving seen data "./dancer.seen" |
| 19:18:37 | | Quit richbridger (Remote host closed the connection) |
| 19:23:11 | | Join richbridger [0] (~richbridg@213-225-5-235.nat.highway.a1.net) |
| 19:48:06 | | Join MarcAndersen_ [0] (~Miranda@193.169.154.231) |
| 19:48:17 | | Quit MarcAndersen (Quit: I was using NightOwl 0.2.) |
| 19:53:35 | | Quit MarcAndersen_ (Quit: Miranda NG! Smaller, Faster, Easier. https://miranda-ng.org/) |
| 20:00 |
| 20:14:11 | | Join MarcAndersen [0] (~Miranda@193.169.154.231) |
| 20:56:07 | | Quit MarcAndersen (Quit: Miranda NG! Smaller, Faster, Easier. https://miranda-ng.org/) |
| 20:57:52 | | Join MarcAndersen [0] (~Miranda@193.169.154.231) |
| 21:00 |
| 21:02:16 | *** | Saving seen data "./dancer.seen" |
| 21:22:33 | * | MarcAndersen slaps MarcAndersen around a bit with a large trout |
| 21:26:17 | __builtin | is logf() thread-safe? |
| 21:27:08 | | Join jadzia [0] (~jadzia@d198-53-38-185.abhsia.telus.net) |
| 21:36:02 | __builtin | ... evidently no |
| 22:00 |
| 22:15:33 | __builtin | the rabbit hole of quake really is quite deep |
| 22:16:03 | __builtin | I've been hunting this one heisenbug for days now, and it's looking like it originates within a call to lseek (!?) |
| 22:17:18 | __builtin | well, fseek(), rather |
| 22:38:25 | __builtin | aaand I'll be damned: it was a stack overflow silently thrashing nearby portions of memory |
| 22:38:33 | __builtin | (in a worker thread) |
| 22:39:04 | | Join aquijoule_ [0] (~richbridg@213-225-32-103.nat.highway.a1.net) |
| 22:41:49 | | Quit richbridger (Ping timeout: 268 seconds) |
| 22:51:58 | rb-bluebot | Build Server message: New build round started. Revision d1a92aafff, 297 builds, 8 clients. |
| 22:52:20 | __builtin | ... and there goes my first commit in 6 months :) |
| 23:00 |
| 23:02:17 | *** | Saving seen data "./dancer.seen" |
| 23:04:38 | rb-bluebot | Build Server message: Build round completed after 761 seconds. |
| 23:04:42 | rb-bluebot | Build Server message: Revision d1a92aafff result: All green |
| 23:11:42 | | Quit Piece_Maker (Ping timeout: 265 seconds) |
| 23:19:33 | | Join Piece_Maker [0] (~Piece_Mak@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net) |
| 23:29:18 | | Quit akaWolf (Ping timeout: 268 seconds) |
| 23:29:26 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 23:56:52 | __builtin | do we have an organization set up with libera yet? |
icon identifies that the person is a core developer (has commit access).