<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
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 ?
<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>
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?
<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.
<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
<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
<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
<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]
<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?
<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
<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
<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
<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>
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?
<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 )"
<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.