<libv>
hrm, no usb under android with my semitime g2
<wens>
Turl: yay
<wens>
means i can start sending patches
TheSeven has quit [Ping timeout: 260 seconds]
TheSeven has joined #linux-sunxi
akaizen_ has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
pwhalen has quit [Ping timeout: 244 seconds]
FR^2 has quit [Ping timeout: 272 seconds]
akaizen has quit [Ping timeout: 240 seconds]
pwhalen has joined #linux-sunxi
FR^2 has joined #linux-sunxi
FreezingCold has quit [Quit: Out]
FreezingCold has joined #linux-sunxi
<libv>
un-be-liev-able.
<libv>
openwrt has only gotten worse over the years
<libv>
flaky wifi due to a bad driver is one thing... but... because it doesn't do proper change management anymore (which also means that most of your network stack gets restarted pretty much anything is changed - yes, dsl disconnects when you change wifi stuff...), and you just happen to lose the passphrase because it didn't fully make it through when you submitted...
<libv>
then the other ssid also gets disabled.
<libv>
great.
<libv>
but... now i had an even better one
<libv>
assign the same ip twice and whoops, there goes dhcp altogether!
<libv>
you better know your network well if you want to recover from that one
<libv>
i don't know what supposedly was improved in the last decade
<libv>
but the above three things definitely haven't improved
<libv>
we did see a lot of churn though.
<libv>
this is probably what open source software is about
<libv>
you never care about the result, you never care about delivering something for others to actually use
<libv>
all you should care for is your own programming fun, and hopefully acting important at conferences, and for that, churn is what you want above all
diego71 has quit [Ping timeout: 255 seconds]
diego71 has joined #linux-sunxi
ganbold__ has quit [Remote host closed the connection]
FreezingCold has quit [Ping timeout: 240 seconds]
Faisal has quit [Quit: No Ping reply in 180 seconds.]
Faisal has joined #linux-sunxi
FreezingCold has joined #linux-sunxi
Faisal has quit [Quit: No Ping reply in 180 seconds.]
Faisal has joined #linux-sunxi
ecelis has quit [Ping timeout: 264 seconds]
ecelis has joined #linux-sunxi
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
bengal has quit [Remote host closed the connection]
bengal has joined #linux-sunxi
libcg has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 250 seconds]
pwhalen has quit [Ping timeout: 260 seconds]
libv_ is now known as libv
pwhalen has joined #linux-sunxi
popolon has joined #linux-sunxi
popolon has joined #linux-sunxi
libcg has quit [Ping timeout: 240 seconds]
Renard has joined #linux-sunxi
<paulk-collins>
blimey, my images built in the android tree won't boot!
<paulk-collins>
U-Boot says "resetting ..." after "Starting kernel ..."
<paulk-collins>
I would assume the image doesn't even run
bengal has quit [Remote host closed the connection]
bengal has joined #linux-sunxi
afaerber_ has joined #linux-sunxi
dlan has quit [Ping timeout: 240 seconds]
afaerber has quit [Ping timeout: 272 seconds]
dlan has joined #linux-sunxi
afaerber_ is now known as afaerber
libcg has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 255 seconds]
mawe242 has quit [Ping timeout: 240 seconds]
zeRez has quit []
quitte has joined #linux-sunxi
<quitte>
bbrezillon: out of lazyness I'll ask despite knowing I should have a look myself first. Your patches appliede except for number 4, which was for some reason previously applied and the dts related ones. Now I'm getting this:
<quitte>
drivers/mtd/nand/nand_hynix.c:35:33: error: 'struct nand_chip' has no member named 'manuf_priv' struct hynix_nand *hynix = chip->manuf_priv;
<quitte>
and similar errors
ddc has joined #linux-sunxi
<wens>
mripard_: any plans about relicensing the dts? i have another i want to send, a sun5i tablet
<bbrezillon>
quitte: and you told me you wanted to stay on the v3 series, hence I sent you patches from my sunxi-nand branch
<quitte>
thanks. I'll add that instead of 5c7f446 then?
<quitte>
bbrezillon: I did not tell you that. I want to stay on kernel 3.13. at least for now.
<bbrezillon>
quitte: you can try to apply pre-v4-fixed, but I'm not sure it applies cleany (and you might miss some commits introduced between 3.13 and 3.16)
<quitte>
bbrezillon: what does V4 and V3 mean? it seems it doesn not simply mean one is the successor of the other
<ddc>
quitte: openwrt build system is not that complicated you can switch to 3.16 without any issues
<ddc>
You should be able to use bbrezilon repo with the build system
<quitte>
ddc: probably will. what I'm most interested in is not patcehd into it anyways
<quitte>
(dma for ethernet,sata,mmc and nand)
<bbrezillon>
quitte: vX, vX+1, ... are the version submitted to the community each version in addressing comments made on the previous one, and each version in based on the latest available kernel
<bbrezillon>
quitte: I can help you get one version working, but I certainly won't backport a given version of the patch series to an older kernel version
<ddc>
If those didn't make it to the mainline you can rebase/apply them
<quitte>
bbrezillon: how is what you sent me different from a backport?
<bbrezillon>
ddc: yep, but some patches have been accepted, and some of my patches are modifying nand core code, and resolving conflicts on these parts is kind of tricky.
<bbrezillon>
quitte: I simply took my sunxi-nand branch and launched a git format-patch <first-commit>..HEAD
<bbrezillon>
quitte: I don't remember on which branch I based my work, but it seems close enough to 3.13 to apply cleanly
<ddc>
My comment was directed to quitte about the patches for ethernet, sata
<bbrezillon>
ddc: oh, okay, sorry
<quitte>
which branch should i pick if i wanted to follow what might become mainline? which one to get allt he latest prototypes?
<bbrezillon>
pre-v4-fixed is the latest and I'll submit part of it soon (still have some fixes to add)
wingrime has joined #linux-sunxi
<ddc>
bbrezilion: regarding bb I've tried smaller partition size for the Samsung and it seems to save the bb on reboot
<ddc>
I've managed to get a hold of cubieboard2. and it has different bad blocks
<bbrezillon>
ddc: okay, have you tried the on flash BBT thing
<bbrezillon>
?
<ddc>
Not yet that in my todo list for tomorrow
<bbrezillon>
okay, I'll double check the value you've set for the last partition
<bbrezillon>
but AFAIR it was correct
<ddc>
I've setup 5 portions and 4 of the bb reside on the smaller portions and the all recognised by the scan process on boot
<ddc>
Over all the nand contains 6 bad blocks
<bbrezillon>
ddc: which seems correct given the previous logs you've provided
<ddc>
But the scan process still not picking up the other two. Which live in the larger partition
<ddc>
during boot up
<bbrezillon>
ddc: are all partitions (except boot0 and boot0-recovery) defined with the same ECC and RNDizer mode ?
<ddc>
Mmm. I cannot remember from the top of my head. I will check it tomorrow and send u some outputs
<Turl>
libv, I never had my WAN go down when I "wifi up"
<Turl>
libv, there's fallback mode for when you hose it like that :)
<libv>
Turl: openwrt lost it along the way :(
<Turl>
mawe242, it's less error prone because it's always 32 bits, just like the registers. int and friends may vary
<Turl>
libv, I'm quite happy with how openwrt works tbh
<Turl>
their v6 support is great
<libv>
Turl: try feeding it 2 the same ip addresses :p
<Turl>
on where?
<libv>
dhcp hosts
<Turl>
on the lan?
<libv>
yup
<Turl>
that'll break no matter the platform
<libv>
no, it should not
<Turl>
if dnsmasq gets hosed because of that, file a bug
<libv>
either the ui catches that
<libv>
or dnsmasq should either catch or work around that
<libv>
it just throws in the towel.
<Turl>
but even if it didnt the host wouldnt work
<libv>
why not?
<libv>
the first of the macs gets the ip
<libv>
the other gets a random one
<libv>
whichever gets the lease first
<Turl>
if both get the ip it breaks
<libv>
how can that happen?
<libv>
there's one dhcp server in the network
<Turl>
fixed ip?
<libv>
yes
<libv>
but the dhcp server hands them out
<Turl>
usually when you do that its to reserve the ip because its fixed
<Turl>
on the host config
<libv>
that's besides the point
<Turl>
indeed
<libv>
dnsmasq should be smarter about it
<libv>
or
<Turl>
file a bug :)
<libv>
openwrt should be smarter about it
<libv>
there are bugs
<libv>
no-one cares.
<Turl>
its certainly low prio
<libv>
well, if you're dealing with a lot of machines, and you like them to be pingable over a lot of installations, you quickly add a lot of devices to the list
<libv>
people will run into this
<libv>
and many will not know a way out apart from flashing again
<Turl>
you can ping hostname.lan :)
<libv>
it's one of those amazingly simple stupid things
<libv>
not if you're no longer getting a dhcp lease
<Turl>
failsafe is well documented
<libv>
which is great, if you can reach the document
<libv>
it shouldn't happen, period.
<libv>
same thing for when the passphrase got messed up
<Turl>
huh
<Turl>
what happened to it?
<libv>
it shouldn't happen, period, but if it does, it shouldn't bring both networks down
<libv>
i think i described that
<libv>
flaky wifi due to ath9k being very unstable (still!)
<libv>
2 networks, one normal, one guest
<libv>
i switched channels
<Turl>
it was bad a couple of years ago, but I havent had issues for a year or two
<libv>
the stupid "let's update all configuration at once" scheme modern openwrt seems to do, that didn't complete for some reason
<Turl>
with two month uptimes
<libv>
and the passphrase for the guest network was just gone
<libv>
as a result, both the main and the guest wlan were stopped
<Turl>
i used to have the failed dma bug
<libv>
well, i was cocky after getting an updated kernel, and turned N on again
<libv>
reboot was required to right the problem again
<Turl>
its probably not the passphrase but a bad channel
<libv>
no, the passphrase issue happened last week
<Turl>
if you choose a bad channel/ht config it wont come up
<libv>
the log said "no passphrase, goodbye"
<libv>
and i got neither ssids working
<Turl>
heh
<quitte>
bbrezillon: do you know if your linux-sunxi branch builds?
<libv>
while the passphrase only vanished on the guest
<libv>
Turl: when these sort of things seem to amass themselves...
<libv>
there is something fundamentally wrong.
<Turl>
libv, maybe you should move to gargoyle
<libv>
i don't want to move, i want this to work.
<libv>
without me finding utter stupidity all over the place
<libv>
it's like networkmanager, and pulseaudio and systemd
<libv>
people just rework/reinvent all the time, but they never fix the issues that actually make life harder for people who just want to get other stuff done
<Turl>
pebkac prevention :p
<Turl>
bbl
<libv>
with the passphrase disappearing?
<libv>
the second was pebkac, yes, but still
<libv>
oh, i switched channels when the passphrase vanished btw
<quitte>
bbrezillon: never mind. just got to find the patch ...
netlynx has quit [Quit: Leaving]
rz2k has quit [Read error: Connection reset by peer]
<bbrezillon>
quitte: I don't have any linux-sunxi branch, though I have a linux-sunxi repo, and you should find the different branch we were talking about earlier
<ah>
quitte: but you should probably avoid hand-editing patches like that.... apply them, do your changes and diff again instead.
<quitte>
ah: in that case it's a perfectly good solution
sehraf has quit [Client Quit]
sehraf has joined #linux-sunxi
mawe242 has joined #linux-sunxi
sehraf has quit [Client Quit]
mawe242 has quit [Remote host closed the connection]
sehraf has joined #linux-sunxi
pwhalen has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
skoperst has joined #linux-sunxi
<skoperst>
hi
<Nyuutwo>
hi
<skoperst>
how's it going?
<skoperst>
well.. I got the pucduino8 which is A80 board
<skoperst>
and was wondering how should I start into compiling the kernel. First I cant seem to find it anywhere in github, secondly I dont know what the status about mainline kernel and sunxi support, should I try to use that?
<skoperst>
Annndd.. What about the DTS for my board? where should I look for it?
<mripard_>
skoperst: there's no support at all for the A80, and we don't have any documentation
<mripard_>
so I don't really know to what degree you can rely on what's been done so far
<mripard_>
so I guess the f
<Nyuutwo>
skoperst: do you have ever modified kernel?
<skoperst>
Nyuutwo: Yes I did, developed a few drivers. and modified quite some kernel. But. only Android kernels
<mripard_>
*safest would be to start as if you were porting Linux on a new SoC
<mripard_>
is there some A80 code somewhere already?
<skoperst>
I can ask for the board manufacturer(pcduino) to release me the code. But is it the right thing to do? I mean isnt it better if it was a repository for all a80 boards?
<Nyuutwo>
mripard_: on wiki there is dead link to github
<skoperst>
mripard_: I couldnt find any sources online
<mripard_>
skoperst: eventually, yes, but we have to start somewhere :)
<mripard_>
ok
<skoperst>
Do you know if its possible to compile android kernel from mainline kernel? or its unreal?
<mripard_>
as a general question, it is
<mripard_>
in sunxi case, it's not
<skoperst>
why?(if its not too long explanation)
bertrik has quit [Remote host closed the connection]
<mripard_>
we're missing quite a few things that Android rely on
<Nyuutwo>
mainline just now gets some kind of framebuffer support
<mripard_>
most notably a graphic driver
akaizen has quit [Remote host closed the connection]
<skoperst>
I see(thought not completley know what its about)
<mripard_>
it's about displaying stuff on a screen :)
<mripard_>
and, in the A80 case
<mripard_>
they probably changed quite a few things in there
<quitte>
bbrezillon: nand was found. badblocks identified. now it's waiting for the rootfs and has never identified the mtd partitions
<mripard_>
so you can't just re-use what we done so far
<mripard_>
even though, it's very likely it's close to the A31 that is pretty well supported already
<Nyuutwo>
mripard_: A31 is supported by 3.4?
<quitte>
boots from mmc, though
<mripard_>
Nyuutwo: no.
<mripard_>
only in mainline
<quitte>
bbrezillon: the mtd partitions appear in /dev. but the 6th autogenerated one isn't there anymore
<mripard_>
but it's what we were talking about :)
<skoperst>
from my experience framebuffer driver + GPU driver + all the proprietary HAL hell.. is messy and unique for each SoC manuf.
ricardocrudo has joined #linux-sunxi
<quitte>
...and no eGON in the spl dump
<quitte>
ugh. no mtd6 could be normal ....
<skoperst>
But that was for older devices, maybe today its different
<mripard_>
not really
<mripard_>
but the HAL is in userspace
<mripard_>
and the GPU driver is still optional iirc
<skoperst>
what do you mean optional? slow as f* is not an option imho
<mripard_>
(and some SoC have an open-source GPU driver that is in mainline kernel and mesa)
<skoperst>
who is that?
<mripard_>
we're far from being that lucky though....
<mripard_>
tegra k1, intel atoms
<skoperst>
i guess qcom/mtk is not one of them
<mripard_>
iirc the latest qcom too
<skoperst>
iirc=?
<skoperst>
ah ok
<skoperst>
;)
<mripard_>
but I'm unsure about this one
<skoperst>
another small question, do you know if sunxi still using the FEX files? i really hate those
<skoperst>
oh man.. all the kernel filled with strcmps for that
<skoperst>
I started developing kernel when they didnt use DTS, so easy and fun to use config
<skoperst>
and board.c files
<skoperst>
for me FEX was a mess, And i want to learn about DTS files so this is not helping.
<skoperst>
Specially when FEX is mutually exclusive with the DTS if i understand correctly
<mripard_>
yep
<mripard_>
but if you want to learn something, you'd better go for DT
<mripard_>
at least it's useful for other SoCs and even other arch's
<skoperst>
Yes i saw some devices with it but never had the chance to compile a kernel and play with it.. thanks for the advise
akaizen has joined #linux-sunxi
physis has quit [Remote host closed the connection]
ricardocrudo has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
FR^2 has quit [Quit: Leaving]
skoperst has quit [Ping timeout: 246 seconds]
<paulk-collins>
how come the wiki page for tzx-q8-713b tells to use the A13_MID u-boot config while its dram config doesn't mach what's the the board's actual script.fex?
<paulk-collins>
what's in the*
bengal has quit [Ping timeout: 255 seconds]
Renard has joined #linux-sunxi
tonyctl has joined #linux-sunxi
tonyctl has left #linux-sunxi [#linux-sunxi]
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
libcg has quit [Remote host closed the connection]
akaizen_ has joined #linux-sunxi
akaizen has quit [Ping timeout: 240 seconds]
Zboonet has quit [Remote host closed the connection]
Gerwin_J has quit [Quit: Gerwin_J]
ricardocrudo has quit [Remote host closed the connection]