<penguin42>
specing: Hmm, nope, img_unpack doesn't like it, neither does afptool
Reepicheep12 has joined #arm-netbook
* penguin42
wonders if the rk-tools have been tried cross fromx 86-64
<drachensun>
seems like under /dev nanda-nandi use to appear but are gone now for me
<drachensun>
is that true for everyone else too?
<techn>
ssvb: this perf tool is just what I was looking for :D
<drachensun>
hmmm it only happens on my new devices, never mind
<techn>
drachensun: it propably depends on your livesuit image
<drachensun>
I tried the same images on an older model and newer model
<drachensun>
its something with the board is different
<drachensun>
the older model works and the newer doesn't, with the same SD image I mean
hp__ has quit [Ping timeout: 246 seconds]
dagoo has quit [Quit: dagoo]
freakazoid0223 has joined #arm-netbook
tinti has joined #arm-netbook
tinti has quit [Remote host closed the connection]
<ithamar>
techn: is hno ever here on irc?
<techn>
ithamar: he's propably keeping some time off now
<techn>
usually he was quite active
<ithamar>
techn: ok, just wondering, as I would love to have a bit of a brainstorm with him on FEL
<ithamar>
think I might be getting close to having something working
<ithamar>
his Allwinner-info stuff gave me some explanation on stuff I had not figured out yet
<ithamar>
picture is starting to become complete now
<techn>
there was other guy why is quite into u-boot
<techn>
was it slapin or specing
<techn>
checking logs.. :)
<ithamar>
wish I was working from home again
<ithamar>
currently on-site and man, it sucks all my hacking time away
<techn>
yes.. slapin was working mtd code for u-boot
<ithamar>
ah cool, I'll check if he has done any FEL related stuff
<ithamar>
just *really* want an opensource flashing tool ;)
<techn>
:)
<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
<ithamar>
but it seems to be using different commands for my POV A10 tab then for hno's device
<ithamar>
almost got the full struct figured out
* 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
<ithamar>
penguin42: rkcrc is for rockchip.... what are you trying to do?
<ithamar>
penguin42: "ANDROID!" is part of the header of an Android boot/recovery image (which contains a kernel)
<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
* penguin42
is thinking there are multiple different .img's
<ithamar>
penguin42: but you are trying to do that for a Rockchip based device?
<penguin42>
yes
<penguin42>
ithamar: I've just not quite seen how the flash image goes together yet
<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
<ithamar>
penguin42: busybox hd on the device might help figure that out
<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
<ithamar>
(hexdump bits of the partition on the device to check what is there)
<ithamar>
ah ok!
<ithamar>
that's helpful
<ithamar>
so it wants a true "Android" image on there
<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
<ithamar>
so you need to run mkbootimg on the kernel image (and possibly a initramfs) to create something you can flash
<penguin42>
where does mkbootimg come from?
<ithamar>
Android source tree
<penguin42>
ah
<ithamar>
needs a whole bunch of params that *have* to be correct too
<penguin42>
every damn platform is completely different - ode for device trees
<ithamar>
well, a lot of it is simply due to the chip manufacturers
<ithamar>
coming up with their own hacks
<penguin42>
yes, and they need spanking hard until they start doing the basics the same way
<ithamar>
i agree there
<ithamar>
lots of spanking ;)
<penguin42>
maybe with some nails in
<ithamar>
:O
<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
stefanro1 has joined #arm-netbook
stefanro has quit [Ping timeout: 264 seconds]
<ithamar>
techn: would it be ok if I move my FEL docs to the wiki?
<ithamar>
think it would make more sense then in a git repo...
<xenoxaos>
penguin42: check to make sure debugging info isnt in the kernel...
<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
<ithamar>
penguin42: I don't think you should specify the INITRAMFS in the kernel
<ithamar>
penguin42: android passes it as a memory blob externally
<penguin42>
ithamar: Yeh
<penguin42>
hmm, rebooted to recovery and it's not come back
<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?
<ithamar>
yup, in its "usb boot" recovery mode I guess
<ithamar>
that the rockchip flashing tool uses
<ithamar>
(there's a linux rkflash tool that can be used for recovery too)
<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
<ithamar>
are you using an MK808 device?
<penguin42>
mk809
<ithamar>
usually this type of behaviour is because the page size of the .img file is incorrect
<ithamar>
that's my experience on several platforms (older rockchip, telechips, etc)
<ithamar>
usually pagesize matches the nand chip page size of the device
<penguin42>
and how do you find that out?
<ithamar>
well, if you have a working .img file, check offset 0x24, that contains the 32bit word containing the page size
<ithamar>
so it is complaining about something else
<ithamar>
the post you linked to also said something about having to use a "special" mkbootimg....
<penguin42>
I used the one from that post
<ithamar>
seems to include a SHA hash or so
<ithamar>
okidoki
<ithamar>
then I'm at a loss too :(
<penguin42>
but I dd'd it into the recovery part - so why it screwd up the main one is hmm
<ithamar>
no, it is still set to boot into recovery
<ithamar>
the bootloader is just so stupid to not try the main when recovery fails
<penguin42>
oh right, erm that's dumb
<ithamar>
yup, but also common on many platforms :(
<penguin42>
so there's some simple and easy convenient way to flip the bootloader back - right?
<ithamar>
flash a working recovery? :/
<ithamar>
or clear the misc partition somehow
<ithamar>
at least on older rockchips that's where it was stored (commands to instruct the bootloader to boot into recovery)
<ithamar>
"real" platforms use registers that survive reboot
<ithamar>
in that case a real power off/on would reset it
<penguin42>
hmm well I have rkflashtool
<ithamar>
that should do it if you know the offsets of the partitions
<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
<ithamar>
yup, seems to be size@offset
<ithamar>
hmmm wonder why there is a seperate "kernel" partition....
<ithamar>
anyway, I'm off to bed, it is 3:30AM here
<penguin42>
yeh, 2:30 here - I must go soon as well
<penguin42>
Thanks!
<ithamar>
ah in the UK penguin42 ?
<ithamar>
(I am in NL)
<penguin42>
yeh
<ithamar>
well, have a good night, and good luck with the hacking!
<penguin42>
thanks!
hg_5 has quit [Ping timeout: 276 seconds]
ganbold_ has joined #arm-netbook
hg_5 has joined #arm-netbook
lerc has joined #arm-netbook
hg_5 has quit [Ping timeout: 246 seconds]
freakazoid0223 has quit [Ping timeout: 264 seconds]
piezo has quit [Ping timeout: 264 seconds]
<penguin42>
hmm rkflashtool doesn't seem to want to be much help - just dumping out repeating junk; time to go to bed I think
penguin42 has quit [Quit: Leaving.]
piezo has joined #arm-netbook
rz2k has joined #arm-netbook
Reepicheep12 has quit [Remote host closed the connection]
aholler has joined #arm-netbook
Reepicheep12 has joined #arm-netbook
aholler_ has quit [Ping timeout: 248 seconds]
<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?
<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
<rz2k>
set your cpu for 1ghz and you will have 10-30% for mp3s
<Reepicheep12>
5% now, incredible thank you.
<Turl>
100% isn't always a bad thing
<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.
<Turl>
yeah, that's because the defaults are a bit agressive
<orly_owl>
anyone here running a freedombox?
Quarx has joined #arm-netbook
hipboi has joined #arm-netbook
cheng has joined #arm-netbook
eebrah has joined #arm-netbook
cheng has quit [Quit: Leaving]
hp__ has joined #arm-netbook
eebrah has quit [Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121213185036]]
Alex1269 has joined #arm-netbook
gsilvis has quit [Read error: Connection reset by peer]
gsilvis has joined #arm-netbook
<provel_>
Anyone knows if CEC is working?
<provel_>
on mele a1000 and such ...
provel_ has quit [Quit: leaving]
provel_ has joined #arm-netbook
<provel_>
nobody tried CEC?
rellla has joined #arm-netbook
gimli has joined #arm-netbook
<andoma>
provel_: no drivers exist in kernel for CEC on allwiner devices
<provel_>
andoma: ok thank you.... and no documentation to write one?
provel_ has quit [Quit: leaving]
lerc has quit [Ping timeout: 246 seconds]
<hno>
ithamar, I am around but not actively at the computer at the moment.
rellla has quit [Quit: rellla]
rsalveti has quit [Ping timeout: 248 seconds]
rsalveti has joined #arm-netbook
<ithamar>
hno: I'm going to start documenting the FEL commands/LiveSuit flashing on the wiki this week
<ithamar>
hno: Just noticed from your traces your device uses protocol version 1, while mine is protocol 2 (as returned from the version command)
<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
hansg has joined #arm-netbook
hipboi has quit [Quit: Leaving]
von_fritz has joined #arm-netbook
<ithamar>
hno: will check if I have protocol version 1 device here as well
<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
<gzamboni>
As i understood the "Mic Input Mux" is for setting the ADC from 9 to 12 bits
<gzamboni>
as the A10 has only one 24bit ADC i supose the "ADC Input Mux" is the muxer for selecting the input port
<gzamboni>
and the micin port has a hardware preamplifier
<buZz>
hansg: hey
<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
<hramrach>
hello
<hramrach>
anyone knows a sane way to use the leds?
<hramrach>
I wrote a script that reads a file in /sys, compares with previous, if different lights led
<hramrach>
which lights led when disk is accessed
<hramrach>
the led trigger seems only available for real IDE disks in kernel it seems
<hramrach>
and iptables
<hramrach>
so if you had IDS you could light a led when under attack or something
<hramrach>
but not what I am looking for at this moment
<buZz>
did you try the new driver?
<hramrach>
it provides a trigger slot
<buZz>
yeah
<hramrach>
but what you plug in that slot to make something useful?
<buZz>
a trigger ;)
<buZz>
google linux led triggers
<hramrach>
did not find any in the kernel that I could use
<hramrach>
are they provided as oot modules?
<buZz>
there are some in the kernel
<hramrach>
if so that's _very_ impractical
<buZz>
but you could write your own
<buZz>
linux LED support is not A10 specific
<buZz>
either use it, or just do your own stuff through gpio
<buZz>
no use reinventing the wheel imho
<hramrach>
but the triggers seem driver specific
<buZz>
they arent
<hramrach>
so where is that documented how you use the disk trigger with MMC?
<hramrach>
kinda did not find anything on that
<hramrach>
or even with sata disk
<buZz>
did you google 'linux led triggers'
<buZz>
because all this stuff is not A10 specifiv
<buZz>
specific*
<hramrach>
indeed, it is not
<hramrach>
will try another google dance
<buZz>
s/A10/platform/
<hramrach>
was looking in hte kernel docs only so far iirc
<hramrach>
I see led trigger for CPU activity
<hramrach>
and that's it
<gzamboni>
someone ported the linux led driver for A10
<hramrach>
looks like the LED subsystem is under development still
<hramrach>
you need not port it
<gzamboni>
i saw this week on the sunxi ML
<hramrach>
it's not platform specific
<hramrach>
but the framework has no useful triggers
<hramrach>
in 3.4 at least
<hramrach>
I guess I just update the script for the new driver when I rebuild the kernel
<hramrach>
maybe we get more triggers in 3.8
<hramrach>
and if not then it's time to reinvent more wheels
hg_5 has joined #arm-netbook
<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)
<hansg>
dmesg output should confirm this
<buZz>
hansg: ooo, i thought you added a hack to let 1366 jump to 1360 mode
<buZz>
but i guess i was mistaken :D
<hansg>
buzz, no
<buZz>
ok ty :D
<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
<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.
<hansg>
Patches welcome :)
<buZz>
:P
<buZz>
well its funny, the 1360 mode gets stretched to 1366 on my screen :P
lkcl_ has quit [Ping timeout: 248 seconds]
Quarx|2 has joined #arm-netbook
Quarx has quit [Ping timeout: 256 seconds]
Quarx|2 has quit [Client Quit]
Quarx has joined #arm-netbook
Reepicheep12 has left #arm-netbook ["Leaving"]
penguin42 has joined #arm-netbook
<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
merbzt has joined #arm-netbook
Avernos_ has joined #arm-netbook
Avernos has quit [Ping timeout: 255 seconds]
Alex1269 has quit [Ping timeout: 245 seconds]
hansg has quit [Remote host closed the connection]
<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?
<ithamar>
penguin42: read the source ;)
<ithamar>
penguin42: it is pretty straightforward, but afaik it has only been tested on rk28xx and rk29xx
<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)
<penguin42>
but there again it seems to be sending back the right size data - so it can't be too confused
<ithamar>
offset passed to rkflash(tool) is in blocks, not in bytes iirc
<penguin42>
yeh 512byte blocks
<ithamar>
(havent touched rockchip for months at least so not 100% sure)
<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
<ithamar>
hmmmm
<penguin42>
exactly
<penguin42>
the reboot command works, and the read is returning sane sized data - so not completely dead
<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
<ithamar>
hmmm would not expect that if i hear the results you're getting
<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
<ithamar>
yeah it is pretty straightforward
<ithamar>
I think the issue is more with the parameters then the protocol
<ithamar>
if your read is returning data it suggests that it _thinks_ the command is valid
<penguin42>
yeh, so I'm wondering if it's encoding the address to read wrongly
<penguin42>
lots of people saying they're just patching the uid
<ithamar>
might want to look if they list any of the arguments there, maybe they are doing something "special" with the offsets somehow
<ithamar>
e.g. how to map the mtd offset parameters to the kernel to parameters for rkflashtool
rellla has joined #arm-netbook
<penguin42>
yeh, that's why I've been trying to dump larger chunks assuming I'll hit something interesting
Holo_ has quit [Remote host closed the connection]
Holo_ has joined #arm-netbook
ganbold__ has quit [Remote host closed the connection]
xman has joined #arm-netbook
jukivili has quit [Remote host closed the connection]
jukivili has joined #arm-netbook
techn is now known as Guest85545
gimli has quit [Ping timeout: 256 seconds]
<penguin42>
hmm, the good news is I can write a block and read it
xman has quit [Ping timeout: 272 seconds]
rz2k has quit []
Quarx has quit []
<hno>
ithamar, protocol 1 is used by FEL. Protocol 2 is the protocol handler uploaded over FEL. Both uses the same command structure.
<hno>
process is:
<hno>
1. Device boots in FEL mode.
<hno>
2. Livesuit uploads & executes code for initializing the hardware (DRAM etc).
<hno>
3. Livesuit uploads the flashing application and starts it.
<hno>
3. Flashing application takes over the control. Resets USB and when it returns it's now runnign protocol 2.
<hno>
4. Livesuit communicates with the flashing application using protocol version 2.
<hno>
I only have interest in protocol version 1 as that is what the boot ROM implements.
<hno>
version 2 is all software uploaded to the device by livesuit.
freakazoid0223 has quit [Quit: Leaving]
merbzt has quit [Ping timeout: 240 seconds]
wingrime has joined #arm-netbook
<ithamar>
hno: thanks! I'll include this on the wiki pages I'm going to create
* penguin42
wonders what to do with this 370MB recovery image - I guess split it and put each one back in the appropriate place?
<ithamar>
hno: it does explain why my trace said v2 while the device said v1 using the fel tool ;)
<ithamar>
hno: guess I have spent my time looking at the wrong traces :(
<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."
<L84Supper>
the problem is getting building departments to go along with any changes to traditional building methods
* penguin42
looks at L84Supper
<L84Supper>
soory
<L84Supper>
wrong channel
<penguin42>
now I wonder which one it was for
<L84Supper>
but while I'm here, did people start getti g their cubieboards
<L84Supper>
#reprap
<L84Supper>
I still have to test the interrupt response time on the a10
<L84Supper>
the TI AM335x has a nice Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS)
<L84Supper>
but it's overpriced
<penguin42>
L84Supper: Nothing that can't be fixed with a FIQ routine?
<L84Supper>
maybe, maybe not, some designs just don't care about it
<specing>
Or get a cortex-M micro and interface it
<L84Supper>
with x86 we get <4us latency jitter on irq's with RTAI, <10us with xenomai
<penguin42>
or a dual core and keep one for real time
<penguin42>
what x86 - that's a big range, and some of the BIOSs can just go off and wipe their arse for a while
<L84Supper>
yeah, especially during an SMI event
<penguin42>
nod
<L84Supper>
but with SMI killed or using coreboot it in the few microseconds
<br->
ithamar / hno: where is wiki you guys are using?
<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
<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?
<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
<penguin42>
they're both A8's
<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 ?
<L84Supper>
yes, just not sure how they laid out the fast GPIO and on what bus
<L84Supper>
have to try and see
von_fritz has quit [Quit: vonfritz leaves, don't panic]
xman has joined #arm-netbook
<penguin42>
hmph, that hasn't unbricked it
arete74_ has joined #arm-netbook
hg_5 has quit [Ping timeout: 272 seconds]
arete74 has quit [*.net *.split]
<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
<L84Supper>
running just the machine controller should be similar to the TI, even some arm9 work well enough