Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
tkaiser has joined #linux-sunxi
tgaz has quit [Ping timeout: 250 seconds]
tkaiser has quit [Ping timeout: 244 seconds]
orly_owl_ has joined #linux-sunxi
pmattern has quit [Quit: Genug für heute.]
orly_owl has quit [Ping timeout: 240 seconds]
ssvb has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
kaspter has joined #linux-sunxi
Andy-D_ has joined #linux-sunxi
Andy-D has quit [Ping timeout: 272 seconds]
jrg has quit [Ping timeout: 250 seconds]
orly_owl_ has quit [Quit: leaving]
orly_owl has joined #linux-sunxi
kaspter has quit [Ping timeout: 276 seconds]
tgaz has joined #linux-sunxi
ganbold has joined #linux-sunxi
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 250 seconds]
ninolein has joined #linux-sunxi
ninolein_ has quit [Ping timeout: 272 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 264 seconds]
<wens> got my codec, though i still need to get some wires
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 276 seconds]
jrg has joined #linux-sunxi
<jrg> nice
<jrg> it hung again
luoyi has joined #linux-sunxi
<jrg> seems unstable at 1.61 as well. i'm trying 1.2GHz now
<jrg> ran for quite some time tho
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 244 seconds]
vagrantc has quit [Quit: leaving]
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 is now known as cnxsoft
IgorPec has joined #linux-sunxi
tkaiser has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
reev has joined #linux-sunxi
reev has quit [Max SendQ exceeded]
reev has joined #linux-sunxi
tkaiser has quit [Ping timeout: 252 seconds]
zuikis has joined #linux-sunxi
<luoyi> wens: does this version dts file make you feel better ? https://github.com/luoyi/linux-sunxi/commit/aa454e63049c6ed64fa9447977355b823b867100
Andy-D_ has quit [Ping timeout: 258 seconds]
tkaiser has joined #linux-sunxi
zuikis has left #linux-sunxi [#linux-sunxi]
JohnDoe_71Rus has joined #linux-sunxi
Akagi201 has joined #linux-sunxi
luoyi_ has joined #linux-sunxi
luoyi has quit [Ping timeout: 250 seconds]
Andy-D_ has joined #linux-sunxi
<wens> sigh, i2s pinouts on bpi-m1+ aren't the same as rpi 2
<luoyi_> yes
reinforce has joined #linux-sunxi
<luoyi_> and bpi-m1+ have a mclk output pin
<luoyi_> and I've just got a new CS4334 DAC board. can't get it work. still don't know the reason.
staplr has quit [Quit: Konversation terminated!]
<wens> sigh again, the cubies don't have i2s on the pins :(
<luoyi_> I've heared that cubietrunk can get i2s out with some hardware modify
<luoyi_> but maybe it's too hard for me. so I choose to use bpi m1+
paulk-collins has joined #linux-sunxi
<wens> correct, cubietruck i2s is by default connected to the bt module, but with a soldering iron you can change it to be on the pins
<wens> i don't know if it would break the bt pcm connection though
<wens> and i prefer not having to modify my boards
<luoyi_> the resistors on the cubietrunk which needed to be modified is so small
<luoyi_> I've looked at it, and give up
<luoyi_> wens: how do you think of the new version of the bpi m1+ dts file? I've changed spi/uart function to defautl disable. does it suitable for a formal mail review ?
<wens> remove them completely, otherwise the dts gets bloated
<luoyi_> OK
<luoyi_> can I reserve the spdif section ?
<orly_owl> is there a community for amlogic socs? it seems amlogic actually released all their source code, so odroid-c2 is looking like a good board
<wens> is it a dedicated pin or connected? if not, then no
<wens> orly_owl: head over to #linux-amlogic
<orly_owl> thanks
massi has joined #linux-sunxi
<luoyi_> it's a clean version based on your advise
codekipper has joined #linux-sunxi
<codekipper> luoyi_: I would move the codec label so that it's in alphabetical order(and add a newline either side of it)
<codekipper> the commit message is pretty important but you can get an idea of the other boards that have been commit on what (and where) to write
<codekipper> what's wrong with the other DAC?...
<luoyi_> codekipper: DAC ?
<codekipper> you mentioned you couldn't get the CS4334 to work
<luoyi_> yes. I've bought a CS4334 DAC board, https://item.taobao.com/item.htm?id=43821462615 . but can get it work right. it just keep silent
<luoyi_> s/can/can't/g;
<luoyi_> I think CS4334 can receive the same format i2s signal just as PCM5102
<luoyi_> my sound file is 24Bit/96KHz
<luoyi_> 24Bit/48KHz
<luoyi_> codekipper: you mean the commit message format just like 'ARM: dts: am335x-bone*: add DT for BeagleBone Black '
merbanan has joined #linux-sunxi
<luoyi_> codekipper: do you think https://github.com/luoyi/linux-sunxi/commit/f79f5512631fa24397adae5c60451fbd246d4702 this commit message is OK ?
Akagi201_ has joined #linux-sunxi
Akagi201 has quit [Read error: Connection reset by peer]
matthias_bgg has joined #linux-sunxi
premoboss has joined #linux-sunxi
premoboss has quit [Client Quit]
klarrt has quit [Ping timeout: 240 seconds]
andoma has quit [Ping timeout: 240 seconds]
andoma has joined #linux-sunxi
klarrt has joined #linux-sunxi
arete74 has quit [Quit: leaving]
arete74 has joined #linux-sunxi
<Amit_T> wens: Hello, this particular commit in u-boot b733c278d7adc48c71bd06faf359db3d9e385185 breaks my changes done for H3 emac , I think its not appropriate for SoCs which have internal PHY.
<plaes> Amit_T: better complain at u-boot list
<Amit_T> plaes: ok, I post it at u-boot channel, sorry for inconvenience.
libv_ is now known as libv
<plaes> no problem :)
<codekipper> luoyi_: you need to squash all the patches together, remove the weblink and add a signoff
luoyi_ is now known as luoyi
<codekipper> luoyi: as for the DAC, try forcing the LRSync to be 32bits
<luoyi> codekipper: you mean the mail content , right ?
<luoyi> codekipper: LRSync is in which registor ?
IgorPec has quit [Ping timeout: 272 seconds]
ganbold has quit [Quit: This computer has gone to sleep]
akaWolf has quit [Ping timeout: 240 seconds]
akaWolf has joined #linux-sunxi
<luoyi> you mean Word Select Size ?
diego_r has joined #linux-sunxi
vickycq has quit [Ping timeout: 264 seconds]
joedj has quit [Ping timeout: 264 seconds]
vickycq has joined #linux-sunxi
<codekipper> that's the baby......we found that the WSS needed to be 32bits..let me find a patch
<codekipper> talking off patches it's probably easier to generate a patch locally and copy that to pastebin then using github.
joedj has joined #linux-sunxi
<luoyi> change the wss then we need to change the mclkdiv/bclkdiv ?
<codekipper> this is my latest sun4i-dai.c http://pastebin.com/GQN8uqWp
<codekipper> I haven't tested my PCM5102 yet...so can't say that it will work
yann|work has quit [Ping timeout: 260 seconds]
<luoyi> with my driver , PCM5102 is work right
<luoyi> and I still can't understand your algorithm calc the mclkdiv/bclkdiv
<codekipper> but someone else saw the same issue when they were connecting to their resampler(can't find the product name)
<codekipper> what don't you understand?
<luoyi> https://github.com/luoyi/Sunxi-A20-Audio-Driver/blob/master/sun4i-dai/sun4i-dai.c this is my i2s driver code. and you can check the calc_bclk_mclk function
<luoyi> I'll first try your driver and then modify my driver force to use 32bit wss, and hope one way can work right
<codekipper> where did the divs come from?..not the A20 User Manual
<luoyi> they just come from A20 User Manual
<luoyi> codekipper: you can check my note about the calc of bclkdiv and mclkdiv
<codekipper> that doesn't match the MCLK AND BCLK section in the user manual
<luoyi> the figure in the webpage is just a screenshot of the user manual .
<luoyi> what's your mean of doesn't match ?
<codekipper> the last section of the dai part of the document lists the mclk and bclk settings based on the sampling rate(we chose the highest oversampling rate)
apvh has quit [Ping timeout: 264 seconds]
avph has joined #linux-sunxi
IgorPec has joined #linux-sunxi
kaspter has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
<wens> i got my BPI M2+
jrg has quit [Ping timeout: 264 seconds]
WB6ALX has quit [Read error: Connection reset by peer]
WB6ALX has joined #linux-sunxi
<wens> jemk: are you going to upstream the dts?
<Amit_T> Its costly compared to pine64
alexxy has quit [Quit: No Ping reply in 180 seconds.]
jrg has joined #linux-sunxi
alexxy has joined #linux-sunxi
<wens> 40 USD free shipping
<plaes> o_O
<wens> pine64 was 15 USD + 20 USD shipping? and they might even raise the price later?
<wens> plaes: found on aliexpress, not the one i got
<plaes> ah.. I read that free shipping was 40USD :D
<KotCzarny> my opi+2e will arrive today! woo-hoo
<wens> plaes: then you probably get the board for free :p
<MoeIcenowy> pine64 now seems to be sold on Taobao for ¥199 and said to be shipped in 72 hours
<MoeIcenowy> (shipping not included
<MoeIcenowy> (Will it be a lie?
<wens> MoeIcenowy: wasn't there news about pine64 knockoffs on taobao?
alexxy has quit [Excess Flood]
<MoeIcenowy> wens: oh?
<MoeIcenowy> they're fake?
<MoeIcenowy> is Pine64 open-source?
<wens> was reported on cnx-soft i think
alexxy has joined #linux-sunxi
<MoeIcenowy> if they're board copies, maybe it's worth buying
<KotCzarny> he he
<tkaiser> KotCzarny: Curious how fast your DRAM can be clocked
<luoyi> codekipper: I understand, the table is just another express of my algorithm. the over-samplerate mean the bclk/ratesample
<KotCzarny> tkaiser, they are apparently much better than opipc
<KotCzarny> lets hope im not unlucky
<MoeIcenowy> Here's something interesting... Recently I'm working on my tablet with gsl1680 touchscreen...
<tkaiser> MoeIcenowy: Pine64 released schematic for one board variant and said they won't do more (no OSHW). And they confirmed that the boards an taobao are fakes
<MoeIcenowy> I extracted the firmware from gslX680.ko
<MoeIcenowy> tkaiser: which variant
<MoeIcenowy> 512MB ver?
<MoeIcenowy> and I found the touch experience is bad
<MoeIcenowy> I think the driver is not well
tsuggs has joined #linux-sunxi
<MoeIcenowy> however
<MoeIcenowy> today when I booted it into the stock Android
<KotCzarny> tkaiser, its hard to pull 'shipping not included' scam twice ;)
<MoeIcenowy> I found that... the firmware is badly tweaked...
<MoeIcenowy> oh a low-budget device...
<tkaiser> MoeIcenowy: Don't know, I just read some complaints from people that not all board variants are supported well (would've to look into pine64 wiki)
<MoeIcenowy> tkaiser: oh
codekipper has quit [Quit: Page closed]
reev has quit [Ping timeout: 246 seconds]
<jelle> I wonder if they will ever make that a64 laptop reported on cnx
<MoeIcenowy> is A33 nand not support by mainline kernel?
yann|work has joined #linux-sunxi
<mripard> no nand is supported by mainline LInux
<jemk> wens: what dts?
<jemk> wens: thats not from me ?!
<wens> tkaiser: ugh... you added the link, was it from you?
IgorPec has quit [Ping timeout: 250 seconds]
reev has joined #linux-sunxi
<Amit_T> wens: didn't get any response from u-boot channel regarding my query, could you please have a look at it ?
xcasex has quit [Ping timeout: 244 seconds]
<montjoie> wens: apritezl I have updated my github emac branch
<mripard> Amit_T: you were right in the middle on another discussion, so it might have gone unnoticed
<wens> Amit_T: you should probably send an email to the list, and cc the author of that patch
<mripard> but describing your changes and your problem would help
<tkaiser> wens: Yes, that link was from me. Adding BPi M2+ was just putting together stuff from OPi PC (USB minus one port and one led less) and OPi Plus (Ethernet). And both WiFi/BT is still missing
<KotCzarny> wens, usb minus one port also means 'no internal crippling hub'
xcasex has joined #linux-sunxi
<tkaiser> wens: I used the .dts back then to create Armbian images with 4.6-rc1 for BPi M2+ and OPi Plus
<KotCzarny> oops, too hot, misread
<wens> tkaiser: uh, so do you think i should do a new one from scratch? or use yours? (which you should put your name on)
<tkaiser> wens: All the stuff expect WiFi/BT should work since I based this on SinoVoip's fex file and it's tested. They tried really hard to keep each and every pin mapping identical to Orange Pis so expect of AP chip for WiFi/BT and camera connector .dts should be ok. But I trust way more in your experience than in my copy&paste capabilities ;)
<tkaiser> wens: the red led on BPi M2+ uses the pin mapping of the green led on all Orange Pis
apritzel has joined #linux-sunxi
<Amit_T> wens: ok , just thought before sending an email to the list, I should consult here.
<tkaiser> wens: And this is what we ended up with regarding u-boot: https://github.com/igorpecovnik/lib/blob/master/patch/u-boot/u-boot-dev/u-boot-99-add-missing-boards.patch#L34-L66 (we chose 816MHz since due to VDD_CPUX being all the time at 1.3V BPi M2+ has serious thermal problems)
<Amit_T> mripard: Made few changes in order to support u-boot h3 emac , http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/261544, it was working untill commit b733c278d7adc48c71bd06faf359db3d9e385185 was introduced (and I am not these changes are appropriate for SoC's that have internal PHY)
avph has joined #linux-sunxi
arete74 has quit [Ping timeout: 240 seconds]
IgorPec has joined #linux-sunxi
reev has quit [Ping timeout: 250 seconds]
<mripard> Amit_T: you should tell that on #u-boot ;)
<NiteHawk> he did
<mripard> no, he just said that it was not working
<Amit_T> Done .
<mripard> not pointing to any source code, change, or without describing the issue he was seeing
<NiteHawk> IRC is the wrong place anyway, that should go to the ML
reev has joined #linux-sunxi
<xcasex> hmm
xcasex has quit [Changing host]
xcasex has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
enrico_ has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
kaspter has joined #linux-sunxi
<oliv3r> hi, how would i decipher or figure out what irq causes the following trace: [<800092e1>] (gic_handle_irq) from [<8001141b>] (__irq_svc+0x3b/0x5c)
ricardocrudo has quit [Ping timeout: 276 seconds]
Gerwin_J has joined #linux-sunxi
phiplii has quit [Remote host closed the connection]
kaspter has quit [Ping timeout: 240 seconds]
<luoyi> mripard: I've sent my bpi m1+ dt patch to linux-sunxi maillist. but without any individual personal's mail address. does this is enough for community to review that or I should add get_maintainer.pl's output to the receiver list ? the mail addr is: https://groups.google.com/forum/#!topic/linux-sunxi/tNFIL-Isykc
kaspter has joined #linux-sunxi
<mripard> luoyi: mainline patches should be adressed to everyone that is reported by get_maintainer
<luoyi> mripard: well, should I resend the mail ?
<mripard> yes
arete74 has joined #linux-sunxi
montjoie has quit [Ping timeout: 250 seconds]
montjoie has joined #linux-sunxi
Nacho has quit [Read error: Connection reset by peer]
Nacho has joined #linux-sunxi
ganbold has joined #linux-sunxi
_fortis has joined #linux-sunxi
<luoyi> mripard: I've resent the mail. you should have received the mail now.
ricardocrudo has joined #linux-sunxi
<mripard> yep, I did
reev has quit [Ping timeout: 260 seconds]
tlwoerner has quit [Quit: Leaving]
tgaz has quit [Ping timeout: 260 seconds]
MoeIcenowy is now known as duangduang
ricardocrudo has quit [Read error: Connection reset by peer]
tlwoerner has joined #linux-sunxi
duangduang is now known as MoeIcenowy
Akagi201_ has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
kz1 has quit [Ping timeout: 252 seconds]
kz1 has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
IgorPec has quit [Ping timeout: 276 seconds]
massi has quit [Ping timeout: 240 seconds]
tgaz has joined #linux-sunxi
massi has joined #linux-sunxi
apritzel has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
massi has quit [Read error: Connection reset by peer]
Akagi201 has joined #linux-sunxi
Amit_t__ has joined #linux-sunxi
nove has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<MoeIcenowy> If I want to develop on sunxi i2s support
<MoeIcenowy> should I directly use mripard:wip/a20-i2s?
<MoeIcenowy> @wens @mripard
<MoeIcenowy> or... what should I merge on sunxi-next?
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<wens> MoeIcenowy: i'm not really following i2s development atm
raknaz has joined #linux-sunxi
<MoeIcenowy> wens: I'm now considering implement A33 audio codec as an internal "external" codec
<wens> MoeIcenowy: that was what i was suggesting all along
<enrico_> hi, what's the status of nand support in kernel 4.6 for a20? i know about the ongoing work about randomizer ecc, i wanted to test bootloader+rootfs (readonly) on olinuxino micro and lime2
massi has joined #linux-sunxi
<wens> MoeIcenowy: keep in mind that since we are introducing a new clock driver, it may be a while before we add new clocks (like the audio ones you will need for audio codec / i2s)
<wens> you can of course add them in your own tree
<MoeIcenowy> wens: clock are only dt work, right?
<wens> MoeIcenowy: not exactly, you may need to write new drivers
<MoeIcenowy> in addition
<MoeIcenowy> is a33 csi possible to be mainlined?
<MoeIcenowy> (in allwinner sdk it has a closed libisp
<wens> you could check if it's bypass-able
<wens> someone is working on CSI though
Amit_t__ has quit [Quit: Page closed]
<apritzel> ARGH: those AW guys drive me mad!
<apritzel> wens: just spend literally hours on the boot0 disassembly to find the reason why my RSB setup does not work
<apritzel> and guess what:
<apritzel> the hardware address is 0x3a3, not 0x1d1 as the AXP datasheet says
raknaz has quit [Quit: Page closed]
<KotCzarny> umkay
<KotCzarny> opi+2e happily booted with opipc sdcard ;)
zuikis has joined #linux-sunxi
Amit_t__ has joined #linux-sunxi
ChrisArena52 has joined #linux-sunxi
Netlynx has joined #linux-sunxi
IgorPec has joined #linux-sunxi
massi has quit [Quit: Leaving]
<ChrisArena52> Isn't 3a3 == (1d1 << 1) | 1 ??
<NiteHawk> it is
<apritzel> ChrisArena52: indeed
jernej has joined #linux-sunxi
lamer14646237281 has joined #linux-sunxi
<KotCzarny> ethernet no worky tho
reinforce has joined #linux-sunxi
lamer14646237281 has quit [Client Quit]
paulk-collins has quit [Quit: Leaving]
tkaiser has quit [Ping timeout: 260 seconds]
<wens> probably like I2C, where address is 7 bits + 1 r/w bit :/
matthias_bgg has quit [Ping timeout: 244 seconds]
<KotCzarny> ah, right, chip changed
<KotCzarny> looking at the specs, opi+2e is one of the beefiest sunxi boards
<KotCzarny> almost a dreamboard
tkaiser has joined #linux-sunxi
<apritzel> ChrisArena52: and 3a3 is what we write for the AXP223 in U-Boot as well
<ChrisArena52> So what is the standard for I2C addresses? Wasn't that an I2C address? Should it be the unshifted value (1d1) or the shifted value (3a3)?
<apritzel> but that number is not mentioned in the AXP223 manual
<apritzel> that's the RSB address
<ChrisArena52> either number?
<apritzel> so here is the idea
<apritzel> 1d1 is the device address (as the manual says)
<apritzel> but you have to write (addr << 1) | 1 into the register
<apritzel> which is not documented in the RSB doc in the A83T manual
<apritzel> and the U-Boot code matched the manual
<apritzel> but the AXP223 datasheet did not mention the RSB address
<apritzel> so it was somehow figured out and found to be 0x3a3
<apritzel> but indeed it is also 0x1d1 as for the AXP803
<apritzel> will documented this into the Wiki later
<apritzel> now off to the playground ...
<Amit_t__> playground :), to play CRICKET ?
<wens> apritzel: yeah, we had u-boot sources to work off, so we just used that value
<wens> i managed to work out which addresses match what function
<wens> (which is mentioned in the kernel sunxi-rsb driver)
<jrg> KotCzarny: have you gotten the opi+2e yet?
<jrg> mine made it out of shenzhen
<jrg> so it should arrive stateside soon
<KotCzarny> jrg: yup, today
<KotCzarny> now copying sdcard to another
IgorPec has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
<tkaiser> KotCzarny: There is eMMC on this board. Way faster than your next SD card ;)
<KotCzarny> tkaiser: i think i'll keep droid before i make a backup of it
<KotCzarny> right now it will run happily with samsung evo+ 64gb
<KotCzarny> bigger and fast enough ;)
<KotCzarny> will do
<KotCzarny> no worries
<KotCzarny> i just got home ;)
vagrantc has joined #linux-sunxi
Akagi201 has quit [Remote host closed the connection]
kaspter has quit [Ping timeout: 240 seconds]
ChrisArena52 has quit [Ping timeout: 250 seconds]
<KotCzarny> oh, wow, 55MB/s on nand
<KotCzarny> (read)
<KotCzarny> tkaiser, where is wifi driver located?
<tkaiser> KotCzarny: There are issues now. Will be fixed the next days: http://forum.armbian.com/index.php/topic/1241-opi-lite-wireless-device-not-working/?view=getlastpost
<KotCzarny> so its not fully compatible with etv?
<tkaiser> And I still wonder why everyone on this planet only looks at boring sequential transfer speeds even when random IO is way more important for the use case in question.
<tkaiser> KotCzarny: Nope, just read through the thread
<KotCzarny> tkaiser, because its quick and dirty test done in seconds
<KotCzarny> (hdparm -t)
<tkaiser> KotCzarny: hdparm is BS. Always. Here iozone numbers: http://pastebin.com/L1S7b3m7
<KotCzarny> 7MB/s on random 4k write is respectable, if not speedy
<tkaiser> Only ODROID eMMC for C2 (and maybe C1+) is faster :)
<KotCzarny> you might add that iozone table to opi+2e table
<KotCzarny> for 35usd that opi+2e is a very good board
<KotCzarny> doh, jernej using mega.nz for file hosting.. bleurgh
<KotCzarny> jernej: for short time file storage use transfer.sh
<jernej> KotCzarny: not for everything
<KotCzarny> ie. curl --upload-file file.name http://transfer.sh
<KotCzarny> done!
<jernej> Are you serching for wifi driver?
<KotCzarny> yup
<jernej> I can give you normal link :)
<KotCzarny> would love
<KotCzarny> :)
<jernej> just a sec
<jernej> there is a slight issue, drivers don't get along
<tkaiser> jernej: will the module then be called 8189fs?
<KotCzarny> ie. while having another similar card?
<jernej> so you must be careful not to modprobe 8189es
<KotCzarny> right now i use 8188eu
<KotCzarny> (for usb dongle)
<jernej> yes, 8189fs
<jernej> no, only for SDIO
<jernej> there is some issue with bsp kernel and SDIO rescanning
<tkaiser> 8189fs is great. Then we can differentiate between both chips more easily.
<KotCzarny> btw. does ap mode work?
<jernej> can't check because I don't have a board
<jernej> ask IgorPec
<KotCzarny> umkay, compiling
<KotCzarny> on opi+2e itself ;)
<KotCzarny> hrm, i miss some symbols
<jernej> which ones?
<KotCzarny> [ 1261.081160] 8189fs: Unknown symbol extern_wifi_set_enable (err 0)
<KotCzarny> [ 1261.081401] 8189fs: Unknown symbol sdio_reinit (err 0)
<jernej> for which kernel?
<KotCzarny> 3.4.112
<KotCzarny> self compiled, not armbian one
<KotCzarny> what/where to enable?
<KotCzarny> SDIO UART/GPS class support
<KotCzarny> MMC embedded SDIO device support
<KotCzarny> not uart, lets see the second one
<jernej> did you edit Makefile?
<KotCzarny> only changed sun8i to x86, because im not crosscompiling
<jernej> that is the reason
<jernej> just leave it at sun8i
<jernej> maybe you can clear CROSS_COMPILE
<KotCzarny> but then i'll have to edit the make rules. because they call cc
<KotCzarny> yeah
<jernej> you can then just do "make CROSS_COMPILE="
<jernej> to override default value
<jernej> you must also define KSRC
<KotCzarny> ksrc is autodetected from /lib/modules
Amit_t__ has quit [Ping timeout: 250 seconds]
<jernej> well, in 386
<jernej> but not in sun8i
<jernej> I compiled it with:
<jernej> make KSRC=<path> CROSS_COMPILE=
<jernej> actually, I cross compiled it, but this should work
enrico_ has quit [Quit: Bye]
<KotCzarny> jernej: thank you!
<KotCzarny> btw. why were those 2 symbols undefined in x86 build path?
<jernej> KotCzarny: no problem :)
<jernej> because it's using generic platform driver and not sunxi BSP specific
<jernej> check platform folder
<KotCzarny> btw. as for wifi mac, i would vote for using ethernet mac +1 in the last digit
<buZz> anyone looking for a job? :D
<buZz> > Job Offer: Allwinner International Marketing, Allwinner International TV Box Sales
<jernej> KotCzarny: Is ethernet mac stored somewhere?
<KotCzarny> emac/gmac reads it somehow
<KotCzarny> so i guess you can look for code there
<mripard> R40
avph has left #linux-sunxi ["WeeChat 1.5"]
<mripard> so it's not A40 after all
<KotCzarny> if those tinaos guys do the same support as allwinner to their chips, i would stay with my armbian
<KotCzarny> :)
<mripard> I think tina os is done by allwinner
edolnx has quit [Quit: Leaving]
<KotCzarny> mripard, lets hope they will respect opensource and minimize the blobs ;)
<jernej> and provide full documentation
<IgorPec> yeah ;)
<KotCzarny> hrm
<KotCzarny> you are right that this driver is problematic on changing mac
<jernej> is ethernet mac + 1 safe? What if someone buys 10 boards?
<KotCzarny> hard to say, but it ignored rtw_initmac modprobe option
<jernej> aren't macs usually sequential from same production line?
<KotCzarny> [ 1132.779008] RTL871X: ERROR invalid mac addr:[edited], assign random MAC
<KotCzarny> why the heck it said it's invalid?
<jernej> what form?
<KotCzarny> xx:xx:xx:xx:xx:xx
<jernej> it seems that first byte must have bit 0 or bit 1 set
<KotCzarny> my gmac has 96 as the first byte
<jernej> scratch that
<jernej> bit 0 must be set in first byte
<jernej> try odd number
<KotCzarny> same
<KotCzarny> lets see if i clear whole byte
<tkaiser> jernej: AFAIK u-boot uses the SID to generate a locally administered MAC address for Ethernet: https://en.wikipedia.org/wiki/MAC_address#Address_details
<jernej> tkaiser: Tnx
<KotCzarny> it worked with first byte set to 00
iamfrankenstein has quit [Ping timeout: 244 seconds]
scream has joined #linux-sunxi
<jrg> where is my arm fbsd tho? :(
<KotCzarny> jrg: wrong channel to ask, you think about #freebsd-arm :P
<jrg> lol
<jernej> so something like: xx:xx:xx:xx:xx:00 ?
<KotCzarny> 00:xx:xx:xx:xx:xx
<KotCzarny> i might check other values if you want
<jrg> there isnt a freebsd-arm
<KotCzarny> failed with 16
<jrg> you lied to me
<KotCzarny> not true, you were the first one!
<jrg> lol!
<jrg> sometimes being first isnt the beat thing to be
<jrg> and i deployed to iraq twice
<jrg> so i know what im talking about here :)
<KotCzarny> hmm, it refuses any mac with first byte different from 00
<jernej> there is function which checks mac validity
<KotCzarny> first triplet is assigned to companies
<jernej> and returns null if address is all null, all 0xff or has bit 1 or bit 0 set in first byte
<KotCzarny> still works for 00:00:00:xx:xx:xx
<jernej> Can you try 0x94 for first byte
<KotCzarny> worked
<KotCzarny> 94:00:00
<KotCzarny> i'll just clear the whole first byte for simplicity
<KotCzarny> (scripts)
<jernej> random mac has first tripplet 00:e0:4c
<jernej> but yeah, just zeros is simpler
<nove> now, only needs to be known what is the definition of "open-source"
<tkaiser> nove: Exactly my thoughts. Did you manage to watch the whole video?
<nove> do someone that knows chinese could translate what says in the slide about R40 -> https://www.youtube.com/watch?v=h7KD-6HblAU&t=43s
<nove> yes, i saw both
<KotCzarny> wpa_supplicant connected, no ping :/
<KotCzarny> hrm, tcp works, icmp doesnt?
<nove> in the job offer video, there are said that one of the roles, is to "improve the reputation of allwinner", and for international sales, then maybe
apritzel has quit [Ping timeout: 244 seconds]
<KotCzarny> poor scapegoat
<jernej> KotCzarny: There are two todos in source, one for IPV6 and another for 802.1Q VLAN header
<KotCzarny> jernej, when i ping it from another machine, it replies
<KotCzarny> anyway, ssh works and that's what counts
<jernej> well, if it uses same codebase as 8188eu (which seems it does), then driver quality is not so good
keh has joined #linux-sunxi
<nove> that R16W, has integrated wifi
<tkaiser> nove: Otherwise it would be a normal A33 ;)
<nove> (i had this suspicion from the A64 bsd sources)
<KotCzarny> i love this orange
<KotCzarny> it 'just works' (thanks to you guys of course)
Gerwin_J has quit [Remote host closed the connection]
<tkaiser> KotCzarny: If you want to try out mainline kernel (after you submitted DRAM test results ;) you might give M2+ image a try: http://linux-sunxi.org/Banana_Pi_M2%2B#OS_images
<tkaiser> You 'loose' only 1 USB port, 1 led and WiFi
<KotCzarny> hehe
<KotCzarny> hrm, when running lima-memtester ./fel... should wait for usb device?
<KotCzarny> or just connecting usb cable to otg port switches it into fel mode?
<KotCzarny> or i have to press some button?
<tkaiser> nove: Interesting. Also BT maybe?
<nove> yes, maybe
<tkaiser> KotCzarny: You have to press the FEL button since otherwise you boot Android. There is a wiki page already ;) (and that's one of the reasons I created an own page for Plus 2E since buttons are different on Plus 2)
<KotCzarny> well, you should add that bit of info to memtester section, even if duplicating info
<tkaiser> KotCzarny: Eject SD card, connect OTG cable, press FEL button, provide DC-IN (necessary)
<tkaiser> Most probably lima-memtester will continue to run when you cut DC-IN since after the board has been powered on it can also use 5V provided through OTG port
<KotCzarny> added that info
<KotCzarny> can the board be powered via otg port ?
apritzel has joined #linux-sunxi
<tkaiser> KotCzarny: If it's like the other Oranges then no (doesn't power on then). But I haven't really tried since I'm a member of the Micro USB haters club ;)
<tkaiser> KotCzarny: Did you receive also a PSU from Xunlong?
<ssvb> tkaiser, KotCzarny: or just write the fel-sdboot.sunxi image from https://github.com/linux-sunxi/sunxi-tools/tree/master/bin to the SD card
<montjoie> tkaiser: why do you prefer barrel DC than uUSB for power ?
<ssvb> tkaiser, KotCzarny: via "dd if=fel-sdboot.sunxi of=/dev/sdX bs=1024 seek=8"
<ssvb> montjoie: barrel DC is a bit more foolproof
<KotCzarny> hrm, cant find hdmi cable, will test memory tomorrow
<KotCzarny> tkaiser: i've ordered barrel--usb adapter (because i have a power brick from my hdd that i was using with opipc and i needed another power source)
<KotCzarny> montjoie: because uUSB is limited to 1.8A at best
alain has joined #linux-sunxi
<KotCzarny> still, would be convenient to run it from such source for low power tasks while mobile
jstein has joined #linux-sunxi
<alain> I'm testing montjoie's latest sun8i-emac driver, getting the following error: sun8i-emac 1c30000.ethernet eth0: Could not attach to PHY, any ideas ?
<alain> running 4.7.0-rc1
Gerwin_J has joined #linux-sunxi
ganbold has quit [Quit: Leaving]
<alain> tried the "gpio set PD6" trick in u-boot, no success either
ganbold has joined #linux-sunxi
<alain> [ 0.912506] libphy: 1c30000.ethernet: probed [ 93.202988] sun8i-emac 1c30000.ethernet eth0: Could not attach to PHY
jernej_ has joined #linux-sunxi
<tkaiser> montjoie: Micro USB is 1.8A max by design/specs. That is the first problem (since under heavy load and especially with connected peripherals the board needs more). And then USB cables are prone to voltage drops (resistance) and encourage people to use the wrong 'PSU' (eg. crappy phone chargers or 'smart' chargers that do not provide more than 500mA if the device on the other end of the cable is too dumb to signal a need for
<tkaiser> more -- applies to every SBC out there)
<tkaiser> ssvb: Thx for the instructions, will try this with OPi PC Plus the next days (since no FEL button)
jernej has quit [Ping timeout: 244 seconds]
jernej_ is now known as jernej
alain has quit [Ping timeout: 250 seconds]
Akagi201 has joined #linux-sunxi
Akagi201 has quit [Remote host closed the connection]
scream has quit [Remote host closed the connection]
<KotCzarny> tkaiser, i think you should add photo of the board without the heatsink
alain has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
<tkaiser> Too late
<tkaiser> KotCzarny: BTW: No one trying to buy a sunxi board is looking into our wiki.
<montjoie> tkaiser: KotCzarny thanks for the info
<montjoie> alain for which board ?
<alain> Orange Pi Plus (the old one)
<longsleep> most people buying a sunxi board do not even know that they do
<montjoie> alain: perhaps I forgot something in the dt
<montjoie> alain: we change the handling of phy from external driver to internal
FergusL has quit [Ping timeout: 276 seconds]
<alain> don't think I can spot an error in the dt but happy to test if you want me to try something
<montjoie> alain: it worked before right ?
<alain> nope, that's the first time in a long time I test mainline kernel
<alain> yes boss :)
<montjoie> alain: no other message from emac (dmesg |grep -i emac) ?
<alain> nope
<alain> I'm just getting an earlier boot message "libphy: 1c30000.ethernet: probed"
IgorPec has quit [Ping timeout: 250 seconds]
<alain> tkaiser: all bits from the patch you linked to appear to be there
<KotCzarny> we need 'buying guide' page in wiki, that will explain that one shouldn't just look at the specs
<KotCzarny> for example, sometimes fewer usb ports is more
<alain> I actually tried manually setting PD6 in uboot, same result
<tkaiser> KotCzarny: Useless, people come to linux-sunxi community after they made mistakes, not prior to that
<KotCzarny> and other thing like opensource and blobs, marketing scams about speeds, implementation fails
<KotCzarny> tkaiser, google power
<tkaiser> KotCzarny: filter bubble
<KotCzarny> linked in enough places it will help to promote things we want
<KotCzarny> and right now opi+2e took my personal #1 from opipc in being best board for the money
<tkaiser> KotCzarny: There will be some sort of 'promotion' for this board soon. We just have to think about way to do the best with it (community wise). But the channels to spread the word are definitely different.
<alain> montjoie, tkaiser: anything else you'd want me to try before I switch my opiplus back to legacy kernel?
<KotCzarny> tkaiser: good, because its a really nice board, and people are just clueless what to choose
<longsleep> how is CSI camera support for sunxi handled in mainline - i am looking at the drivers in the BSP tree and well .. terrible
<KotCzarny> longsleep, i bet you are better of with usb camera
<KotCzarny> ;)
<longsleep> i am sure yes, but i have never looked into CSI cameras before and want to see whats possible
<longsleep> i am pretty shocked at the quality of the vfe stuff, its even worse than the rest
zuikis has left #linux-sunxi [#linux-sunxi]
<longsleep> https://github.com/longsleep/linux-pine64/blob/pine64-hacks-1.2/drivers/media/platform/sunxi-vfe/device/hm5065.c#L4793 look at that - it looks like its just fresh out of some interns desktop folder trash
<KotCzarny> hmm, i must say connection quality of that wifi setup is pretty nice
<KotCzarny> let's see how about stability
<KotCzarny> jernej: debug shall be turned off though, it thrashes my logs
JohnDoe8 has joined #linux-sunxi
<KotCzarny> ooh, did it just hung? (during -j4 compilation)
<jernej> oh, i forgot to update tar on server
<jernej> just edit include/rtw_debug.h:186: printk->pr_debug
JohnDoe_71Rus has quit [Ping timeout: 244 seconds]
<KotCzarny> i just undefined CONFIG_DEBUG
<jernej> where is it set?
<KotCzarny> include/autoconf.h
<jernej> that works too :)
<KotCzarny> tkaiser: you should advise against 1296 without the heatsink
<KotCzarny> 1200 seems stable tho
JohnDoe8 has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
<ssvb> KotCzarny: what's wrong with 1296?
<KotCzarny> ssvb: board just hung during compilation (few moments before that it reached ~70C)
<KotCzarny> or at least it lost all network connectivity (wifi/eth)
<ssvb> KotCzarny: this does not sound good, but you could try increasing the dvfs voltage in script.bin
<ssvb> just to check if this helps
<KotCzarny> LV1_freq = 1296000000
<KotCzarny> LV1_volt = 1320
<KotCzarny> might be too conservative
<KotCzarny> i think armbian's dvfs values arent stable for all boards
<ssvb> well, the Allwinner's fex seems to recommend at least 1340 - https://linux-sunxi.org/Orange_Pi_PC#CPU_clock_speed_limit
<KotCzarny> i guess armbian's values might work when using heatsink
<tkaiser> ssvb: KotCzarny: Yes, might be true. I still believe we made a mistake with Armbian settings when we started to support all the SY8106A based H3 boards.
<tkaiser> KotCzarny: Temperature shouldn't be a problem at all. Undervoltage is more likely. But compiling is pretty lightweight
<KotCzarny> i will stick with allwinner's defaults
<tkaiser> KotCzarny: Allwinner defaults are crap anyway. In case you do please do NOT spread the word immediately unless you have a proof that this was the culprit.
<ssvb> tkaiser: the temperature also affects reliability, so running at 70C at some voltage may be less reliable than running at 40C at the same voltage
<KotCzarny> tkaiser: it hung wit 1296@1320, allwinner suggests 1340
<tkaiser> Small addendum: I thought I killed my BPI M2+ when testing a few days ago. Since it froze at boot. Serial console showed that enabling EHCI was the last action.
<tkaiser> Then I tested with OPI Plus 2E and experienced the same. Same with PC Plus. Just to realize that the Apple PSU that worked flawlessly for years was the culprit.
<tkaiser> That's the reason I asked whether you got a PSU from Xunlong too. Since this solved the problem for me
<KotCzarny> i have a psu from hdd enclosure capable of the few amperes on the each line
<KotCzarny> still, you might be right
<KotCzarny> gonna check again at 1296@1340
<ssvb> tkaiser: if you remember that article, it is just harder for the electrons to move when the temperature gets higher - http://asic-soc.blogspot.fi/2008/03/process-variations-and-static-timing.html
<tkaiser> BTW: Tested H3 running at 100C for 5 days by accident on BPi M2+ before. Since I simply forgot that I had the board running in a small cardboard box without any airflow running cpuburn-a7 (throttling down to 576/480 MHz)
<KotCzarny> poor banana
<tkaiser> ssvb: Thx for the reminder. I still would check whether insufficient DC-IN might be the culprit.
<KotCzarny> hrm
<KotCzarny> same story, reached 70C and hung
<KotCzarny> funny that
<ssvb> well, it sounds like the *transition* between the operating points may be the culprit
<KotCzarny> nope, it reached 1296 and back down few times
<tkaiser> ssvb: More details please
<ssvb> if I remember correctly, 70C is exactly the transition threshold
<KotCzarny> hum?
<tkaiser> KotCzarny: Which fex are you using? Outdated pastebin.com stuff, latest version from Armbian repo or the fex wens extracted from the Android image?
<ssvb> it could have tried to jump up and down rapidly between 1200/1296 and somehow got stuck
<KotCzarny> armbian fex from wiki page
<KotCzarny> this one
<tkaiser> ssvb: I played this game a few hundred times the last days. On the left constantly jumping between 1200/1296 MHz: http://kaiser-edv.de/tmp/Gn4wTB/Bildschirmfoto%202016-05-25%20um%2018.14.54.png
FergusL has joined #linux-sunxi
<KotCzarny> gotta run, cya!
<KotCzarny> just fyi: when stuck to 1200 as the max freq compilation finishes successfully
<KotCzarny> but temp reaches ~67C max
<KotCzarny> hrm
<KotCzarny> i lied
<KotCzarny> reached 70C and hung too
<KotCzarny> o.O
<KotCzarny> wth
<tkaiser> KotCzarny: Between 1200 and 1296 MHz VDD_CPUX is switching. In case you can use another PSU please do
<KotCzarny> yeah, gonna find me one
<KotCzarny> i remember that opipc killed one of those hdd psus in the past
<KotCzarny> but its funny its not the load but temperature point which is consistent
<tkaiser> And they are from old IDE enclosure and probably 20 years old, true? ;)
<longsleep> 70C is the first trip point in the fex you linked, now if i could read fex files it would be easy to figure out what happens :)
<KotCzarny> nope, has ide and sata
<KotCzarny> longsleep: oh, i didnt check that fex, just assumed it works
<tkaiser> KotCzarny: Cool, only 15 years old! ;) Just kidding, you really should try to use another PSU
<longsleep> KotCzarny: if i read this correctly, at 70*C it clocks down to 1.2GHz and reduces voltage to 1240mV
edolnx has joined #linux-sunxi
<tkaiser> The fex works pretty well but switching between 1296 and 1200 MHz means also 100mV now that you increased the dvfs opreating point voltage
<KotCzarny> gotta run now, will check it tomorrow
<longsleep> its less than 100mV, LV1 seems to be 1320 and LV2 1240
<longsleep> no clue about fex files though :)
<tkaiser> longsleep: He increases it to fex comments from Allwinner (1340mV). And BTW: You read it correctly
<longsleep> ah
<longsleep> ok :)
<tkaiser> longsleep: It's exactly the same stuff we played with already. Just different 'encoding'
<longsleep> yeah i got it
<tkaiser> And I tried to torture OPi Plus 2E already with much higher thermal settings (no problem at all since the board shows really excellent heat dissipation) just to realize that performance gains are laughable when increasing allowed temperatures a lot.
<longsleep> mhm is it not linear to cpu frequency?
<longsleep> its slower when cooler?
<tkaiser> This was without a heatsink. When allowing 90*C then cpufreq jumped between 1200 and 1296 MHz, after decreasing first trip point to 70*C cpufreq remained at stable 1200 MHz (less that 4 percent performance 'loss')
<tkaiser> longsleep: Just a little bit
lukasz has joined #linux-sunxi
mosterta has joined #linux-sunxi
<lukasz> Hello
<longsleep> well 4 percent is something but 70*C is a lot better than 85*C
<tkaiser> longsleep: With heatsink it makes no difference at all if cpuminer is the only workload since heat dissipation is that good that cpufreq remains at 1296 MHz anyway.
<longsleep> ok thats good
<longsleep> i was hoping this was possible with the Pin64 heatsink but it is not
alain has quit [Quit: Page closed]
<tkaiser> longsleep: A64 is a different story. But I'm still curious how the announced H64 boards from Xunlong behave. All 3 new Xunlong boards have a thicker PCB (maybe containing copper as you mentioned yesterday)
<longsleep> tkaiser: yes, but the Pine64 board also contains copper according to TL
<longsleep> tkaiser: i guess it is the amount of copper which matters
<tkaiser> longsleep: Try to bend Pine64 and try to bend OPi Plus 2E ;)
<longsleep> well, i have enough boards in the shelf which i did not touch yet, i like the Pine64 as i could essentially start from scratch software wise
jernej has quit [Ping timeout: 244 seconds]
jernej_ has joined #linux-sunxi
<tkaiser> longsleep: I know. In case Steven's asking: Would you be interested in a H64 Orange _when_ Xunlong is ready?
<tkaiser> But I would suspect it would be rather boring since the only difference between A64 and H64 might be a varying SoC ID and that's it
Gerwin_J_ has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 244 seconds]
Gerwin_J_ is now known as Gerwin_J
<lukasz> Got two questions about compiling an android image for the pine64. 1) is the layout of partitions from sunxi wiki the same for pine64 and 2) does anyone have any info about u-boot for android?
<tkaiser> lukasz: To which Android sources do you refer?
ricardocrudo has quit [Remote host closed the connection]
<tkaiser> lukasz: Sorry, I meant which Android sources are you trying to use with Pine64?
<lukasz> One moment tkaiser: Im asking on behalf of someone, so I need him to get back to me.
<lukasz> Android SDK 6.0 from wiki
jernej has joined #linux-sunxi
jernej_ has quit [Ping timeout: 252 seconds]
<tkaiser> Good luck. I wouldn't expect being able to build Android from sources if there's a 12GB large tarball lying somewhere around and the vendor still fails to provide working Android 5.x builds :)
<tkaiser> 'Working' read as 'where such simple things like display resolutions work flawlessly'
<lukasz> oh thats a pity :/ Thank you very much tkaiser - helpful as always.
<tkaiser> lukasz: To be honest: I might spread to much negativity here. Better rely on someone else's experience who is more familiar with Android.
<lukasz> tkaiser: No worries - I can always see past you negativity and appreciate your comments ;) I will linger for a little bit and see if someone else has any ideas
<lukasz> well, perhaps its not all lost "<kap1r0t0> but I have already compiled I just do not know where or how to save the files that were generated ( boot.img , system.img , recovery.img )"
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
Gerwin_J has quit [Quit: Gerwin_J]
reinforce has quit [Quit: Leaving.]
lukasz has left #linux-sunxi ["Leaving"]
nove has quit [Quit: nove]
mpmc has quit [Ping timeout: 276 seconds]
Andy-D_ is now known as Andy-D
<apritzel> longsleep: tkaiser: there seem to be some difference between H64 and A64
<apritzel> I did some experiments the other day with FEL booting
<apritzel> loading the same code on a Remix Mini PC and a Pine64
<apritzel> and the Remix was executing in _non_secure SVC mode, whereas the Pine64 comes up in secure
<apritzel> which explains why I can't access some peripherals or do a RMR call to get to 64-bit on the Remix
<apritzel> using FEL the only code that comes from the device is from BROM
<apritzel> so either the BROM is different
<apritzel> or there is some magic pin which toggles this behaviour
<apritzel> or the BROM is making different decisions based on the SID
<apritzel> or it's something else ;-)
<willmore> Magic?
<apritzel> willmore: let's consider the above options first ;-)
keh has quit [Ping timeout: 264 seconds]
mpmc has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
jstein has quit [Remote host closed the connection]
<apritzel> yeah, at least one good thing from my disassembly hours: I hacked boot0 to load U-Boot & company from sector 80 (just behind boot0) instead of 19096KB
<apritzel> longsleep: that means that the whole firmware can be located within the first Megabyte of the SD card
<apritzel> very much like upstream U-Boot does
<apritzel> just don't know about the legality of this change (if it's still OK to distribute the changed boot0 binary)
<ssvb> apritzel: sent soem fixes to the U-Boot mailing list
<ssvb> there is a slim chance that this might be somehow related to this "magic" too
<apritzel> ssvb: ah nice
<willmore> apritzel, okay, I'm just saying don't rule out magic. ;)
* apritzel is humming the Queen song now
ssvb has quit [Remote host closed the connection]
<willmore> It's a kind of magic?
<apritzel> willmore: indeed that one
<willmore> Nice.
* willmore may boot his Pine64 tonight for the first time.
<willmore> Or I might watch the new star wars movie with my kids.
<apritzel> or Highlander (though it's nothing for the kids, I am afraid)
<apritzel> I'd suggest you prefer the family over the Pine64, btw ;-)
<willmore> Kids are 7 and 9. Not quite ready for Highlander.
<apritzel> Indeed, was just because of the music ;-)
<willmore> No, they can listen to the music. It's more the beheading and the profanity that it's not quite kid friendly.
<willmore> Then again, there's going to be a bit of that in this star wars movie, I'm afraid.
<apritzel> agreed, but my son (turning 9 soon) took it quite well
<apritzel> but we cut a bit back on those action movies here
<willmore> Yeah, it's really my 7 year old daughter who will find it distressing. She didn't like when the girl cut her hair off in "Tangled".
<apritzel> can recommend Zootopia and Inside Out, btw
ganbold has quit [Quit: This computer has gone to sleep]
<willmore> Inside out was good. zootopia is on the list of movies to get.
<apritzel> it has a nice message
<apritzel> and is quite fun too
jernej_ has joined #linux-sunxi
Andy-D has quit [Ping timeout: 260 seconds]
jernej has quit [Ping timeout: 276 seconds]
Akagi201 has joined #linux-sunxi