Black_Horseman has quit [Quit: Zwi se logou mou!!!]
forcev has quit [Read error: Operation timed out]
eebrah|away is now known as eebrah
eebrah is now known as eebrah|away
FunkyPenguin has joined #linux-sunxi
benn has joined #linux-sunxi
atiti has joined #linux-sunxi
megal0maniac_afk is now known as Guest21502
Guest21502 has quit [Killed (hubbard.freenode.net (Nickname regained by services))]
megal0maniac_afk has joined #linux-sunxi
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
benn has quit [Remote host closed the connection]
zeRez_ is now known as zeRez
n01 has joined #linux-sunxi
eebrah|away is now known as eebrah
BJfreeman has quit [Ping timeout: 252 seconds]
jlj has joined #linux-sunxi
<jlj>
is a special type of serial-to-usb converter needed to get a serial console or would any with RX TX and gnd work?
Tartarus_ has joined #linux-sunxi
<jelly-home>
jlj: you want to pick one that matches the voltage levels for the serial side. RS232 has levels different from TTL has levels different from LVTTL
<jelly-home>
jlj: A10 uses 0V and 3.3V ("LVTTL", I think) so that's the kind of usb-serial adapter you want to use with such a board
<jlj>
jelly-home: thanks. do you know if there is a recommended adapter/one known to work?
<hramrach__>
any 3.3V one should do. there are some available from olimex and the cubieshop
<hno>
alcides, and there is another one in the chineese forumes somewhere..
<alcides>
hno I'll search for this one too...
<wingrime>
Trul: ping
<hno>
alcides, I would start with the first one. It's under review for inclusion and feedback very welcome.
<wingrime>
oliv3r: ping
<wingrime>
hno: do you have uart cable nearly?
<wingrime>
hno: current linux sunxi3.0 not boots when AXP drivers turned off
<alcides>
hno will it be included soon? what is missing?
<hno>
Sort of, but not in a position to play with the boards right now.
<hno>
Feedback from others testing it, and some gentle pushes to have it included.
<wingrime>
hno: I can't figure out why....
<hno>
plus probably one more round of review of the code.
<hno>
What board are you using?
<alcides>
cubieboard
<hno>
also, 3.0 is kind of being deprecated. we are trying to get everyone over to 3.4.
<hno>
is there same problem with staging/sunxi-3.4 branch?
wingrime has quit [Read error: Operation timed out]
<alcides>
[alcides@cubieboard:~]$ uname -a
<alcides>
Linux cubieboard 3.4.43.sun4i+ #30 Fri Jun 7 13:48:08 CEST 2013 armv7l armv7l armv7l GNU/Linux
wingrime has joined #linux-sunxi
<wingrime>
hno: sory for lag
<hno>
wingrime, no problem.
<hno>
where does it halt?
<wingrime>
hno: simply no respone on screen
<wingrime>
hno: it must be in dmesg
<wingrime>
hno: i borrowed my uart (also tablet have no normal pins so in that case I need solder it directly)
<wingrime>
*uart connector
<wingrime>
hno: just try build without AXP in config
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
* hno
is updating his repo. Will take a couple of minutes on current connection.
<hno>
wingrime, which branch are you using?
<wingrime>
hno: 3.0 stable
<wingrime>
hno: I think problem exists not only there
<hno>
wingrime, can you try if same problem is in stage/sunxi-3.0?
<hno>
or stage/sunxi-3.4 preferably. There is not much entergy going into 3.0 these days.
<wingrime>
hno: it will not much helpfull untill I have no uart cable
<hno>
looking at the stage/sunxi-3.0 diff I doubt there is any change there.. no AXP related changes at all.
<wingrime>
hno: just try boot with AXP turned off in config
<wingrime>
hno: I going make mainline axp version, so I need firstly get kernel boot without linux-sunxi driver
<wingrime>
hno: For testing with linux-sunxi I writed small glue that register i2c board (staticly linked) main mfd driver will be tested as module
pacopad has quit [Quit: pacopad]
<hno>
wigyori, so sun5i_defconfig and CONFIG_AW_AXP disabled should be good to test?
<hno>
sorry, wingrime^
<hno>
crap... missing some stuff on this laptop.
wingrime has quit [Ping timeout: 240 seconds]
wingrime has joined #linux-sunxi
<hno>
wingrime, I think you have worse connection than me today.
<wingrime>
hno:indeed
<hno>
* wingrime har avslutat (Ping timeout: 240 seconds)
<hno>
or your client is blocking CTCP PING?
<wingrime>
hno: using irssi
<hno>
wingrime, so sun5i_defconfig and CONFIG_AW_AXP disabled should be good to test?
<wingrime>
yes
<wingrime>
ctcp - I have used it very long time ago... no idea with irssi, but with mIrc worked fine
<hno>
wingrime, your client responds to ping from me at least..
<hno>
hmm... I wonder which of my SD cards actually have a bootable Linux system..
<wingrime>
hno: witch board are you using
<hno>
A13 OLinuxIno at the moment. Only have that and Cubieboard2 with me.
<wingrime>
hno: russa mail so crap. that I still not recived anysing
<wingrime>
hno: any results?
<hno>
wingrime, not so fast... not even power on the board yet.
<hno>
and need to rebuild kernel again.. a misguided rm -rf messed things up a bit..
<oliv3r>
hi, i just made a fex to get me some boot01 uart love for my tablet using the uSD adapter, but all i get is '333333fffffff33333333fffffff'
<oliv3r>
wingrime: pong
<hno>
oliv3r, you haven't disabled the MMC controller.
<oliv3r>
jlj: just cut off the connector, that's what i did
<oliv3r>
ssvb: i did what? i missed hno's quesiton
<hno>
oliv3r, what?
<hno>
oliv3r, this? <ssvb> hno: afaik oliv3r tried to do more detailed comparison between the boot0 and u-boot dram settings
<oliv3r>
ssvb: but if it's about boot0 from a20 dump and what's in hno's repo right now, then yes, my github should be slightyl more complete, but worse tested ;)
<oliv3r>
you need my patches if you want performance that is on par
<hno>
I asked if the register differences had been mapped out I think.
bamvor has quit [Ping timeout: 240 seconds]
<hno>
oliv3r, are you stuck in scrollback mode?
bamvor has joined #linux-sunxi
<oliv3r>
hno: i did too! but i'll check again
<oliv3r>
[mmc0_para]
<oliv3r>
sdc_used = 0
<oliv3r>
hno: yes i was backreading
<hno>
oliv3r, the boot one as well?
alcides has quit [Remote host closed the connection]
<hno>
wingrime, not too odd my script.bin makes disp choke.. lcd_bl_en = port:power1<1><0><default><1>
<hno>
lcd_power = port:power0<1><0><default><1>
<hno>
those are AXP pins.
<hno>
wingrime, yours have the same.
<hno>
and not very odd there is nothing on the LCD is it's neither powered or enabled.
<hno>
backlight enabled..
<oliv3r>
hno: my tablet has a pin-hole 'reset' button; what is it for? force to fel-mode?
<wingrime>
olive3r: do RESET ]
<hno>
oliv3r, usually.
<oliv3r>
i may have just killed my tablet; and i have no clue how
<oliv3r>
all i did was 'reboot' from within android
<oliv3r>
i did the 10 second button thing
<oliv3r>
but lsusb doesn't even show it
<oliv3r>
i get absolutly nothing from the device
<hno>
oliv3r, what do the manual say about that hole?
<oliv3r>
manual?
<oliv3r>
lol
<oliv3r>
i'll check the box
<oliv3r>
i might still have it
<wingrime>
oliv3r: just find situable image for livesuit
<hno>
push power button for at least 12 seconds.
<hno>
then release it, wait a moment, and push it again for ~2 seconds.
<oliv3r>
yeah; tried that a few times :S
<oliv3r>
oh i heard a speaker sound pop after 3 seconds
<oliv3r>
maybe it's not entirly dead
<oliv3r>
battery could be thoug
<oliv3r>
yeah the axp reset trick makes the speaker pop
<hno>
plug in the charger?
<oliv3r>
i have otg plugged
<hno>
wingrime, are you really sure your doesn't boot?
<oliv3r>
manual says 'when a problem occurs, press soft reset via pinhole'
<wingrime>
hno: can't say defenetly untill no uart connected
<wingrime>
hno: but I tryed not once
<hno>
wingrime, any other methods for sign of life than display? Does it show up on USB?
<wingrime>
hno: it not boots in cases 1) no axp 2) with axp + glue driver that register i2c board
<oliv3r>
what about corrupted nanda partition
<hno>
wingrime, display will be completely off on that hardware until you have AXP GPIO driver.
<hno>
oliv3r, try booting from an SD card.
<oliv3r>
aye, checking my sd card now :)
<oliv3r>
but corrupted nanda (e.g. fsck fail) won't force FEL mode
<wingrime>
hno: will try agian tomorrow , otherwice get uart cable and check
<hno>
oliv3r, in many cases not.
<oliv3r>
good
<oliv3r>
i had nanda mounted during reboot
<hno>
oliv3r, it
<hno>
it's a FAT so quite hard to crash that bad..
<oliv3r>
true, but i don't know what else :)
<wingrime>
hno: if I connect some nand signals together will a10 boot to fex?
<hno>
and there is two copies of script.bin in case one gets corrupted..
<hno>
wingrime, yes. But easier to use a FEL SD card.
<oliv3r>
found my fedora 18 sd card
<hno>
only used the "short some otherwise unused NAND signals" to force MMC2 boot on my Cubieboard modified with MMC2.
<oliv3r>
mmc boots
<oliv3r>
sweet
<oliv3r>
while i'm no big fedora fan (not opposed in anyway either); i do love a) the simplicity of his install; and the fact it 'just works'
<oliv3r>
thank you hansg
<wingrime>
hno: mmc2 ~after~ nand in boot order?
<hno>
yes
<oliv3r>
no corrupted partitions :(
<hno>
oliv3r, SD boot failed?
<wingrime>
oliv3r: fex
<oliv3r>
sd boot works fine
<oliv3r>
but i've booted that fex before fine
<oliv3r>
i'll restore original
<oliv3r>
ohhhh
<oliv3r>
fuck me
<oliv3r>
i deleted the fex to replace it with a diff one
<oliv3r>
but then wifi failed again, so i rebooted to fix wifi; but no fex :)
<hno>
There, corrupted nanda content :)
<oliv3r>
lol :)
<oliv3r>
wingrime: +10 points; golden tip :)
<hno>
but... there is two copies. boot1 should have found the backup...
<oliv3r>
i removed both :)
<hno>
don't do that again :)
<oliv3r>
i have the .orig left
<oliv3r>
i made a copy before starting to mess with those :)
<oliv3r>
rm; scp script.bin .
<oliv3r>
but then wifi wasn't up
<hno>
next time leave the backup alone... always.
<hno>
just replace script.bin. no need to rm before scp.
wingrime has quit [Ping timeout: 260 seconds]
<hno>
there is many ways a file update on FAT can screw up, but very unlikely a file you haven't touched will get screwed up as well.
<oliv3r>
well wanted to make sure the backup was the same as the normal one
<hno>
you do that after booting the normal one.
<hno>
if at all.
<oliv3r>
i guess; lesson learned :)
<oliv3r>
hno: before i forget, you didn't answer before; the pull request for marsboard a10
<oliv3r>
the data is identical to cubieboard; but it's a 'name' thing
<hno>
haven't seen it
<oliv3r>
today or yesterday
<hno>
haven't been able to keep up with the email flow at all.
<oliv3r>
no problem
<oliv3r>
on linux-sunxi i tried to answer/close most issues
<hno>
good.
<hno>
but my anser is that I do not really care if there is duplicate DRAM parameter files.
<oliv3r>
so merge it then
<oliv3r>
roger
rellla has joined #linux-sunxi
<oliv3r>
if you haven't done it; i'll do it later/tomorrow
<oliv3r>
haven't quite figured out how to nicely merge things via github, not very happy with the double log entries it creates (1 for the patch, 1 empty for the merge)
<hno>
please do. takes at least 2 min to open up github here.
<oliv3r>
ack
<hno>
don't worry too much about the merge commit. it's normal.
<hno>
git works that way.
<oliv3r>
i find them pollutingly ugly :p
<oliv3r>
so i just download it as a .patch (by appending .patch to the url) and submit it that way
<hno>
that work too, but records a different hash for the merged commit.
<hno>
so history tracking gets a little lost.
<oliv3r>
ohh
<hno>
doesn't matter on leaf merges like this.
<oliv3r>
well what i did for a diff branch (probably does the same hash mess then) is merge, pull locally, remove the 'merge' commit; and push -force
<oliv3r>
ok i'll leave it in as it is
<hno>
How did you remove the merge commit? If you do that then you are back where you started.
<oliv3r>
well i pulled 2 commits; the patch and an empty 'merge' commit
<oliv3r>
so i just did a reset to the one before; and push -force it
<oliv3r>
maybe i shouldn't do crazy shit when I don't know what i'm doing :)
<hno>
Yes, but the parent of the merge commit is the previous version before merge, and the merged commit.
<oliv3r>
maybe they did it wrong?
<oliv3r>
a 'pull request' always results in 2 commits (or more) does it not?
<hno>
sounds so.
<hno>
depends on if the merge can be fast-forwarded or not.
<hno>
a merge that can be fast-forwarded can result in just one commit.
<hno>
(the original one) with no sign of who merged it.
<oliv3r>
hmm, maybe they did it wrong, people on github tend to know even less then I do
<hno>
or you can opt to always use a merge commit, to keep a record of when the merge happened and by who.
<oliv3r>
how are you enjoying your vacation so far btw?
<oliv3r>
but still get 'ffff333333fffff33333fff333
<hno>
The vacation is very good thanks, but the cough is back for the last days, very annoying, Need to go and see a doctor about that when I get back I think.
<hno>
oliv3r, view the merge commit as a branch point. From that to the common ancestor there is two independent branches. If you reset to a hash on one then the commits on the other is lost.
<hno>
if the common ancestor was the previous HEAD then all is fine.
<oliv3r>
it was, but yeah
<hno>
and the merge could have been fast-forwarded without the merge commit instead of merged.
<oliv3r>
these dtv patches are all simple patches anyway, all based off of the same root
<oliv3r>
so nothing major really
<oliv3r>
sorry to take more of your (ill) time, but do you spot anything strange here? http://sprunge.us/QGWX
<oliv3r>
'card burn para' is still pf0*
<oliv3r>
i'll change that too
utente has joined #linux-sunxi
focus_it has quit [Quit: Leaving]
<oliv3r>
same, 333ffff3333ffff33333 :S
<oliv3r>
i just changed the pf* to pc* (copied the numbers from sd2 i think) but no usd debug :(
<hno>
oliv3r, no idea. looks fine to me, but I never really do this myself. From what I have understood you normally flash a debug image to enable SD UART + JTAG.
<oliv3r>
ah ok
<hno>
which gives a boot0 which sets up the uart + jtag very early.
<techn__>
oliv3r: for me it worked well
<oliv3r>
well turl did say you would know which branch i had to use for 'lichee u-boot'
<oliv3r>
uart u-boot is 'fine' for me
<hno>
techn__, replacing script.bin, or a full flash?
<techn__>
hno: you need to create livesuit image with that new script.bin
<hno>
oliv3r ^
<oliv3r>
seriosuly?
<oliv3r>
i'll do the 'special u-boot that forces uart' trick
<techn__>
oliv3r: you need to have boot0 and boot1 mmc disabled too :/
<oliv3r>
yeah i did disable mmc
<oliv3r>
in my script.bi
<hno>
not really.. those will just give some garbage before...
<oliv3r>
my goal is to debug the booting (or failure to do so) of the kernel
<oliv3r>
so u-boot + kernel early printk is plenty for me
<techn__>
oliv3r: there is another script.bin stored in nand .. it's raw somewhere
<techn__>
hmm
<oliv3r>
i'm starting to have my doubts wether boot1 can parse script.bin at all :p
<oliv3r>
boot0 won't, livesuit takes script.bin and modifies boot0
<oliv3r>
boot1 i'm thinking the same
<hno>
boot1 reads script.bin.
<hno>
at least the boot1 versions I have seen.
<hno>
and is also why it crashed for you...
<hno>
nothing else reads script.bin in the boot process any more.
<hno>
earlier boot1 read script.bin a second time when selecting the image to boot (u-boot) and then u-boot loaded script.bin yet again.. but now it's just loaded once.
<oliv3r>
boot.axf?
<techn__>
oliv3r: you can check livesuit contents with ithamars awutils .. there is one "partition" for second scrpt.bin
<oliv3r>
yeah, that's true
<oliv3r>
i extracted (and uploaded to sunxi-bin) those details ages ago
<oliv3r>
i think i put info about that on the wiki too
<techn__>
oliv3r: you can try to modify just that .fex file and use "make livesuit" .. ;)
<oliv3r>
and how do i use livesuit image?
<oliv3r>
don't I need windows for that?
<hno>
I think that's for livesuit usage. It needs script.bin to seed boot0 & boot1 boot header parameters.
<hno>
and to configure the board for flashing,
<techn__>
oliv3r: oh.. and you need to modify that lichee-dev u-boot to be sduart capable
<oliv3r>
i think i'll only do that bit techn__ :)
<techn__>
oliv3r: I think fastest way would be to use sduart is fel-boot
<techn__>
skip whole livesuit sh*t
<oliv3r>
what?
<hno>
fel booting is nice, but not so android friendly.
bsdfox_ has joined #linux-sunxi
bsdfox_ has joined #linux-sunxi
<techn__>
hno: I booted android with fel boot :)
<hno>
yes, possible, but different..
<oliv3r>
the android that resides on flash? :)
<techn__>
oliv3r: yes
<oliv3r>
oh nice
<oliv3r>
what u-boot did you use?
<hno>
fel booting can boot anything.
<oliv3r>
techn__: could you do a howto for the wiki?
<oliv3r>
i'll try to follow it
<techn__>
oliv3r: I was planning to push BSP changes.. but have been busy (and ill)