| 00:00.27 | techn | also it seems that ump handling is not much different on newer blobs |
| 00:00.59 | techn | https://github.com/linux-sunxi/xf86-video-mali/commits/r3p2-01rel0 |
| 00:01.39 | penguin42 | specing: Hmm, nope, img_unpack doesn't like it, neither does afptool |
| 00:16.30 | *** join/#arm-netbook Reepicheep12 (~Reepichee@124-168-191-186.dyn.iinet.net.au) |
| 00:18.03 | penguin42 | wonders if the rk-tools have been tried cross fromx 86-64 |
| 00:19.04 | drachensun | seems like under /dev nanda-nandi use to appear but are gone now for me |
| 00:19.11 | drachensun | is that true for everyone else too? |
| 00:22.01 | techn | ssvb: this perf tool is just what I was looking for :D |
| 00:22.22 | drachensun | hmmm it only happens on my new devices, never mind |
| 00:23.29 | techn | drachensun: it propably depends on your livesuit image |
| 00:23.49 | drachensun | I tried the same images on an older model and newer model |
| 00:23.58 | drachensun | its something with the board is different |
| 00:24.13 | drachensun | the older model works and the newer doesn't, with the same SD image I mean |
| 00:52.05 | *** join/#arm-netbook freakazoid0223 (~matt@pool-173-75-233-172.phlapa.fios.verizon.net) |
| 00:55.17 | *** join/#arm-netbook tinti (~tinti@201.62.162.119) |
| 01:12.18 | ithamar | techn: is hno ever here on irc? |
| 01:12.55 | techn | ithamar: he's propably keeping some time off now |
| 01:13.18 | techn | usually he was quite active |
| 01:13.24 | ithamar | techn: ok, just wondering, as I would love to have a bit of a brainstorm with him on FEL |
| 01:13.39 | ithamar | think I might be getting close to having something working |
| 01:14.06 | ithamar | his Allwinner-info stuff gave me some explanation on stuff I had not figured out yet |
| 01:14.13 | ithamar | picture is starting to become complete now |
| 01:14.22 | techn | there was other guy why is quite into u-boot |
| 01:14.40 | techn | was it slapin or specing |
| 01:15.04 | techn | checking logs.. :) |
| 01:15.17 | ithamar | wish I was working from home again |
| 01:15.28 | ithamar | currently on-site and man, it sucks all my hacking time away |
| 01:16.02 | techn | yes.. slapin was working mtd code for u-boot |
| 01:16.31 | ithamar | ah cool, I'll check if he has done any FEL related stuff |
| 01:16.39 | ithamar | just *really* want an opensource flashing tool ;) |
| 01:17.32 | techn | :) |
| 01:21.51 | ithamar | seems livesuit sends a struct containing dram config and such from sys_config1.fex and image layout from sys_config.fex to the device at the start |
| 01:22.54 | ithamar | but it seems to be using different commands for my POV A10 tab then for hno's device |
| 01:23.42 | ithamar | almost got the full struct figured out |
| 01:31.38 | penguin42 | doesn't get this - the kernel-0.3.img that AndrewDB provided starts with the strings ANDROID! but I don't see where that comes from, the rkcrc doesn't seem to prepend it |
| 01:33.04 | ithamar | penguin42: rkcrc is for rockchip.... what are you trying to do? |
| 01:33.35 | ithamar | penguin42: "ANDROID!" is part of the header of an Android boot/recovery image (which contains a kernel) |
| 01:33.48 | penguin42 | ithamar: I'm trying to build a kernel and install it; I've got a kernel built; I've run it through rkcrc so I think I've now got a .img - but I don't quite understand how that goes together into a full image that I can write to the recovery partition |
| 01:34.09 | penguin42 | is thinking there are multiple different .img's |
| 01:34.39 | ithamar | penguin42: but you are trying to do that for a Rockchip based device? |
| 01:34.43 | penguin42 | yes |
| 01:35.41 | penguin42 | ithamar: I've just not quite seen how the flash image goes together yet |
| 01:36.30 | ithamar | penguin42: Rockchip has used different formats as well, so it might be an idea to check what is on the device to start with |
| 01:36.45 | ithamar | penguin42: busybox hd on the device might help figure that out |
| 01:37.27 | penguin42 | ithamar: I've got an image that someone else built (AndrewDB) and it starts with Android! and that's what was dd'd onto the recovery and works |
| 01:37.32 | ithamar | (hexdump bits of the partition on the device to check what is there) |
| 01:37.44 | ithamar | ah ok! |
| 01:37.47 | ithamar | that's helpful |
| 01:38.01 | ithamar | so it wants a true "Android" image on there |
| 01:38.28 | penguin42 | yeh, so that's what I'm aiming for; I've got a git checkout that apparently is his kernel tree that I've got to build, I've got an rk-tools directory, so just haven't figured out how to put them all together yet |
| 01:38.34 | ithamar | so you need to run mkbootimg on the kernel image (and possibly a initramfs) to create something you can flash |
| 01:38.42 | penguin42 | where does mkbootimg come from? |
| 01:38.49 | ithamar | Android source tree |
| 01:38.58 | penguin42 | ah |
| 01:39.15 | ithamar | needs a whole bunch of params that *have* to be correct too |
| 01:39.30 | penguin42 | http://www.armtvtech.com/armtvtechforum/viewtopic.php?f=66&t=1132 looks like that's the recipie |
| 01:40.48 | ithamar | yup that looks correct indeed |
| 01:45.41 | penguin42 | every damn platform is completely different - ode for device trees |
| 01:50.39 | ithamar | well, a lot of it is simply due to the chip manufacturers |
| 01:50.51 | ithamar | coming up with their own hacks |
| 01:50.54 | penguin42 | yes, and they need spanking hard until they start doing the basics the same way |
| 01:51.13 | ithamar | i agree there |
| 01:51.24 | ithamar | lots of spanking ;) |
| 01:51.31 | penguin42 | maybe with some nails in |
| 01:53.47 | ithamar | :O |
| 01:54.20 | penguin42 | hmm my image file is 50% larger than the one andrewdb built; it's either an issue of the kernel not being compressed, or I've got a nasty feeling I've got a 2nd copy of the ramdisk in there |
| 01:57.15 | *** join/#arm-netbook stefanro1 (~stefan@pD9FFB8A3.dip.t-dialin.net) |
| 01:59.37 | ithamar | techn: would it be ok if I move my FEL docs to the wiki? |
| 02:00.18 | ithamar | think it would make more sense then in a git repo... |
| 02:01.16 | xenoxaos | penguin42: check to make sure debugging info isnt in the kernel... |
| 02:02.25 | penguin42 | xenoxaos: Possible; but I think my problem is the duped ramdisk; I set the path to the initramfs in the kernel to the ramdisk I extracted, but then the mkbootimg also takes a path to the ramdisk |
| 02:04.08 | ithamar | penguin42: I don't think you should specify the INITRAMFS in the kernel |
| 02:04.30 | ithamar | penguin42: android passes it as a memory blob externally |
| 02:06.05 | penguin42 | ithamar: Yeh |
| 02:07.35 | penguin42 | hmm, rebooted to recovery and it's not come back |
| 02:08.03 | penguin42 | and it's not coming back after a power cycle, but is showing up on usb under a different id - I suspect stuck in boot loader? |
| 02:09.04 | ithamar | yup, in its "usb boot" recovery mode I guess |
| 02:09.19 | ithamar | that the rockchip flashing tool uses |
| 02:09.38 | ithamar | (there's a linux rkflash tool that can be used for recovery too) |
| 02:09.40 | penguin42 | not quite sure why; if it rebooted to Android then it let me bring adb up and the only thing I did at that point was an adb reboot recovery I'm not sure why it wouldn't let me get back to android |
| 02:11.03 | ithamar | are you using an MK808 device? |
| 02:11.16 | penguin42 | mk809 |
| 02:11.43 | ithamar | usually this type of behaviour is because the page size of the .img file is incorrect |
| 02:11.58 | ithamar | that's my experience on several platforms (older rockchip, telechips, etc) |
| 02:12.31 | ithamar | usually pagesize matches the nand chip page size of the device |
| 02:13.12 | penguin42 | and how do you find that out? |
| 02:14.50 | ithamar | well, if you have a working .img file, check offset 0x24, that contains the 32bit word containing the page size |
| 02:15.39 | ithamar | if that's any help |
| 02:15.51 | penguin42 | 000020 00 80 08 60 00 40 00 00 00 00 00 00 00 00 00 00 |
| 02:15.55 | penguin42 | so that's 16384 ? |
| 02:16.13 | penguin42 | which is I think what I used |
| 02:17.02 | ithamar | yeah that looks correct |
| 02:17.06 | ithamar | hmmmm |
| 02:17.14 | ithamar | so it is complaining about something else |
| 02:17.35 | ithamar | the post you linked to also said something about having to use a "special" mkbootimg.... |
| 02:17.46 | penguin42 | I used the one from that post |
| 02:17.46 | ithamar | seems to include a SHA hash or so |
| 02:17.51 | ithamar | okidoki |
| 02:18.07 | ithamar | then I'm at a loss too :( |
| 02:18.25 | penguin42 | but I dd'd it into the recovery part - so why it screwd up the main one is hmm |
| 02:18.49 | ithamar | no, it is still set to boot into recovery |
| 02:19.16 | ithamar | the bootloader is just so stupid to not try the main when recovery fails |
| 02:19.23 | penguin42 | oh right, erm that's dumb |
| 02:19.41 | ithamar | yup, but also common on many platforms :( |
| 02:20.02 | penguin42 | so there's some simple and easy convenient way to flip the bootloader back - right? |
| 02:20.37 | ithamar | flash a working recovery? :/ |
| 02:20.59 | ithamar | or clear the misc partition somehow |
| 02:21.29 | ithamar | at least on older rockchips that's where it was stored (commands to instruct the bootloader to boot into recovery) |
| 02:21.59 | ithamar | "real" platforms use registers that survive reboot |
| 02:22.20 | ithamar | in that case a real power off/on would reset it |
| 02:23.16 | penguin42 | hmm well I have rkflashtool |
| 02:23.51 | ithamar | that should do it if you know the offsets of the partitions |
| 02:25.08 | penguin42 | that would seem a good thing to know wouldn't it - hmm well I've got the cmdline and that's apparently got what look like offsets? mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00004000@0x00004000(kernel),0x00008000@0x00008000(boot),0x00008000@0x00010000(recovery),0x000C0000@0x00018000(backup),0x00040000@0x000D8000(cache),0x00100000@0x00118000(userdata),0x00002000@0x00218000(kpanic),0x00100000@0x0021A000(system),-@0x0033A000(user) bootver=2012-0 |
| 02:26.12 | ithamar | yup, seems to be size@offset |
| 02:26.50 | ithamar | hmmm wonder why there is a seperate "kernel" partition.... |
| 02:27.54 | ithamar | anyway, I'm off to bed, it is 3:30AM here |
| 02:28.02 | penguin42 | yeh, 2:30 here - I must go soon as well |
| 02:28.14 | penguin42 | Thanks! |
| 02:28.21 | ithamar | ah in the UK penguin42 ? |
| 02:28.52 | ithamar | (I am in NL) |
| 02:29.04 | penguin42 | yeh |
| 02:29.53 | ithamar | well, have a good night, and good luck with the hacking! |
| 02:29.56 | penguin42 | thanks! |
| 02:31.08 | *** join/#arm-netbook ganbold_ (~Ganbold@202.21.108.213) |
| 02:31.49 | *** join/#arm-netbook hg_5 (~chatzilla@unaffiliated/hg-5/x-8664886) |
| 02:32.30 | *** join/#arm-netbook lerc (~quassel@121-74-244-63.telstraclear.net) |
| 03:09.46 | penguin42 | hmm rkflashtool doesn't seem to want to be much help - just dumping out repeating junk; time to go to bed I think |
| 03:20.26 | *** join/#arm-netbook piezo (~piezo@pdpc/supporter/active/piezo) |
| 03:30.57 | *** join/#arm-netbook rz2k (~rz2k@95-25-154-89.broadband.corbina.ru) |
| 04:22.16 | *** join/#arm-netbook aholler (~aholler@p57B21045.dip0.t-ipconnect.de) |
| 04:25.17 | *** join/#arm-netbook Reepicheep12 (~Reepichee@124-168-191-186.dyn.iinet.net.au) |
| 04:30.16 | Reepicheep12 | I'm getting 50%-100% cpu usage while playing audio using mplayer on the Mele a1000 with the kernel I compiled from sunxi-bsp. This happens with both sunxi-3.0 and sunxi-3.4. It happens on both USB DAC output and composite output. No resampling is going on as far as I can tell. Any ideas? |
| 04:30.30 | Reepicheep12 | mnemoc: I'm wondering if any of those flags I disabled (which I thought were video related) could have affected audio output (or decoding). My kernel config is here: http://sprunge.us/jcFS |
| 04:32.04 | rz2k | Reepicheep12: http://linux-sunxi.org/Cpufreq |
| 04:33.01 | rz2k | set your cpu for 1ghz and you will have 10-30% for mp3s |
| 04:36.49 | Reepicheep12 | 5% now, incredible thank you. |
| 05:05.13 | Turl | 100% isn't always a bad thing |
| 05:09.38 | Reepicheep12 | Yeah fair enough although there was awful stuttering (which I knew was avoidable as other distros on this device performed fine). Fixed now though thanks to the brains trust. |
| 05:10.45 | Turl | yeah, that's because the defaults are a bit agressive |
| 05:21.33 | orly_owl | anyone here running a freedombox? |
| 06:19.56 | *** join/#arm-netbook Quarx (~Quarx@178.74.64.56) |
| 06:57.56 | *** join/#arm-netbook hipboi (~hipboi@123.89.122.92) |
| 07:04.32 | *** join/#arm-netbook cheng (~cheng@193.48.48.60.kmr03-home.tm.net.my) |
| 07:05.49 | *** join/#arm-netbook eebrah (~chatzilla@212.49.88.106) |
| 07:34.47 | *** join/#arm-netbook hp__ (~kvirc@d5153E228.access.telenet.be) |
| 08:00.33 | *** join/#arm-netbook Alex1269 (550f765b@gateway/web/freenode/ip.85.15.118.91) |
| 08:15.25 | *** join/#arm-netbook gsilvis (~almostsix@50.12.163.241) |
| 08:36.19 | provel_ | Anyone knows if CEC is working? |
| 08:36.31 | provel_ | on mele a1000 and such ... |
| 08:37.35 | *** join/#arm-netbook provel_ (~matte@host179-120-dynamic.32-79-r.retail.telecomitalia.it) |
| 08:43.59 | provel_ | nobody tried CEC? |
| 08:50.26 | *** join/#arm-netbook rellla (~Thunderbi@p4FE56075.dip0.t-ipconnect.de) |
| 08:54.35 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 08:55.35 | andoma | provel_: no drivers exist in kernel for CEC on allwiner devices |
| 09:12.51 | provel_ | andoma: ok thank you.... and no documentation to write one? |
| 09:34.34 | hno | ithamar, I am around but not actively at the computer at the moment. |
| 09:42.20 | *** join/#arm-netbook rsalveti (~rsalveti@unaffiliated/rsalveti) |
| 09:45.15 | ithamar | hno: I'm going to start documenting the FEL commands/LiveSuit flashing on the wiki this week |
| 09:45.51 | ithamar | hno: Just noticed from your traces your device uses protocol version 1, while mine is protocol 2 (as returned from the version command) |
| 09:49.46 | ithamar | hno: the general flow seems to be the same, but protocol 1 seems to only use the SRAM for flashing, whilst 2 uses the DRAM too |
| 09:52.16 | *** join/#arm-netbook hansg (~hans@ip32-174-211-87.adsl2.static.versatel.nl) |
| 10:15.46 | *** join/#arm-netbook von_fritz (~fritz@host212-191-dynamic.4-87-r.retail.telecomitalia.it) |
| 10:22.00 | ithamar | hno: will check if I have protocol version 1 device here as well |
| 10:55.30 | gzamboni | Does anyone know the audio mixer values for the mixer control "ADC Input Mux" ? its not a enum so i cant know witch value is for the linein / fmin / micin |
| 10:55.37 | gzamboni | As i understood the "Mic Input Mux" is for setting the ADC from 9 to 12 bits |
| 10:55.59 | gzamboni | as the A10 has only one 24bit ADC i supose the "ADC Input Mux" is the muxer for selecting the input port |
| 10:56.17 | gzamboni | and the micin port has a hardware preamplifier |
| 11:11.50 | buZz | hansg: hey |
| 11:12.30 | buZz | hansg: i have a 1366x768 hdmi screen on my cubieboard, but your EDID patches dont select 1360x768 with them enabled, but setting the mode by hand does work |
| 11:14.09 | hramrach | hello |
| 11:14.24 | hramrach | anyone knows a sane way to use the leds? |
| 11:15.04 | hramrach | I wrote a script that reads a file in /sys, compares with previous, if different lights led |
| 11:15.14 | hramrach | which lights led when disk is accessed |
| 11:15.42 | hramrach | the led trigger seems only available for real IDE disks in kernel it seems |
| 11:15.54 | hramrach | and iptables |
| 11:16.14 | hramrach | so if you had IDS you could light a led when under attack or something |
| 11:16.29 | hramrach | but not what I am looking for at this moment |
| 11:16.53 | buZz | did you try the new driver? |
| 11:17.06 | hramrach | it provides a trigger slot |
| 11:17.15 | buZz | yeah |
| 11:17.18 | hramrach | but what you plug in that slot to make something useful? |
| 11:17.28 | buZz | a trigger ;) |
| 11:17.34 | buZz | google linux led triggers |
| 11:17.52 | hramrach | did not find any in the kernel that I could use |
| 11:18.02 | hramrach | are they provided as oot modules? |
| 11:18.36 | buZz | there are some in the kernel |
| 11:18.36 | hramrach | if so that's _very_ impractical |
| 11:18.43 | buZz | but you could write your own |
| 11:18.52 | buZz | linux LED support is not A10 specific |
| 11:19.03 | buZz | either use it, or just do your own stuff through gpio |
| 11:19.11 | buZz | no use reinventing the wheel imho |
| 11:19.16 | hramrach | but the triggers seem driver specific |
| 11:19.21 | buZz | they arent |
| 11:19.52 | hramrach | so where is that documented how you use the disk trigger with MMC? |
| 11:20.02 | hramrach | kinda did not find anything on that |
| 11:20.09 | hramrach | or even with sata disk |
| 11:20.36 | buZz | did you google 'linux led triggers' |
| 11:20.42 | buZz | because all this stuff is not A10 specifiv |
| 11:20.45 | buZz | specific* |
| 11:20.52 | hramrach | indeed, it is not |
| 11:21.00 | hramrach | will try another google dance |
| 11:21.04 | buZz | s/A10/platform/ |
| 11:21.11 | hramrach | was looking in hte kernel docs only so far iirc |
| 11:26.21 | hramrach | I see led trigger for CPU activity |
| 11:26.25 | hramrach | and that's it |
| 11:26.41 | gzamboni | someone ported the linux led driver for A10 |
| 11:26.42 | hramrach | looks like the LED subsystem is under development still |
| 11:26.53 | hramrach | you need not port it |
| 11:26.53 | gzamboni | i saw this week on the sunxi ML |
| 11:27.00 | hramrach | it's not platform specific |
| 11:27.14 | hramrach | but the framework has no useful triggers |
| 11:27.22 | hramrach | in 3.4 at least |
| 11:28.48 | hramrach | I guess I just update the script for the new driver when I rebuild the kernel |
| 11:29.18 | hramrach | maybe we get more triggers in 3.8 |
| 11:29.35 | hramrach | and if not then it's time to reinvent more wheels |
| 11:32.10 | *** join/#arm-netbook hg_5 (~chatzilla@unaffiliated/hg-5/x-8664886) |
| 11:38.05 | hansg | buzz, the problem is that 1366 does not divide by 8, and the EDID info from your board likely does not also advertise 1360x768, or at least not as the second mode in its EDID DTD list (assuming 1366x768 is the first) |
| 11:38.23 | hansg | dmesg output should confirm this |
| 11:38.49 | buZz | hansg: ooo, i thought you added a hack to let 1366 jump to 1360 mode |
| 11:38.55 | buZz | but i guess i was mistaken :D |
| 11:38.59 | hansg | buzz, no |
| 11:39.13 | buZz | ok ty :D |
| 11:40.07 | hansg | The proper fix would be to figure out how to tell the lcd + hdmi code that there is a framebuffer with a pitch of 1368 pixels, but a width of 1366, iow that there is 2 bytes of pixels / row padding |
| 11:40.45 | hansg | At least I think that that will make X happy. You can remove the is this a multiple of 8 check from the EDID code if you only use fbcon, but it breaks X. |
| 11:40.48 | hansg | Patches welcome :) |
| 11:43.33 | buZz | :P |
| 11:43.50 | buZz | well its funny, the 1360 mode gets stretched to 1366 on my screen :P |
| 12:14.42 | *** join/#arm-netbook Quarx|2 (~Quarx@176.62.122.115) |
| 12:16.36 | *** join/#arm-netbook Quarx (~Quarx@176.62.122.115) |
| 12:20.34 | *** part/#arm-netbook Reepicheep12 (~Reepichee@124-168-191-186.dyn.iinet.net.au) |
| 12:22.08 | *** join/#arm-netbook penguin42 (~dg@tu006.demon.co.uk) |
| 13:15.15 | penguin42 | hmph, the data that rkflashtool is dumping in no way corresponds to what wireshark sees - although neither of them makes any sense - rkflashtool sees just counting numbers, wireshark sees all FF's |
| 13:23.54 | *** join/#arm-netbook merbzt (~benjamin@c-94-255-219-122.cust.bredband2.com) |
| 13:35.48 | *** join/#arm-netbook Avernos_ (~avernos@221.223.240.39) |
| 14:13.06 | ithamar | does anyone know if https://github.com/allwinnerwk is an official Allwinner repo ? |
| 14:26.44 | mnemoc | ithamar: yes, it is |
| 14:27.40 | ithamar | mnemoc: ah cool, thanks for confirming ;) |
| 14:49.11 | *** join/#arm-netbook tinti (~tinti@201.62.162.119) |
| 14:53.43 | *** join/#arm-netbook provel_ (~matte@host179-120-dynamic.32-79-r.retail.telecomitalia.it) |
| 14:54.13 | provel_ | anyone knows if allwinner A10 uses same cec chip as others? (tda9950) |
| 14:56.02 | *** join/#arm-netbook rsalveti (~rsalveti@unaffiliated/rsalveti) |
| 15:09.01 | L84Supper | provel_: http://doc.chipfind.ru/pdf/philips/tda9550.pdf ? |
| 15:10.58 | *** join/#arm-netbook lkcl (~lkcl@host-92-26-28-63.as13285.net) |
| 15:16.50 | *** join/#arm-netbook ganbold__ (~Ganbold@202.21.108.213) |
| 15:20.46 | *** join/#arm-netbook freakazoid0223 (~matt@pool-173-75-233-172.phlapa.fios.verizon.net) |
| 15:45.41 | penguin42 | it's a pity rkflashtool is doing nothing sane for me (except the reboot option works) - does anyone know if anyone has written down any of the protocol they've worked out? |
| 15:51.05 | ithamar | penguin42: read the source ;) |
| 15:51.37 | ithamar | penguin42: it is pretty straightforward, but afaik it has only been tested on rk28xx and rk29xx |
| 15:52.17 | penguin42 | ithamar: There are various people who've said they've had success on the rk3066 but mine is giving back bogus data (or the flash is particularly wiped) |
| 15:52.37 | penguin42 | but there again it seems to be sending back the right size data - so it can't be too confused |
| 15:53.01 | ithamar | offset passed to rkflash(tool) is in blocks, not in bytes iirc |
| 15:53.12 | penguin42 | yeh 512byte blocks |
| 15:53.29 | ithamar | (havent touched rockchip for months at least so not 100% sure) |
| 15:53.30 | penguin42 | but I'm reading large chunks and dumping it, I either have blocks of all FF's or blocks that just have counting data |
| 15:54.12 | ithamar | hmmmm |
| 15:54.27 | penguin42 | exactly |
| 15:54.52 | penguin42 | the reboot command works, and the read is returning sane sized data - so not completely dead |
| 15:56.20 | penguin42 | there is one comment somewhere about there being two recovery modes, a type 1 which is where you short the pins together and it only works with their windows tool that no one has reversed yet, I wonder if it's somehow got into that - but I haven't done the pin short yet |
| 15:57.36 | ithamar | hmmm would not expect that if i hear the results you're getting |
| 15:58.14 | penguin42 | yeh, so I'm thinking it's some disagreement about the protocol, and it looks like the protocol is some form of send a command and you receive a response packet and then a chunk of data |
| 15:58.49 | ithamar | yeah it is pretty straightforward |
| 15:59.42 | ithamar | I think the issue is more with the parameters then the protocol |
| 15:59.58 | ithamar | if your read is returning data it suggests that it _thinks_ the command is valid |
| 16:00.16 | penguin42 | yeh, so I'm wondering if it's encoding the address to read wrongly |
| 16:02.06 | penguin42 | lots of people saying they're just patching the uid |
| 16:10.27 | ithamar | might want to look if they list any of the arguments there, maybe they are doing something "special" with the offsets somehow |
| 16:11.03 | ithamar | e.g. how to map the mtd offset parameters to the kernel to parameters for rkflashtool |
| 16:19.24 | *** join/#arm-netbook rellla (~Thunderbi@p4FE56075.dip0.t-ipconnect.de) |
| 16:20.23 | penguin42 | yeh, that's why I've been trying to dump larger chunks assuming I'll hit something interesting |
| 16:36.08 | *** join/#arm-netbook Holo_ (uid6962@gateway/web/irccloud.com/x-vqsayqsddiurubgk) |
| 17:02.01 | *** join/#arm-netbook xman (~Vinicius@177.159.217.152) |
| 17:03.05 | *** join/#arm-netbook jukivili (~jussi@dalek.fi) |
| 17:39.56 | penguin42 | hmm, the good news is I can write a block and read it |
| 18:05.37 | hno | ithamar, protocol 1 is used by FEL. Protocol 2 is the protocol handler uploaded over FEL. Both uses the same command structure. |
| 18:05.51 | hno | process is: |
| 18:06.00 | hno | 1. Device boots in FEL mode. |
| 18:06.25 | hno | 2. Livesuit uploads & executes code for initializing the hardware (DRAM etc). |
| 18:06.49 | hno | 3. Livesuit uploads the flashing application and starts it. |
| 18:07.23 | hno | 3. Flashing application takes over the control. Resets USB and when it returns it's now runnign protocol 2. |
| 18:07.41 | hno | 4. Livesuit communicates with the flashing application using protocol version 2. |
| 18:08.27 | hno | I only have interest in protocol version 1 as that is what the boot ROM implements. |
| 18:08.37 | hno | version 2 is all software uploaded to the device by livesuit. |
| 18:24.27 | *** join/#arm-netbook wingrime (~wingrime@78.109.115.103) |
| 18:25.42 | ithamar | hno: thanks! I'll include this on the wiki pages I'm going to create |
| 18:26.36 | penguin42 | wonders what to do with this 370MB recovery image - I guess split it and put each one back in the appropriate place? |
| 18:27.25 | ithamar | hno: it does explain why my trace said v2 while the device said v1 using the fel tool ;) |
| 18:28.42 | ithamar | hno: guess I have spent my time looking at the wrong traces :( |
| 18:30.14 | L84Supper | " Instead of creating buildings that made up of discrete parts fulfilling distinct functions, such as protective shell, insulation and connection, Oxman thinks a building's skin should be like human skin whose pores also contract and expand in relation to the environment. Her team is now now considering ways of printing these sort of breathable building skins to integrate barrier and filtering functions into a single material system." |
| 18:30.47 | L84Supper | the problem is getting building departments to go along with any changes to traditional building methods |
| 18:32.15 | penguin42 | looks at L84Supper |
| 18:32.18 | L84Supper | soory |
| 18:32.24 | L84Supper | wrong channel |
| 18:32.32 | penguin42 | now I wonder which one it was for |
| 18:32.48 | L84Supper | but while I'm here, did people start getti g their cubieboards |
| 18:32.58 | L84Supper | #reprap |
| 18:38.02 | L84Supper | I still have to test the interrupt response time on the a10 |
| 18:38.44 | L84Supper | the TI AM335x has a nice Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS) |
| 18:38.50 | L84Supper | but it's overpriced |
| 18:39.21 | penguin42 | L84Supper: Nothing that can't be fixed with a FIQ routine? |
| 18:40.20 | L84Supper | maybe, maybe not, some designs just don't care about it |
| 18:40.38 | specing | Or get a cortex-M micro and interface it |
| 18:42.05 | L84Supper | with x86 we get <4us latency jitter on irq's with RTAI, <10us with xenomai |
| 18:42.16 | penguin42 | or a dual core and keep one for real time |
| 18:42.52 | penguin42 | what x86 - that's a big range, and some of the BIOSs can just go off and wipe their arse for a while |
| 18:43.20 | L84Supper | yeah, especially during an SMI event |
| 18:43.45 | penguin42 | nod |
| 18:43.46 | L84Supper | but with SMI killed or using coreboot it in the few microseconds |
| 18:44.11 | br- | ithamar / hno: where is wiki you guys are using? |
| 18:44.36 | penguin42 | L84Supper: yeh, and some of them fudge the tsc during the SMI to make it appear like it didn't do anything; so use an external device to time it |
| 18:47.07 | penguin42 | hmm so I have a system.img, a misc.img, a kernel.img and boot.img - I wonder which I should put in - I guess follow the offsets from the kernel command line? |
| 18:47.39 | L84Supper | someone has the beaglebone with TI AM335x supporting 200khz stepping with stepper motors and xenomai, I'm still wondering if the A10 can do as well |
| 18:48.51 | penguin42 | they're both A8's |
| 18:49.14 | penguin42 | as long as you keep the video off the bus and aren't RAM heavy I don't see there would be much odds ? |
| 18:49.49 | L84Supper | yes, just not sure how they laid out the fast GPIO and on what bus |
| 18:50.13 | L84Supper | have to try and see |
| 18:51.44 | *** join/#arm-netbook xman (~Vinicius@177.159.217.152) |
| 18:54.31 | penguin42 | hmph, that hasn't unbricked it |
| 19:04.51 | *** join/#arm-netbook arete74_ (~arete74@net-93-64-241-175.cust.dsl.vodafone.it) |
| 19:13.43 | L84Supper | penguin42: the only reason to use the a10 is controlling the CNC as well as driving the UI display, so it's a matter of finding out how well the IRQ's consistently perform under video, ram, sata loads |
| 19:14.48 | L84Supper | running just the machine controller should be similar to the TI, even some arm9 work well enough |
| 19:16.14 | L84Supper | https://www.youtube.com/watch?v=w3Ls5ta7eg8 |
| 19:17.30 | L84Supper | http://code.google.com/p/miniemc2/ mini2440 platform: ARM920T CPU running at 400 MHz, 64Mb of SDRAM |
| 19:23.10 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 19:24.33 | L84Supper | i.mx6 might be nice as well for machine control, if they ever ship in volume |
| 19:24.58 | *** join/#arm-netbook eebrah (~chatzilla@41.223.58.75) |
| 19:25.57 | jinzo | L84Supper, afaik the single and dual core production doesen't have the problems the quad core version has. |
| 19:25.57 | specing | i.mx6 would be nice if you wanted that machine to think for itself (ie have an AI running on it) |
| 19:26.17 | jinzo | but hardly anyone is interested in that it seems |
| 19:28.51 | *** join/#arm-netbook hg_5 (~chatzilla@unaffiliated/hg-5/x-8664886) |
| 19:29.28 | penguin42 | this is weird; if I write with rkflashtool and read back it seems fine; but then I reboot and it's back to reading garbage |
| 19:33.47 | L84Supper | jinzo: are any boards shipping with the single or dual core i.mx6? wandboards are way behind schedule |
| 19:34.30 | jinzo | L84Supper, I wouldn't know - just a observation on my side. |
| 19:34.57 | jinzo | and if we draw parralels with the desktop CPU world,... |
| 19:35.13 | L84Supper | http://wandboard.org/ just wondering since their website still has reservations vs an order button |
| 19:35.18 | ithamar | penguin42: almost sounds like you are reading/writing RAM instead of flash |
| 19:35.26 | penguin42 | ithamar: Yeh, odd sort of flash! |
| 19:35.47 | penguin42 | ithamar: I'm wondering if the tables they use for wear leveling etc are screwed |
| 19:36.25 | penguin42 | ithamar: http://www.armtvtech.com/armtvtechforum/viewtopic.php?f=4&t=1283&p=7651#p7651 describes what I did |
| 19:36.29 | L84Supper | every ARM solution for machine control and UI on one board always ends up far more expensive than an x86 board |
| 19:36.31 | ithamar | penguin42: something weird is up for sure |
| 19:36.58 | penguin42 | ithamar: I'm tempted trying to do a full erase and try again, but that sounds even more dangerous |
| 19:37.09 | penguin42 | ithamar: ANd I don't have a windows box to try shorting the pins |
| 19:39.26 | ithamar | penguin42: still wonder why these ppl don't supply a linux flasher (even nvidia does that) |
| 19:39.53 | penguin42 | ithamar: Costs time to write & test |
| 19:40.15 | penguin42 | ithamar: You'd think these days they'd run their tools from other Android boxes! |
| 19:41.08 | penguin42 | ithamar: Of course if they just released the specs of their protocol that would also solve the problem |
| 19:44.30 | *** join/#arm-netbook lerc (~quassel@121.75.145.113) |
| 19:51.23 | *** join/#arm-netbook tinti (~tinti@201.62.162.119) |
| 20:03.52 | penguin42 | right, that's enough breaking things for this weekend |
| 20:10.22 | *** join/#arm-netbook hg_5 (~chatzilla@unaffiliated/hg-5/x-8664886) |
| 20:14.42 | Guest85545 | huaah.. static cycle_t aw_clksrc_read(struct clocksource *cs) is taking 15% of idletime on xbmc |
| 20:15.46 | Guest85545 | if you take interrupt hanling away.. it's still 7% |
| 20:17.01 | jelly-home | bad event loop is bad? |
| 20:18.23 | *** join/#arm-netbook techn_ (~quassel@a91-152-35-60.elisa-laajakaista.fi) |
| 20:47.39 | bsdfox | no ubuntu repo for syslinux? |
| 20:47.53 | bsdfox | I only see syslinux-common that doesn't have the syslinux binary |
| 20:48.37 | *** join/#arm-netbook Alex1269 (558e46db@gateway/web/freenode/ip.85.142.70.219) |
| 21:01.42 | *** join/#arm-netbook lerc (~quassel@121.75.145.113) |
| 21:04.00 | *** join/#arm-netbook Alex1269_ (558e46db@gateway/web/freenode/ip.85.142.70.219) |
| 21:31.33 | *** join/#arm-netbook eebrah (~chatzilla@41.223.58.74) |
| 21:52.54 | *** join/#arm-netbook hg_5_ (~chatzilla@ip-84-39-175-133.free.aero2.net.pl) |
| 21:54.26 | *** join/#arm-netbook hg_5__ (~chatzilla@91.234.245.245) |
| 21:56.51 | nemik | are there any current livesuite images for linaro/ubuntu? all i've seen is for android |
| 22:13.50 | *** join/#arm-netbook freakazoid0223 (~matt@pool-173-75-233-172.phlapa.fios.verizon.net) |
| 22:26.14 | *** part/#arm-netbook provel_ (~matte@host179-120-dynamic.32-79-r.retail.telecomitalia.it) |
| 22:34.05 | jinzo | hm are A31 devices already shipping? |
| 22:34.37 | jinzo | http://www.onda-tablet.com/onda-v812-quad-core-tablet-pc-android-allwinner-a31-wifi-hd-2160p-dual-camera-16gb.html |
| 22:34.47 | jinzo | looks like the same people that run ainol-novo.com |
| 22:37.15 | techn_ | it that kind tablet is under 200.. how cheap a20 tablet will be :p |
| 22:37.43 | jinzo | there's a 9.7 inch for 230 |
| 22:37.52 | jelly-home | now see, 2160p implies a 3840x2160 resolution, not 1024x768 |
| 22:38.25 | jinzo | output capability probably. |
| 22:39.09 | jelly-home | probably similar to 1.5GHz A10 |
| 22:59.29 | *** join/#arm-netbook asderca77 (~ared@host209-178-dynamic.9-87-r.retail.telecomitalia.it) |
| 23:07.24 | *** join/#arm-netbook hugoroyd (uid6558@gateway/web/irccloud.com/x-fviamilzlsjewlrm) |
| 23:30.09 | nemik | techn_: did you ever get a working livesuit img with ubuntu/linaro rootfs? i'd like to make one with mk_livesuite_img.sh |