| 00:01:21 | | Quit alexweissman (Remote host closed the connection) |
| 00:01:52 | Bilgus | I was under the impression I could force it to the very end of the file or am I mistaken? |
| 00:02:43 | pamaury | yes, if you change all linker files |
| 00:04:16 | Bilgus | ah ok |
| 00:04:37 | pamaury | you need to mark the instanciation of the structure with something like __attribute__((".eof")) [I'm making up a name] and then the linker file of each target need to ensure this section (.eof) is at the very end of the binary |
| 00:04:51 | pamaury | it's not necessarily very complicated to do, just needs to be careful |
| 00:05:44 | | Quit scorche (Disconnected by services) |
| 00:05:48 | | Join scorche` [0] (~scorche@rockbox/administrator/scorche) |
| 00:09:06 | | Quit Senji (Ping timeout: 240 seconds) |
| 00:15:34 | pamaury | Bilgus: maybe sending an email to the mailing list would be a good idea, to gather feedback and maybe ideas |
| 00:15:53 | Bilgus | I just signed up to it today |
| 00:16:15 | Bilgus | Haven't gotten an activated mail as of yet |
| 00:17:16 | | Join shh [0] (~me@145.132.155.235) |
| 00:18:12 | pamaury | Bilgus: if you don't get it soon, send an email to Zagor |
| 00:19:00 | | Join scorche [0] (~scorche@rockbox/administrator/scorche) |
| 00:20:46 | | Quit scorche` (Ping timeout: 240 seconds) |
| 00:21:00 | Bilgus | k |
| 00:21:46 | | Quit shh (Ping timeout: 240 seconds) |
| 00:25:32 | | Quit scorche (Ping timeout: 264 seconds) |
| 00:46:09 | | Quit mutnai (Quit: Page closed) |
| 00:46:47 | | Join chrisjj [0] (5001d87b@gateway/web/freenode/ip.80.1.216.123) |
| 00:46:51 | | Nick zoid is now known as TRUMPbot (~zoid@unaffiliated/taxationistheft) |
| 00:47:15 | | Nick TRUMPbot is now known as zoid (~zoid@unaffiliated/taxationistheft) |
| 00:47:42 | | Nick zoid is now known as EagleBot (~zoid@unaffiliated/taxationistheft) |
| 00:47:52 | | Nick EagleBot is now known as zoid (~zoid@unaffiliated/taxationistheft) |
| 00:49:43 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 51.0.1/20170125094131]) |
| 00:49:57 | | Nick zoid is now known as taxationistheft (~zoid@unaffiliated/taxationistheft) |
| 00:50:17 | | Nick taxationistheft is now known as zoid (~zoid@unaffiliated/taxationistheft) |
| 00:56:26 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:01:34 | | Join scorche [0] (~scorche@rockbox/administrator/scorche) |
| 01:19:20 | | Quit pamaury (Ping timeout: 258 seconds) |
| 01:26:56 | | Quit xorly (Ping timeout: 245 seconds) |
| 01:28:26 | | Join Scyther [0] (~Anna@104.200.153.96) |
| 01:31:21 | | Quit PurlingNayuki (Ping timeout: 252 seconds) |
| 01:34:34 | | Join ffurrywol [0] (~randyg@70-6-147-73.pools.spcsdns.net) |
| 01:36:02 | | Quit furrywolf (Disconnected by services) |
| 01:36:06 | | Nick ffurrywol is now known as furrywolf (~randyg@70-6-147-73.pools.spcsdns.net) |
| 01:45:27 | | Quit amayer (Quit: Leaving) |
| 01:50:46 | | Quit ZincAlloy (Quit: Leaving.) |
| 01:53:51 | | Quit michaelni (Quit: Leaving) |
| 02:00 |
| 02:00:02 | | Join Link8 [0] (~me@86.85.176.166) |
| 02:00:16 | | Quit Link8 (Client Quit) |
| 02:03:08 | | Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) |
| 02:06:09 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
| 02:07:30 | | Quit girafe (Read error: Connection reset by peer) |
| 02:11:59 | | Quit ender` (Quit: Religion is regarded by the common people as true, by the wise as false, and by the rulers as useful. — Seneca) |
| 02:38:35 | | Quit amazoniantoad (Ping timeout: 255 seconds) |
| 02:56:28 | *** | Saving seen data "./dancer.seen" |
| 02:57:22 | | Quit Scyther (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 03:00 |
| 03:06:38 | | Quit saratoga (Quit: Page closed) |
| 03:29:36 | | Join PurlingNayuki [0] (~Thunderbi@113.82.116.170) |
| 03:33:52 | | Quit PurlingNayuki (Ping timeout: 258 seconds) |
| 03:45:23 | | Join Strife1989 [0] (~quassel@adsl-98-80-195-3.mcn.bellsouth.net) |
| 03:47:14 | | Quit Strife89 (Ping timeout: 256 seconds) |
| 04:00 |
| 04:01:14 | | Join hunterleo [0] (0e7ff80d@gateway/web/freenode/ip.14.127.248.13) |
| 04:08:52 | hunterleo | help |
| 04:09:01 | __builtin | hey hunterleo |
| 04:09:13 | __builtin | nice seeing you here :) |
| 04:09:19 | hunterleo | Hi Builtin |
| 04:10:17 | hunterleo | I don't know how to contact pamaury. Can I find he here? |
| 04:10:29 | __builtin | he's not around right now |
| 04:11:01 | __builtin | I assume you're here regarding the ROCKER? |
| 04:12:39 | hunterleo | Yep. Do you know anyone regarding how to get it being ported? |
| 04:13:01 | __builtin | well, pamaury's definitely the porting god around here |
| 04:13:45 | hunterleo | Sure, everyone says so. |
| 04:14:17 | __builtin | was there anything in particular you wanted to ask or say? |
| 04:14:38 | hunterleo | Is there anther way I can find him? |
| 04:15:04 | madk | wiat |
| 04:16:02 | __builtin | hunterleo: he reads the logs for this channel, I think |
| 04:16:30 | __builtin | so you can just say it here if that's okay |
| 04:17:34 | hunterleo | Thank you very much. It's very kind of you! |
| 04:19:41 | Bilgus | do you have a Rocker in your hands? |
| 04:20:12 | __builtin | what software does it currently run, and is there an easy way to execute custom code on it? |
| 04:21:04 | Bilgus | We are very extremely interested :P |
| 04:21:13 | hunterleo | Yes, I have one. |
| 04:22:36 | hunterleo | We hired ths same team which develop OS for FiiO, so the OS works like FiiO X1. |
| 04:24:47 | Bilgus | Do we have specs? |
| 04:25:37 | hunterleo | We couldn't execute custom code before porting it. |
| 04:25:56 | madk | hunterleo: pamaury is working on porting to X1 (maybe not currently) |
| 04:25:57 | hunterleo | http://www.ingenic.com/en/?product/id/9.html check this out |
| 04:27:26 | hunterleo | FiiO X1 uses JZ4775. Rocker uses X1000. |
| 04:27:47 | hunterleo | JZ4775 is going to be discontinued. |
| 04:28:30 | hunterleo | The new models of FiiO also use X1000. |
| 04:50:21 | Bilgus | Vert nice |
| 04:50:27 | Bilgus | Very |
| 04:56:30 | *** | Saving seen data "./dancer.seen" |
| 04:59:53 | hunterleo | Thanks. Bilgus. |
| 05:00 |
| 05:00:26 | Bilgus | Whats the expected price point USD of these? |
| 05:56:48 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
| 05:57:13 | | Quit MrZeus (Ping timeout: 255 seconds) |
| 05:58:07 | | Nick JanC is now known as Guest8949 (~janc@lugwv/member/JanC) |
| 05:58:07 | | Quit Guest8949 (Killed (sinisalo.freenode.net (Nickname regained by services))) |
| 05:58:08 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
| 06:00 |
| 06:07:03 | | Quit smoke_fumus (Read error: Connection reset by peer) |
| 06:08:15 | | Join PurlingNayuki [0] (~Thunderbi@113.82.116.170) |
| 06:09:02 | | Quit TheSeven (Ping timeout: 245 seconds) |
| 06:09:48 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:26:18 | | Quit furrywolf (Ping timeout: 255 seconds) |
| 06:56:31 | *** | Saving seen data "./dancer.seen" |
| 06:56:58 | | Join ungali [0] (ungali@unaffiliated/ungali) |
| 07:00 |
| 07:03:58 | hunterleo | The retail price is 60 USD now. |
| 07:08:06 | | Quit Acou_Bass (Read error: Connection timed out) |
| 07:09:52 | | Join Acou_Bass [0] (~Acou_Bass@host-89-241-250-248.as13285.net) |
| 07:25:49 | | Quit Acou_Bass (Read error: Connection timed out) |
| 07:37:55 | | Quit ungali (Quit: ungali) |
| 07:52:03 | | Quit PurlingNayuki (Quit: PurlingNayuki) |
| 07:54:55 | | Join goom [0] (~goom@cpe-66-25-153-174.satx.res.rr.com) |
| 08:00 |
| 08:03:28 | | Quit hunterleo (Quit: Page closed) |
| 08:04:18 | | Join PurlingNayuki [0] (~Thunderbi@113.82.116.170) |
| 08:52:53 | | Join johnb3 [0] (~johnb2@p57B45CA3.dip0.t-ipconnect.de) |
| 08:56:34 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:08:58 | | Quit jhMikeS (Ping timeout: 252 seconds) |
| 09:09:21 | | Quit johnb3 (Ping timeout: 264 seconds) |
| 09:48:35 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 09:53:35 | | Join johnb3 [0] (~johnb2@p57B45CA3.dip0.t-ipconnect.de) |
| 09:54:24 | | Quit johnb3 (Client Quit) |
| 09:54:50 | | Join johnb2 [0] (~johnb2@p57B45CA3.dip0.t-ipconnect.de) |
| 09:59:09 | | Quit johnb2 (Ping timeout: 240 seconds) |
| 10:00 |
| 10:06:36 | | Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) |
| 10:06:52 | dongs | what's rocker |
| 10:30:21 | | Quit dys (Ping timeout: 255 seconds) |
| 10:39:13 | | Join dys [0] (~dys@ip-109-40-0-171.web.vodafone.de) |
| 10:39:28 | | Join johnb2 [0] (~johnb2@p57B45CA3.dip0.t-ipconnect.de) |
| 10:51:43 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 10:56:38 | *** | Saving seen data "./dancer.seen" |
| 10:58:42 | | Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 10:59:42 | johnb2 | https://www.amazon.com/Bluetooth-Resolution-Lossless-Audiophile-Supports/dp/B01MZ50M0Y/ref=sr_1_1?ie=UTF8&qid=1486202232&sr=8-1&keywords=agptek+rocker |
| 11:00 |
| 11:00:52 | pamaury | ah hunterloo is gone |
| 11:01:58 | pamaury | the player looks cool |
| 11:02:08 | pamaury | if they can give the datasheet for the X1000 I can make the port |
| 11:02:37 | pamaury | I don't think ingenic has released the full programming manual of it |
| 11:04:40 | | Quit goom (Quit: Leaving) |
| 11:21:43 | | Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) |
| 11:27:48 | lebellium | pamaury: on the forum he gave this link http://www.ingenic.com/en/?product/id/9.html and says there is everything we need there but http://www.ingenic.com/ftp://ftp.ingenic.com/SOC/X1000/X1000_DS.pdf gives 404 error... |
| 11:29:53 | lebellium | this works ftp://ftp.ingenic.com/SOC/X1000/X1000_DS.pdf |
| 11:30:02 | lebellium | 46 pages datasheet |
| 11:32:26 | pamaury | 46 pages is not enough, it's incomplete |
| 11:33:40 | lebellium | maybe write it on the forums. I feel he'll be difficult to catch on the IRC due to the time zone |
| 11:39:45 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 11:43:31 | | Quit johnb2 (Ping timeout: 252 seconds) |
| 12:00 |
| 12:29:20 | pamaury | sure |
| 12:41:28 | | Join johnb2 [0] (~johnb2@p57B45CA3.dip0.t-ipconnect.de) |
| 12:47:27 | | Quit StaticAmbience (Ping timeout: 240 seconds) |
| 12:56:42 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 13:04:35 | | Join jb__ [0] (0245a0c8@gateway/web/freenode/ip.2.69.160.200) |
| 13:06:43 | jb__ | pamaury: I'm looking at fuze+ button-driver and gestures. The debug screen detection of "flicks" seems OK to me in comparison to not having gestures at all. |
| 13:08:22 | jb__ | pamaury: seems it would be fairly harmless to map hardware flicks to up/down/left/right buttons? |
| 13:08:47 | | Quit petur (Ping timeout: 240 seconds) |
| 13:09:11 | | Join MrZeus [0] (~MrZeus@2a02:c7f:7008:3400:fd52:2d4e:7071:2f11) |
| 13:13:37 | | Join Malte__ [0] (d9eb20fe@gateway/web/freenode/ip.217.235.32.254) |
| 13:15:47 | Malte__ | Hey guys! I'm currently removing the volume limit of my brother's Sony NW-A30 and it's looking good. But now I'm told to "reset the settings on the device to get the modification applied". What exactly does that mean?. |
| 13:17:23 | | Quit xorly (Ping timeout: 260 seconds) |
| 13:19:05 | pamaury | jb__: it seems to me that the way the hardware detects flicks makes it really unnatural |
| 13:19:36 | | Join gbl08ma [0] (~gbl08ma@ec2-52-23-151-127.compute-1.amazonaws.com) |
| 13:20:14 | pamaury | just detecting flicks is useless unless it's really integrated in the UI. For example what it naturals is if you start scrolling the touchpad and it scrolls the list. It you just flick and it goes up/down one element, that's really useless |
| 13:20:32 | jb__ | pamaury: agreed ... |
| 13:20:32 | pamaury | Malte__: find the factory reset menu entry |
| 13:21:05 | Malte__ | How do I do that? |
| 13:21:10 | jb__ | pamaury: but the work to implement visual feedback like that is more than I could "deal with" |
| 13:21:22 | pamaury | Malte__: look in the menus, nobody has a A30 around so we don't know ;) |
| 13:21:30 | pamaury | Probably in Settings |
| 13:22:01 | jb__ | pamaury: and I keep instinctively flicking the screen touching various buttons. |
| 13:23:12 | jb__ | pamaury: left/right makes sense with the rb ui. left enters a folder/submenu and right returns. |
| 13:23:49 | pamaury | jb__: I think some people had patches to implement a virtual "scroll wheel" on the touchpad, I haven't tried it but a virtual wheel doesn't seem natural to me. I know that the touchpad UI i suboptimal |
| 13:23:59 | | Join StaticAmbience [0] (~Quassel@host217-42-102-36.range217-42.btcentralplus.com) |
| 13:24:00 | Malte__ | Ok: Reset means that I have to reset the device to its factory settings, right? |
| 13:24:35 | jb__ | flicking up/down is also easier than to find the right area on the pad for up/down |
| 13:25:04 | pamaury | Malte__: Sony changes the UI over time but on the E585, That's Settings > Common Settings > Format/restore, something like that |
| 13:26:55 | pamaury | jb__: yes but that means more code, and it's not trivial because it's context dependent |
| 13:27:05 | pamaury | ie scrolling up/down doesn't make sense in all contexts |
| 13:28:04 | Malte__ | Got that. Ok. Now I have to choose between "Reset all setting", "Format System storage", "Rebuild Database", "Restore to factory configuration" |
| 13:28:10 | jb__ | pamaury: why not just map flick up to ~ BUTTON_UP? |
| 13:28:21 | pamaury | jb__: it will do not good |
| 13:28:25 | lebellium | Malte__: reset all settings |
| 13:28:36 | pamaury | because one flick = one up, not useful in a list |
| 13:30:01 | jb__ | pamaury: agreed ... but flick up right now means in order: BUTTON_DOWN, BUTTON_SELECT, BUTTON_UP |
| 13:30:51 | pamaury | yes, but given that we don't control flick detection (it's done by hardware), that would mean waiting to see if hardware see a flick, if not report other buttons |
| 13:31:02 | pamaury | that introduces a unatural delay in the interface |
| 13:31:16 | pamaury | like you press and wait 100ms before the action |
| 13:31:45 | jb__ | pamaury: agreed. but the tap-gesture seems to be 300 ms. is it configurable? |
| 13:31:49 | pamaury | if you want to make it work at least a bit smoothly, you need to detect gesture in software |
| 13:32:00 | pamaury | it's partially configurable |
| 13:32:34 | pamaury | but I still think software is the only way to go |
| 13:32:59 | pamaury | for example maybe the driver can issue repeat events when you smoothly scroll your finger up |
| 13:33:21 | jb__ | ok. the button driver only seems to return button-events |
| 13:33:22 | Bilgus | jb__ I tried gestures and even tried tweaking them what worked best was tweaking sensitivity and dead zone and using it as reqular buttons |
| 13:33:37 | | Quit StaticAmbience (Ping timeout: 276 seconds) |
| 13:34:24 | jb__ | Bilgus: ok. |
| 13:34:32 | Bilgus | Sadly I think what would work better is for the touch pad to select an action and the volume rocker to change it SAD. |
| 13:35:53 | | Join johnb3 [0] (~johnb2@p57B45CA3.dip0.t-ipconnect.de) |
| 13:35:59 | Bilgus | It is rather unfortunate Sansa did that I wonder what kind of BOM savings they had |
| 13:38:43 | jb__ | there is something called kinetic scroll for touchscreens. it seems to read touch-coordinates directly. |
| 13:38:56 | pamaury | yes but touch screen is completely different |
| 13:39:01 | | Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 13:39:09 | pamaury | it assumes a touch... screen ! |
| 13:39:15 | pamaury | coordinates have to map 1 to 1 |
| 13:39:52 | pamaury | for touchpad you want a touchschreen-like mode that have kinetic scrolling but understand that the touchpad coordinate don't map to the screeb |
| 13:39:59 | jb__ | the button driver could scale the pad coordinates. |
| 13:40:16 | pamaury | no that won't work well |
| 13:40:31 | | Quit johnb3 (Ping timeout: 248 seconds) |
| 13:40:54 | pamaury | because touchscreen either work in up/down/left/right emulation, or real touch screen, ie you "click" on button |
| 13:41:09 | pamaury | you can't click on a button you don't see with a touchpad |
| 13:41:20 | jb__ | or the kinetic scroll could use coordinates relative to its source, like: x/MAX_TOUCH_X (?) |
| 13:41:44 | jb__ | pamaury: I get it, but to use kinetic scroll to achieve visual feedback for swiping |
| 13:41:53 | | Quit Malte__ (Quit: Page closed) |
| 13:42:31 | pamaury | yeah but what the point of kinetic scrolling if it ruins everything else ? |
| 13:42:46 | jb__ | pamaury: the button driver only seems to return button events. I don't really understand how software gestures would work. would it simulate a series of button presses? |
| 13:43:36 | jb__ | pamaury: I don't know the code well enough. I thought maybe it could be generalised to touchpads with lists |
| 13:45:15 | pamaury | I have to disappear for 15min, I can explain how it works, you'll understand why none of the existing code/approach can work |
| 13:46:01 | jb__ | thanks! |
| 13:49:43 | | Join paulk-blaze [0] (~paulk@37.164.35.21) |
| 13:58:31 | | Quit paulk-blaze (Remote host closed the connection) |
| 13:58:59 | | Join paulk-blaze [0] (~paulk@37.164.35.21) |
| 14:00 |
| 14:05:18 | | Quit paulk-blaze (Ping timeout: 255 seconds) |
| 14:09:18 | | Join markun [0] (~markun@rockbox/developer/markun) |
| 14:10:08 | pamaury | jb__: the way it works, the button only reports which key(s) are pressed at any given moment. For touchscreen it also reports the (x,y) of the touch if any, the same can be done for touchpad. Anything else is upper layers. Keys repeats for example are not handled in the button driver |
| 14:10:19 | pamaury | thus you cannot simply implement kinetic scrolling in the button driver |
| 14:10:59 | pamaury | the way the touchscreen works is like this: |
| 14:11:53 | pamaury | each screen (list, wps, etc) reports whether or not it can handle touchscreen. If not, a middle layer uses "gird mode" where it split the screen into 9 square buttons and the screen can pretend the device has 9 buttons |
| 14:12:20 | pamaury | if the screen handle touchscreen, it only gets (x,y) of touch and whether or not the user touches the screen, and it has to deal with it |
| 14:13:03 | pamaury | and what it usually does is that it looks for gesture, BUT if the user presses a point and release (ie like a click), it has to do something with it, because it's not a gesture |
| 14:13:18 | pamaury | so it handles like a regular UI, like a mouse click: is a button at (x,y) ? |
| 14:13:31 | pamaury | clearly this doesn't work with a touchpad |
| 14:13:51 | pamaury | if you do a "click" on a touchpad, this is not like a mouse, it's more like a button press |
| 14:14:27 | | Join skapazzo [0] (~skapazzo@151.9.205.1) |
| 14:14:37 | pamaury | furthernore, on a touchscreen, there is something obvious: the touchscreen as the same size as the screen, so the ui can "track" the finger to make the visual feedback consistent with what the user expects |
| 14:15:22 | pamaury | on a touchpad, there is no such relationship, in fact you really DONT want to rescale the coordinate to map the screen, because say you scroll your finger from top to bottom of the touchpad |
| 14:16:12 | pamaury | then you expect the list to go down by the same "distance", so if you screen is 3 times bigger than the touchpad, a full top to bottom slide only move 1/3 of the screen, unless it's a flick and kinetic scrolling kicks in |
| 14:16:39 | pamaury | summary: touchscreen and touchpad share some features, but the way they use them to provide a nice UI are fundamentally different to me |
| 14:17:04 | jb__ | yes I agree. thanks for the explanation |
| 14:17:34 | pamaury | so the proper approach, which is not necessarily complicated, just needs some work, is to do like a touchscreen: |
| 14:18:01 | pamaury | each screen reports whether it can handle touchpad (by default they don't so it's easy), if they do they have to do something about it |
| 14:18:14 | pamaury | and then you can most probably reuse some code from kinetic scrolling for touchpad |
| 14:18:26 | jb__ | a new list implementation for touchpads like for touchscreens? |
| 14:19:15 | pamaury | yeah, they most probably share a lot of elements, but the list needs to know it's a touchpad |
| 14:19:34 | jb__ | how would the list know touchpad coordinates? |
| 14:20:10 | pamaury | the button driver would report them, like for touchscreen |
| 14:23:04 | | Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) |
| 14:23:17 | Bilgus | PAMAURY I've beenn messing around with putting a marker at the end of the FW and I don't think it is going to work AFAICT .codec gets defined .plugin marks the end and then takes up everything after? |
| 14:24:07 | pamaury | Bilgus: you need to get familar with linker script, there is a fundamental difference end of *binary* and end of *memory* |
| 14:25:12 | pamaury | the end of the binary is never at the end of the linker file |
| 14:25:15 | Bilgus | ah so really the binary stops before either of those |
| 14:25:22 | pamaury | yes |
| 14:26:57 | jb__ | pamaury: it looks like coordinates might be put in higher bits by the touchscreen get_button_data(), then action_get_touchscreen_press() extracts them |
| 14:27:24 | pamaury | that's how it works for touchscreen yes, the button data is used to report aux data |
| 14:27:37 | | Nick zoid is now known as ClintonBot (~zoid@unaffiliated/taxationistheft) |
| 14:28:41 | | Nick ClintonBot is now known as zoid (~zoid@unaffiliated/taxationistheft) |
| 14:29:18 | | Join paulk-blaze [0] (~paulk@2001:67c:1810:f055:79f:d5f2:e5f4:4cab) |
| 14:29:24 | pamaury | Bilgus: I can send you an example for the imx233 (like fuze+) |
| 14:30:35 | jb__ | does every touchscreen get_button_data need to be ifdeffed, or does it not lead to chaos? |
| 14:31:18 | pamaury | jb__: I'm pretty sure the entire touchscreen code is ifdefed already |
| 14:32:53 | pamaury | jb__: if you want to work on that, I can send you a POC that create the touchpad mode and shows you where are the gaps to fill |
| 14:34:07 | jb__ | pamaury: fantastic |
| 14:34:58 | jb__ | pamaury: don't plugins use get_button_data(), for example? |
| 14:36:30 | pamaury | I don't remember, the thing is that button data is a generic mecanism to get aux button data but it only makes sense if you know how to interpret it. Thus I expect any use of get_button_data() is ifdef because otherwise it doesn't make sense |
| 14:36:48 | jb__ | got it |
| 14:37:01 | pamaury | I think so far touchscreen is the only user of button data |
| 14:37:33 | | Quit APLU (Ping timeout: 264 seconds) |
| 14:39:27 | jb__ | it seems like more work than I was hoping for, but I'll look at this in my spare time. Touchpads make more sense than touchscreens for tiny devices, where touch areas are small and the fingers cover the screens |
| 14:43:52 | | Quit paulk-blaze (Remote host closed the connection) |
| 14:44:13 | | Join paulk-blaze [0] (~paulk@2001:67c:1810:f055:79f:d5f2:e5f4:4cab) |
| 14:44:42 | pamaury | jb__: to be honest I don't know how much touchscreen and kinetic scrolling are integrated. If they is some clean separation between them, it could be less work than expected |
| 14:46:18 | jb__ | pamaury: ok, so what does the button driver need to do? |
| 14:47:42 | jb__ | pamaury: there needs to be some detection as to what are taps, long presses, swipes ... smartphones wait until the finger is lefted to send a "click" |
| 14:47:50 | pamaury | what I will do in the POC I'll send you (maybe tomorrow) is to make the button driver do like touchscreen: it calls a library function that depending on touchpad mode either reports position or button. The difference with touchscreen is that the touchpad probably needs to give the callback the location of button "on the touchpad" |
| 14:48:23 | pamaury | then in the list gui code, introduce a touchpad mode that only looks at position and decide what is gesture and what is not |
| 14:48:58 | pamaury | I expect the gesture code can be reused, after all it's the same thing on touchscreen and touchpad, but what you make of it is different |
| 14:49:25 | | Quit gbl08ma (Remote host closed the connection) |
| 14:49:37 | | Join APLU [0] (~mulx@eva.aplu.fr) |
| 14:53:34 | | Join Senji [0] (~Senji@85.187.103.250) |
| 14:55:52 | Bilgus | pamaury sure that would be helpful might explain why I init and can't find it in the binary |
| 14:56:30 | pamaury | Bilgus: give me 5 min, I'll send you an example |
| 14:56:43 | Bilgus | take your time thanks |
| 14:56:45 | *** | Saving seen data "./dancer.seen" |
| 15:00 |
| 15:00:27 | pamaury | Bilgus: actually now that I am thinking about it, it may no be that easy for a non-obvious reason: many targets organize their binary like this: |
| 15:00:27 | pamaury | |code|data|code that goes to iram|data that goes to iram| |
| 15:00:27 | pamaury | but when loaded to memory and initialise, it actually looks like: |
| 15:00:27 | DBUG | Enqueued KICK pamaury |
| 15:00:27 | pamaury | |code|data|bss| |
| 15:00:27 | pamaury | so the end of binary is overwritten in RAM. |
| 15:00:29 | pamaury | The proper approach would be to store the header somewhere in the binary, but put the OFFSET to it at the end of the binary |
| 15:00:47 | pamaury | that's what I will do in the example I'll send you |
| 15:02:10 | Bilgus | awesome thats probably it since I can place it higher and find it but each time I go further than data it disappears |
| 15:04:41 | | Join smoke_fumus [0] (~smoke_fum@dynamic-vpdn-93-125-62-122.telecom.by) |
| 15:11:06 | | Join furrywolf [0] (~randyg@72-57-27-185.pools.spcsdns.net) |
| 15:15:26 | jb__ | what are the hopes of achieving left/right screen transitions, like on smartphones or ipod nano? |
| 15:15:45 | furrywolf | none, hopefully. |
| 15:16:00 | jb__ | there is need to render the next framebuffer just as the swipe is detected |
| 15:16:18 | jb__ | furry: =) |
| 15:18:12 | Bilgus | I doubt this would be much liked in the actual UI but maybe in a theme? |
| 15:18:25 | pamaury | jb__: transition, 0% if you want the left and right screen to smoothly transition. If you just think of "I swipe, it changes screen", that probably doable |
| 15:22:08 | | Join MrZeus1 [0] (~MrZeus@2a02:c7f:7008:3400:b0e7:24b8:50fe:7a94) |
| 15:22:32 | jb__ | ok |
| 15:23:45 | | Quit MrZeus (Ping timeout: 255 seconds) |
| 15:27:12 | pamaury | Bilgus: g#1551 |
| 15:27:14 | fs-bluebot | Gerrit review #1551 at http://gerrit.rockbox.org/r/1551 : Implement magic section. by Amaury Pouly |
| 15:28:13 | pamaury | it's implement for imx233 with a small example |
| 15:29:43 | Bilgus | awesome you make it look freaking easy |
| 15:30:34 | | Quit paulk-blaze (Remote host closed the connection) |
| 15:30:52 | | Join paulk-blaze [0] (~paulk@2001:67c:1810:f055:79f:d5f2:e5f4:4cab) |
| 15:31:02 | pamaury | Bilgus: the trick is that each linker script is a bit different and needs to be modified carefully |
| 15:32:51 | Bilgus | yeah I see where they have different sections ahead/behind |
| 15:34:50 | pamaury | basically it should be last section that is not a NOLOAD section |
| 15:34:54 | pamaury | that's a good rule of dumb |
| 15:37:27 | | Quit paulk-blaze (Ping timeout: 240 seconds) |
| 15:45:51 | Bilgus | now since this has a pointer to the offset without need to search it doesn't need to be a string anymore correct I could now make it a long with a few bytes in it for verification correct? |
| 15:46:25 | Bilgus | the actual data not the rbmagic0 |
| 15:48:21 | pamaury | Bilgus: yes, I still suggest you start the data in the magic section with a small (4-byte) magic value just in case |
| 15:48:32 | pamaury | (cause any failure would basically overwrte code, which is BAD) |
| 15:49:37 | pamaury | another approach to this problem would be to modify crt0.S and make the bootloader pass a pointer to some aux data |
| 15:49:51 | pamaury | I think this would be cleaner |
| 15:50:05 | pamaury | I'll put another patch on gerrit to compare both approaches |
| 15:55:18 | | Quit jb__ (Ping timeout: 260 seconds) |
| 15:59:06 | Bilgus | :\ you have other stuff to work on ill start investigating that haha I forgot this is all BE |
| 16:00 |
| 16:17:30 | | Quit zoid (Quit: www.taxationistheft.com) |
| 16:18:22 | | Join zoid [0] (~zoid@159.203.108.115) |
| 16:19:40 | | Quit zoid (Changing host) |
| 16:19:40 | | Join zoid [0] (~zoid@unaffiliated/taxationistheft) |
| 16:28:19 | pamaury | Bilgus: there yet an approach |
| 16:28:34 | pamaury | since on virtually all targets, the code in crt0.S is at the very beginning of RAM |
| 16:28:56 | pamaury | one could say that the boot data must within (say) the first 1024 bytes of the binary |
| 16:29:01 | pamaury | and simply put it in crt0.S |
| 16:29:11 | pamaury | thus the search for it is always quick and it's easy to implement |
| 16:29:37 | pamaury | *yet another |
| 16:30:51 | Bilgus | so keep the header intact and tag the data with magic but search for it |
| 16:31:14 | pamaury | yes, but you only look for it at the very beginning of the binary |
| 16:31:26 | pamaury | and it's up to the target crt0 code to figure out how to implement that |
| 16:32:58 | pamaury | it makes a lot of sense because basically it means "look for special header in the 1024 after entry point of binary" |
| 16:33:36 | Bilgus | now how would I read the data though or would I just write the data I want init directly to the crt and let it init the var? |
| 16:34:12 | pamaury | let me send you an example |
| 16:35:35 | fs-bluebot | Build Server message: New build round started. Revision 96a7603, 255 builds, 17 clients. |
| 16:35:38 | Bilgus | no thats 'P amaury please show me how this works' |
| 16:36:51 | pamaury | one thing that is good about this approach is that you need to change all crt0.S BUT there are less than one per target |
| 16:37:18 | pamaury | also it's essentially target agnostic because all assemblers support the same directives |
| 16:41:36 | pamaury | Bilgus: are you familiar with gnu assembler ? |
| 16:44:09 | Bilgus | I programmed TI calcs in it in HS and did some on a Heathkit HERO in HS so familiar with assembler yes fluent no |
| 16:45:30 | fs-bluebot | Build Server message: Build round completed after 596 seconds. |
| 16:45:31 | fs-bluebot | Build Server message: Revision 96a7603 result: All green |
| 16:47:28 | pamaury | I suggest you read ftp://ftp.gnu.org/old-gnu/Manuals/gas/html_chapter/as_7.html#SEC98 and http://www.cse.unsw.edu.au/~cs3221/labs/assembler-intro.pdf to understand the code I will post |
| 16:47:46 | Bilgus | k |
| 16:56:49 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:01:43 | pamaury | Bilgus: g#1552 |
| 17:01:44 | fs-bluebot | Gerrit review #1552 at http://gerrit.rockbox.org/r/1552 : Add boot data support to rockbox. by Amaury Pouly |
| 17:02:24 | lebellium | pamaury: you'll get probably a sample from the AGPtek rep but it's also available on Amazon.fr - €50 https://www.amazon.fr/Bluetooth-Lecteur-Musical-ROCKER-Memoire/dp/B01NBRJBOH/ |
| 17:02:28 | lebellium | I guess I'l buy it :D |
| 17:05:27 | pamaury | lebellium: we'll see, I answered on the forum. The player looks cool, I'll buy it if he doesn't send me a sample ;) |
| 17:06:05 | pamaury | Bilgus: I included a small debug meny entry to view the data, just as a proof of concept |
| 17:06:52 | pamaury | hopefully the code is self-expanatory: we declare the C structure as extern and we implement it in the crt0.S |
| 17:06:57 | Bilgus | Nice I just pulled it that looks a lot cleaner already |
| 17:06:59 | pamaury | to share code, I implement use a assembler macro |
| 17:07:22 | pamaury | which should in theory work on all assemblers on all targets, so it's only a matter of adding "put_boot_data_here" in al crt0.s |
| 17:07:38 | pamaury | possibly one could #ifdef all of that behind HAVE_BOOT_DATA |
| 17:07:52 | pamaury | you need to choose a particular crc algorithm |
| 17:08:03 | pamaury | and then have the bootloader fill the structure of course |
| 17:12:32 | Bilgus | I'll try this out and come back once I understand it better |
| 17:16:39 | fs-bluebot | Build Server message: New build round started. Revision 501e8a7, 255 builds, 17 clients. |
| 17:24:45 | fs-bluebot | Build Server message: Build round completed after 486 seconds. |
| 17:24:46 | fs-bluebot | Build Server message: Revision 501e8a7 result: All green |
| 17:24:47 | fs-bluebot | Build Server message: New build round started. Revision 1245c5f, 255 builds, 16 clients. |
| 17:40:17 | fs-bluebot | Build Server message: Build round completed after 931 seconds. |
| 17:40:18 | fs-bluebot | Build Server message: Revision 1245c5f result: All green |
| 17:40:19 | fs-bluebot | Build Server message: New build round started. Revision d787191, 255 builds, 16 clients. |
| 17:48:36 | fs-bluebot | Build Server message: Build round completed after 499 seconds. |
| 17:48:37 | fs-bluebot | Build Server message: Revision d787191 result: All green |
| 18:00 |
| 18:03:42 | | Join johnb2 [0] (~johnb2@p57B45CA3.dip0.t-ipconnect.de) |
| 18:05:48 | johnb2 | Mihail: On the read-only internal memory, do you think there is a chance to remove the partition? Would the bootloader from early last year try to load RB from the SD card? |
| 18:07:26 | | Quit PurlingNayuki (Remote host closed the connection) |
| 18:08:54 | | Join PurlingNayuki [0] (~Thunderbi@113.82.116.170) |
| 18:22:27 | | Quit johnb2 (Ping timeout: 258 seconds) |
| 18:26:43 | | Join edhelas [0] (~edhelas@145.133.43.230) |
| 18:31:03 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 18:31:03 | * | __builtin would love to help with a Rocker port... but I'm not sure if I'm qualified enough :/ |
| 18:31:13 | __builtin | dang it, verbs |
| 18:32:59 | pamaury | __builtin: I'll do the port, assuming they can provide at the datasheet for the soc |
| 18:33:07 | pamaury | s/datasheet/programming manual |
| 18:33:58 | lebellium | They necessarily have it or could they do their home firmware without? |
| 18:34:48 | pamaury | lebellium: I guess they could have done it without, if for example they bought the SDK from ingenic or hire ingenic to do the base port and they just did the cutomization |
| 18:35:05 | pamaury | ingenic released some source for the X1000 but to be honest, code is a super annoying source of documentation |
| 18:35:55 | lebellium | He said they hired the FiiO team but I don't know if it was only for the customization |
| 18:36:17 | pamaury | yeah that needs to be clarified |
| 18:38:02 | pamaury | I need to search in ingenic FTP |
| 18:38:03 | | Join ulmutul [0] (~chatzilla@dslb-188-102-002-126.188.102.pools.vodafone-ip.de) |
| 18:38:10 | pamaury | they release a lot of doc but never advertise it |
| 18:39:45 | * | pamaury thinks he found it |
| 18:39:54 | pamaury | http://198.13.102.98/bj/ingenic_support/X1000_X1000E_X1500/02_HW/01_Phoenix/Phoenix_V2.0/03Datasheet/X1000_PM_20150918.pdf |
| 18:42:07 | lebellium | nice! |
| 18:42:54 | lebellium | by the way, it looks like the AGPTek Rocker is only a rebranded Benjie T6 http://www.benjie-tx.com/MP3HiFiPlayer/224.html |
| 18:42:57 | __builtin | it even tells you how to boot from USB :) |
| 18:43:20 | pamaury | apparently they didn't change the usb boot mode, that's cool |
| 18:43:39 | lebellium | I'm confused now about what AGPtek really did |
| 18:43:55 | lebellium | Did the take the existing hardware and just customized their own firmware? |
| 18:44:01 | lebellium | they* |
| 18:45:13 | ulmutul | jb__, pamaury: seems like someone may be interrested in g#1199 :) |
| 18:45:15 | fs-bluebot | Gerrit review #1199 at http://gerrit.rockbox.org/r/1199 : POC Fuze+ Scrollstrip support by Sebastian Leonhardt |
| 18:45:25 | pamaury | ulmutul: I know but I don't like the approach |
| 18:45:59 | ulmutul | Why not? |
| 18:46:24 | pamaury | a scrollstrip on a touchpad doesn't feel very natural to me |
| 18:46:47 | pamaury | also the way it is implemented is strange |
| 18:46:55 | pamaury | it doesn't reuse any of the scrollwheel code afaict |
| 18:47:19 | pamaury | I wouldn't be against a knob to select between button/scrollwheel/kinetic touchpad |
| 18:47:36 | pamaury | but the scrollwheel should at least be implemented with the usual scrollwheel framework |
| 18:49:29 | ulmutul | Hm, I don't know if the wheel framework would work for it. The wheel code for example don't support button actions afaict. |
| 18:50:05 | ulmutul | The whole thing is more or less the atempt to write a scrollstrip framework (for strip targets mainly) |
| 18:50:50 | pamaury | ah sorry, I thought that was the scrollwheel patch ;) |
| 18:50:58 | pamaury | ok but then my reproch is the same |
| 18:51:03 | pamaury | this is way too low level |
| 18:51:24 | | Join maffe [0] (~Miranda@p3EE3A0F9.dip0.t-ipconnect.de) |
| 18:51:39 | | Nick maffe is now known as bufgix (~Miranda@p3EE3A0F9.dip0.t-ipconnect.de) |
| 18:51:44 | pamaury | the proper approach, I believe, is to do like touchscheen: it has to be handle at the UI level so you can properly implement things like kinetic scrolling |
| 18:52:22 | pamaury | this what I'm working on right now, at least a POC |
| 18:56:50 | *** | Saving seen data "./dancer.seen" |
| 18:57:39 | ulmutul | I postet at the forums some time again: http://forums.rockbox.org/index.php/topic,51426.0.html |
| 18:57:40 | ulmutul | Whoever want's to test the touch can download a compiled built. I'm still waiting for feedback about the best way to handle long button presses ;) |
| 18:59:15 | * | ulmutul will look how it's done for touchscreens. |
| 19:00 |
| 19:01:04 | ulmutul | pamaury: have you tested it yet? |
| 19:01:16 | pamaury | no |
| 19:02:20 | pamaury | but in the worst case, it is possible to have a setting between various modes, like touchscreen |
| 19:10:43 | | Quit markun (Quit: leaving) |
| 19:11:06 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 19:15:41 | pamaury | but I'll try the patch |
| 19:16:15 | lebellium | I feel quite fooled actually. I thought they selected some proper hardware for Rockbox and designed the player around it. But they only choose which existing device to rebrand... |
| 19:16:40 | pamaury | yeah sounds weird |
| 19:28:31 | lebellium | I'll see if I cancel my order to get the original device cheaper when it getsreleased on some Chinese webshop like aliexpress |
| 19:28:36 | Bilgus | pamaury i'm sorry to bother you again I'm trying to make the fuze+ imx boot loader and I keep having problems making the mkimxboot |
| 19:29:04 | pamaury | Bilgus: you'll have to be more precise ;) |
| 19:30:27 | pamaury | Bilgus: most probably you are missing some libs ? |
| 19:30:31 | Bilgus | sbtools and undefined reference to `vtable for CryptoPP::HashTransformation |
| 19:31:02 | Bilgus | ubuntu@ubuntu-VirtualBox:~$ whereis libcryptopp.a |
| 19:31:02 | Bilgus | libcryptopp: /usr/lib/libcryptopp.so /usr/lib/libcryptopp.a |
| 19:31:02 | Bilgus | ubuntu@ubuntu-VirtualBox:~$ whereis crypto.cpp |
| 19:31:02 | DBUG | Enqueued KICK Bilgus |
| 19:31:02 | Bilgus | crypto: /usr/src/linux-headers-3.2.0-113/crypto /usr/src/linux-headers-3.2.0-113-generic/crypto /usr/share/man/man3/crypto.3ssl.gz |
| 19:31:02 | Bilgus | ubuntu@ubuntu-VirtualBox:~$ |
| 19:31:39 | pamaury | smells like a linker order problem with old gcc, wait a minute |
| 19:32:55 | pamaury | Bilgus: in rbutil/mkimxboot/Makefile, try to replace |
| 19:32:55 | pamaury | LDFLAGS += -lcrypto++ |
| 19:32:55 | pamaury | by |
| 19:32:55 | pamaury | LDOPTS += -lcrypto++ |
| 19:34:06 | Bilgus | LOL |
| 19:34:44 | Bilgus | that was it like 2 seconds |
| 19:36:44 | Bilgus | thanks I think i would have never figured that out |
| 19:45:35 | pamaury | Bilgus: if you want to speed up dev, you can use mkimxboot to create a singleboot image, and then upload in a recovery mode using sbloader |
| 19:45:58 | pamaury | it avoids the flashing stage (but of course needs to be done on each boot) |
| 19:46:51 | Bilgus | hmm then I assume if it crashes I'm able to revert on next reboot? |
| 19:47:55 | pamaury | you can always use the OF to reflash (as long as you flash dualboot image) |
| 19:48:08 | pamaury | the advantage of using recovery mode that it avoid flashing, thus is much faster |
| 19:51:11 | Bilgus | sounds nice, i'll try that |
| 19:51:34 | pamaury | just make sure you don't flash the singleboot image, that would be longer to recover |
| 19:55:48 | Bilgus | ok so make a single boot image to use sbloader just besure not to actually flash it to the device then? |
| 19:56:31 | pamaury | yes |
| 19:56:48 | pamaury | to make singleboot image, do mkimxboot -i ... -b ... -o ... -t singleboot |
| 20:00 |
| 20:07:00 | | Quit PurlingNayuki (Quit: PurlingNayuki) |
| 20:07:15 | | Join PurlingNayuki [0] (~Thunderbi@113.82.116.170) |
| 20:36:14 | | Quit igitoor_ (Ping timeout: 258 seconds) |
| 20:38:59 | | Join igitoor [0] (igitur@2a00:d880:3:1::c1ca:a648) |
| 20:39:58 | Bilgus | pamaury BOOT_DATA_SEARCH_SIZE how is that guaranteed to be the case just a general assumption based on the size of our firmware? |
| 20:44:22 | Bilgus | nm I just realized its the placement within the crt file |
| 20:45:37 | | Quit igitoor (Changing host) |
| 20:45:37 | | Join igitoor [0] (igitur@unaffiliated/contempt) |
| 20:48:38 | pamaury | Bilgus: yeah placement in the file |
| 20:49:26 | pamaury | 1024 gives you about 256 instructions, I doubt any crt file uses more than, so if you just put it after the last instruction in crt0 it should be within the window |
| 20:50:01 | lebellium | pamaury: Benjie T6 marketed but looks like it's called K1 internally, what a mess... https://f.lnwfile.com/_/f/_raw/n0/x8/s7.jpg |
| 20:52:26 | pamaury | lebellium: lol indeed |
| 20:53:14 | pamaury | lebellium: isn't the agptek supposed to come with a touchpad/touchwheel ? |
| 20:54:07 | pamaury | ah apparently not |
| 20:54:44 | pamaury | I am kind of confused about how the chinese market works anyway, they seem to have clones of clones of clones |
| 20:56:54 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:06:00 | lebellium | I hope the AGPTek rep will explain a bit about their business |
| 21:06:20 | lebellium | but that will probably be confusing as all his earlier posts |
| 21:25:46 | | Join Strife89 [0] (~quassel@adsl-98-80-194-33.mcn.bellsouth.net) |
| 21:28:06 | | Quit Strife1989 (Ping timeout: 255 seconds) |
| 21:30:10 | dongs | lol clone of clones |
| 21:30:18 | dongs | youre not wrong there |
| 21:53:51 | | Quit bufgix (Quit: IRC ist obsolet!) |
| 22:00 |
| 22:01:24 | | Quit edhelas (Ping timeout: 255 seconds) |
| 22:05:47 | | Quit michaelni (Ping timeout: 240 seconds) |
| 22:11:00 | | Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl) |
| 22:11:59 | | Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) |
| 22:13:44 | wodz | pamaury: Did looled at x1000 pm to see how much of the blocks from earlier families are reused? |
| 22:14:20 | pamaury | wodz: not yet |
| 22:15:29 | wodz | pamaury: It has 2nd level cache which afaik was missing in earlier families |
| 22:16:26 | pamaury | wodz: a quick look suggest some blocks are similar but overall there might be many differences |
| 22:18:28 | pamaury | yeah the L2 cache is new |
| 22:18:33 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
| 22:19:04 | pamaury | that will need special care potentially, the manual says "Programmer transparent, that is, those CACHE instructions |
| 22:19:04 | pamaury | managing L1 cache can manipulate L2 cache automatically" |
| 22:19:08 | pamaury | don't know what it means |
| 22:19:22 | wodz | ugh |
| 22:20:15 | wodz | pamaury: It says it is mips32r2 compatible core :) |
| 22:20:20 | | Join Strife1989 [0] (~quassel@adsl-98-67-60-3.mcn.bellsouth.net) |
| 22:21:05 | pamaury | wodz: non full pipelined implementation for most of MIP32 integer instruction release II |
| 22:21:18 | pamaury | I say, wait until I test |
| 22:21:28 | wodz | pamaury: yeah |
| 22:21:33 | pamaury | because jz4760b claims to be mips32r2 and doesn't implement some stuff |
| 22:24:20 | | Quit Strife89 (Ping timeout: 264 seconds) |
| 22:24:23 | pamaury | what would be helpful is if they can send me sample player and one with debug stuff wired |
| 22:24:40 | pamaury | assuming they even have it |
| 22:28:05 | wodz | pamaury: That depends how they approached firmware port. If it was only customization they might not have it |
| 22:34:05 | Bilgus | pamaury how robust do you think my checksum needs to be can do a simple xor of magic0,1 length and payload or should I be looking for something better? |
| 22:41:14 | pamaury | Bilgus: I think the checksum should only consider the payload, and I don't think it needs to be super robust, but just make sure that the initial configuration (ie what put_oot_data_here) is invalid, so the code can detect that the bootloader didn't touch the boot data |
| 22:42:36 | pamaury | a sum sounds better that a xor in this case I think |
| 22:42:43 | Bilgus | ohh I wa planning on using that to verify we had the right information before writing with the boot loader |
| 22:42:45 | pamaury | wodz: any suggestion on that ? |
| 22:43:27 | wodz | pamaury: could you give a bit of context? |
| 22:45:26 | pamaury | Bilgus is implementing a mecanism by why the bootloader can pass some data to the firmware. The goal is for the bootloader to tell rockbox what the volume to mount as /, and so to be able to boot from SD. |
| 22:45:50 | pamaury | The implementation I suggested is g#1551 |
| 22:45:52 | fs-bluebot | Gerrit review #1551 at http://gerrit.rockbox.org/r/1551 : Implement magic section. by Amaury Pouly |
| 22:46:15 | pamaury | err, g#1552 |
| 22:46:17 | fs-bluebot | Gerrit review #1552 at http://gerrit.rockbox.org/r/1552 : Add boot data support to rockbox. by Amaury Pouly |
| 22:46:51 | pamaury | rockbox embeds a structure with a magic value, then a length, crc and payload, and the bootloader fills this payload before jumping to the firmware |
| 22:48:23 | wodz | that sounds sane so far |
| 22:48:38 | pamaury | and the question is: what kind of crc to use |
| 22:49:56 | wodz | that depends how much space in bootloader can we afford. crc32 is not usually big and is already present in main binary |
| 22:51:09 | pamaury | I don't know if crc32 is already compiled in the bootloader or not |
| 22:51:12 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 22:51:12 | * | pamaury checks |
| 22:51:16 | Bilgus | here is what I have so far http://pastebin.com/tFRk77qv |
| 22:52:22 | pamaury | Bilgus: I think crc32 is already compiled in anyway, so it's a good choice indeed |
| 22:53:41 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:e818:b30d:c507:6059) |
| 22:53:48 | pamaury | Bilgus: I have many comments ;) |
| 22:54:15 | Bilgus | do tell.. |
| 22:56:54 | pamaury | I suggest you push to gerrit but basically: |
| 22:56:54 | pamaury | - crc should apply to all payload: bootdata->crc = crc32(crc->payload, crc->length); // not sure about crc_32 prototype |
| 22:56:54 | pamaury | - why 0x52622300 | boot_volume and not just boot_volume ? |
| 22:56:54 | pamaury | - regarding boot_volume, I'm not 100% sure how you plan to implement the "mount Nth volume as /" part, but we'll see |
| 22:56:54 | pamaury | - for(i = 0;i <= (BOOT_DATA_SEARCH_SIZE - sizeof(struct boot_data_t));i++) -> why BOOT_DATA_SEARCH_SIZE - sizeof(struct boot_data_t) ? |
| 22:56:56 | pamaury | - if (len < BOOT_DATA_SEARCH_SIZE) -> why |
| 22:56:57 | *** | Saving seen data "./dancer.seen" |
| 22:56:58 | pamaury | for the last two things, I would rewrite the loop as: |
| 22:57:00 | pamaury | int search_len = MIN(len, BOOT_DATA_SEARCH_SIZE); |
| 22:57:02 | pamaury | for(i = 0;i <= (search_len - sizeof(struct boot_data_t));i++) |
| 22:57:52 | pamaury | also don't forget to memset(payload, 0, len) |
| 22:59:27 | Bilgus | | with the boot_volume is just to allow there to be something in there to check against since its at most a single byte |
| 22:59:58 | Bilgus | figure it typically will be 0 or 1 maybe 2 |
| 23:00 |
| 23:01:03 | pamaury | Bilgus: with the crc check that's kind of useless no ? |
| 23:01:10 | pamaury | or just make boot volume a uint8_t |
| 23:01:38 | Bilgus | ill return the actual volume name with get_volume_name(x, buf); once in the firmware |
| 23:01:45 | pamaury | regarding boot volume, depending on the implementation, I am not sure it should be the boot volume actually |
| 23:02:16 | pamaury | but that depends on how it's implemented |
| 23:03:44 | Bilgus | if I'm only going to use uint_8 the payload gets way smaller still is there anything else you think I should be passing? |
| 23:04:40 | Bilgus | what do you mean the boot volume actually? you think instead we should be passing back the string <MICROSD0>/.rockbox or something? |
| 23:06:26 | pamaury | Bilgus: not it's doesn't make sense to give the string. What I'm saying is that multidrive => multivolume, so in theory there can even be multiple volume on each drive. So the only way you can find the "Nth volume" is to try to mount all partition in the usual order, but then volume 0 will be / and you wanted volume N so you'll have to "exchange" them, if that makes sense |
| 23:06:33 | pamaury | just look at disk.c |
| 23:06:55 | * | pamaury looks to be sure |
| 23:08:03 | pamaury | yeah in disk_mount |
| 23:08:15 | pamaury | there isn't a one to one relationship between drive and volume |
| 23:08:56 | Bilgus | no in multi volume its drives * num of volumes |
| 23:10:16 | pamaury | so what I'm saying is that if I give you a volume number |
| 23:10:27 | pamaury | there is no easy way to find even on which drive it is |
| 23:10:57 | Bilgus | Ah short of looking at all the drives? I'm not sure how else to derive the booted volume |
| 23:11:25 | | Quit wodz (Quit: Leaving) |
| 23:11:46 | pamaury | Bilgus: I don't know enough about how volume integrate with the file system to be honest |
| 23:11:47 | Bilgus | figure In that other commit I have up on gerrit it just tries MAx_drives to 0 till it finds the one that sticks |
| 23:12:00 | Bilgus | Max_volumes* |
| 23:13:52 | Bilgus | probably be a good idea to talk to Michael I forget what his IRC handle is he says I had a thing started in the filesystem code that would allow any one volume to be mounted as the root directory (obviously only one because names could conflict if more are allowed). Would that help here? |
| 23:15:08 | pamaury | yes jhMikeS probably knows how to do that |
| 23:16:12 | Bilgus | I suppose another idea is to pass back out a lookup array that will map element 0 to this boot drive 1 to the internal etc |
| 23:20:16 | pamaury | that's too complicated |
| 23:21:14 | pamaury | let's wait and see what jhMikeS says |
| 23:21:45 | Bilgus | Ill ask jhMikeS what he needs to remap |
| 23:35:27 | Bilgus | thanks for the guidance pamaury I'd still be stuck fiddling around with the linker |
| 23:48:22 | jhMikeS | aye, you actually got me interested in completing it :) |
| 23:48:53 | Bilgus | what do i need to send to your function from the bootloader? |
| 23:49:13 | jhMikeS | can you explain? |
| 23:49:51 | Bilgus | give me a few i'm heading out i'll get on my phone |
| 23:49:59 | jhMikeS | okay |
| 23:51:45 | pamaury | Bilgus: I'm going to bed but you should push to gerrit, updated my patch with your stuff, so that we can have an overview |
icon identifies that the person is a core developer (has commit access).