<willmore>
Anyone know what needs to be done to hook a Li battery to the Pine64? The three pin connector is labeled for +/-. The middle pin is unlabeled and unused? What chemestry does it support? LiCo? LiPo?
<lennyraposo>
my understanding is it is a Lipo
<lennyraposo>
and thoguht that the other pin is for charge level repoting
<lennyraposo>
could be wrong
ninolein has quit [Ping timeout: 250 seconds]
ninolein has joined #linux-sunxi
Wizzup has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
Wizzup has quit [Ping timeout: 265 seconds]
Wizzup has joined #linux-sunxi
<dave0x6d>
so apparently a rep from allwinner is going to come to this channel.
<ssvb>
NiteHawk: I think it's good enough to merge
IgorPec has joined #linux-sunxi
<NiteHawk>
me too :)
<ssvb>
about the github pull requests based workflow, do we keep a changelog between patch revisions in the commit message?
<ssvb>
and in general, merging pull requests instead of just pushing patches keeps a references to the discussion threads associated with the patch sets
<ssvb>
not to mention that the pull requests are automatically checked by the CI, so probably every contribution should go through a github pull request
<NiteHawk>
ssvb: we should / could probably do that in the pull request (initial message). in your case it was simple enough to have the history in the commit, but what about patch sets containing several commits?
<NiteHawk>
and yes, merging those PRs later will then preserve their history too
<ssvb>
NiteHawk: we can just merge it, I don't feel like introducing any changes because that would require re-testing on a bunch of devices again
<NiteHawk>
that's fine - i just wanted to know if it's okay to merge. i've been looking at the generated assembly a bit with my gentoo cross-compiler (gcc-4.9.3), and got the impression that the quirks mentions are more toolchain-related than actual problems with the code.
<ssvb>
different toolchains just produce slightly different code, and it may or may not trigger this bug
<NiteHawk>
i haven't tried that specific version. with mine, i was unable to reproduce your crosscompiler's generation of that particular "blx" instruction. the newer gcc even nicely optimized the push/pop away and basically did a plain "ldr r3,... ; bx r3"
<NiteHawk>
(which works fine for the A20)
<ssvb>
still the current fel-sdboot.c code in git without the NOP padding in the beginning seems to fail with some versions of GCC
<ssvb>
as you know, legacy kernels from Allwinner sometimes need old versions of GCC, so I kept that one around
<NiteHawk>
yes, i intend to do more testing with that on A20 and A64 (but unsure if i'll downgrade to 4.7). for now, let's just keep those NOPs which seem to resolve it
Gerwin_J has joined #linux-sunxi
<NiteHawk>
ssvb: i just noticed that the bin/fel-sdboot.sunxi from your commit seems to be the "broken" blx variant?
jernej has quit [Ping timeout: 240 seconds]
<ssvb>
NiteHawk: what is broken in it?
<NiteHawk>
your gist says "(THIS DOES NOT WORK CORRECTLY ON A10 and A20!!!)"
<NiteHawk>
ah, nvm - it's different code
<NiteHawk>
the "breakage" was in the instructions preceding it, not the blx itself - right?
curlybracket has quit [Ping timeout: 250 seconds]
<ssvb>
we still don't know what is happening, either it is the shift of the code that makes the bug go away, or it is the delay by a few CPU cycles
IgorPec has joined #linux-sunxi
<NiteHawk>
ah, understood. as the gist didn't have the NOP padding we can't really tell where the problem lies with that
lemonzest has joined #linux-sunxi
reinforce has joined #linux-sunxi
staplr has quit [Remote host closed the connection]
jernej has joined #linux-sunxi
jernej has quit [Ping timeout: 276 seconds]
<wens>
montjoie: my h3-emac branch is updated
<wens>
the bindings have been updated to include ephy, and tx/rx clock delays
<wens>
the driver updated to support ephy, and rmii on h3/a64
<plaes>
oh yea :)
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
premoboss has joined #linux-sunxi
IgorPec has quit [Ping timeout: 250 seconds]
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 260 seconds]
iamfrankenstein1 is now known as iamfrankenstein
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
IgorPec has joined #linux-sunxi
premoboss has quit [Read error: Connection reset by peer]
<agraf>
"A subroutine must preserve the contents of the registers r4-r8, r10, r11 and SP (and r9 in PCS variants that designate r9 as v6)."
<ccaione>
wens: sorry to forward you more work ;)
[7] has quit [Remote host closed the connection]
TheSeven has joined #linux-sunxi
TheSeven has quit [Remote host closed the connection]
TheSeven has joined #linux-sunxi
<apritzel>
ssvb: by the way: how far did you get with your SPI boot on the Pine64? I assume you have a hacked SPL, that loads the U-Boot proper from SPI NOR as well?
IgorPec has quit [Ping timeout: 265 seconds]
<apritzel>
ssvb: if yes, is there any code somewhere?
<ssvb>
apritzel: not yet, I'm just trying to patch sunxi-tools to backup/restore the spi flash
<apritzel>
I can trade the DT nodes for SPI (flash) on the Pine64 (later) ...
<apritzel>
(on the box at home only)
<apritzel>
so you should be able to flash it from Linux directly on the board
<wens>
that particular function would probably stay in assembly
<agraf>
ssvb: you are aware that there's a tool called "flashrom", right?
<wens>
one of it's functions is to setup the stack
<agraf>
ssvb: which supports a good number of spi flash chips attached via spidev
<wens>
so the C calling conventions handled by the compiler do not work here
<ssvb>
agraf: yes, and I will be probably borrowing some parts of it (the table with known spi chips)
<agraf>
ssvb: oh, or is this through fel?
<wens>
anyway what i did was convert everything to C, and then pick out the ones that make sense
<ssvb>
agraf: yes, this is through fel to make everything easy
<agraf>
ssvb: i see :)
<KotCzarny>
embedding asm in c usually breaks with gcc version change
<KotCzarny>
s/usually/after some time/
<agraf>
ssvb: is there some way to just reuse flashrom?
<oliv3r>
i'd thinking eventually, why not
<ssvb>
agraf: why would we want to do this?
<agraf>
ssvb: so that new chips get supported automatically
<agraf>
ssvb: there are really funky spi flash chips out there, with different regions supporting different erase sizes for example
<agraf>
ssvb: i don't think you want to remodel or copy that code into sunxi-tools, just to diverge at the end of the day
<agraf>
ssvb: so if there was a way that flashrom could just use sunxi-tools as a proxy to talk to the remote side, you wouldn't have to copy any code
<agraf>
ssvb: how much communication can you do with the current fel approach?
<agraf>
ssvb: is there some channel to send messages back/forth to the fel payload?
<wens>
ccaione: not sure i can help much though, i don't have baytrail tablets
<agraf>
ssvb: if so, you could just use that to encapsulate spi messages, basically remodel the linux spidev interface on top of it
<agraf>
ssvb: and then just proxy everything through there
<agraf>
ssvb: spi-as-a-service ;)
<wens>
ccaione: and ACPI is probably worse than DT in fixability
<ssvb>
agraf: yes, but we probably don't need most of the functionality that the flashrom tool offers
<agraf>
ssvb: on spidev it only offers read/erase/write
<agraf>
ssvb: but you definitely will need a lot of logic
<agraf>
ssvb: some chips need to get partitioned when they come from the factory
<agraf>
ssvb: i had that issue with a few of mine
<ssvb>
apritzel: regarding the U-Boot support, we need a way to identify that the SPL had have loaded from SPI, and this probably needs to be communicated via some data in the SPL header (similar to the FEL boot detection)
<agraf>
ssvb: doesn't A64 have a boot source register?
<ssvb>
agraf: in addition, we probably need some way to prevent stupid users from flashing a wrong firmware, etc.
<ssvb>
agraf: what is the name of this register?
<agraf>
ssvb: I was asking, most SoCs have one
<ssvb>
I think that currently U-Boot is just probing the bootable devices in the same order as the SoC
<ssvb>
for FEL mode, the sunxi-fel tool is patching the SPL header in memory and the SPL code then reads this information
<apritzel>
ssvb: if users just can boot from a recovery SD card, we could provide an image which loads a special U-Boot which flashes the NOR from there
<agraf>
ssvb: hm, i think you're right, I don't see any register
<ssvb>
the availability of the recovery SD card is nice, but IMHO supporting the firmware recovery directly over USB via sunxi-tools still makes sense
<ssvb>
the recovery SD card needs to interact with the users in some way, and this means either UART serial console or HDMI
<KotCzarny>
unless it's 'back to factory state'
<KotCzarny>
run&done
<ssvb>
yes, but there is one problem, the user needs to pick a *correct* recovery SD card image for his device
<ssvb>
and considering the xunlong boards naming conventions, a lot of users may be confused and use a wrong firmware :-)
<KotCzarny>
one firmware to rule them all!
<KotCzarny>
(which isnt that hard i bet with xunlong 'variety' ;)
<ssvb>
IMHO the best option is to have the SPL header with some information about the board (at least the name of the dtb blob)
<ssvb>
then the sunxi-fel tool can try to read this header from the SPI flash and find this information
<ssvb>
based on it, the user can be given warnings about trying to flash incompatible firmware with a different dtb name
<apritzel>
ssvb: the recovery card could have some magic on it to find the right board and select the right firmware
<apritzel>
but I agree that having SPI NOR support in FEL is a good thing
<apritzel>
actually I am not sure we need different firmwares at all
<KotCzarny>
+1
<apritzel>
but this is all theoretical at this point ...
enrico_ has quit [Remote host closed the connection]
* apritzel
is for more discovery instead of hardcoded stuff
<KotCzarny>
there are soc families, and the differences are in dts/addon devices
enrico_ has joined #linux-sunxi
<apritzel>
and for the Pine64 we can detect the board variants by looking at the DRAM size
<KotCzarny>
apritzel: what about fake pine64? ;)
<apritzel>
and by pursuing TLLim to not spoil this in future revisions ;-)
<ssvb>
yes, the DRAM size is one of the things that are used for automatic detection (reducing the list of possible matches), but it is not enough
<ssvb>
having a bit of non-removable storage on every board and reading the board type id (the dtb blob name) is IMHO the right thing to do
<ssvb>
SPI flash is a good option because we can safely probe it in the bootloader on SPI0
<ssvb>
the boards are not expected to have anything radically incompatible on these pins, because otherwise this stuff would fry at the time when the BROM was probing it
<ssvb>
then there is a boot partition on eMMC and NAND, which can be also safely probed
Amit_T has quit [Ping timeout: 265 seconds]
Shirasaka-Hazumi has quit [Read error: Connection reset by peer]
<igraltist>
montjoie: did u test the hwrng on cubietruck with kernel 4.5?
<igraltist>
montjoie: the rngd does not start, [rngd] No entropy sources working, exiting rngd_
avph has quit [Ping timeout: 260 seconds]
Amit_T has joined #linux-sunxi
<montjoie>
igraltist: didnt own any cubietruck
avph has joined #linux-sunxi
<montjoie>
could you share dmesg ?
Shirasaka-Hazumi has joined #linux-sunxi
<montjoie>
and from where do you get hwrng patch ?
<igraltist>
montjoie: i just remember that i was trying ur patch before. but it was longer time ago
<montjoie>
try from my github
<igraltist>
montjoie: the /dev/hwrng is build so i was thinking the patch was in mainline
<igraltist>
the nand on cubietruck which node it have?
<montjoie>
igraltist: no mainline at all for hwrng
<igraltist>
montjoie: ok
<montjoie>
until recently the quality wasnt enough good
<igraltist>
montjoie: could you give me the url for github again :D
<montjoie>
and I need to retest it because the quality of hwrng (tested by rngtest) decrease when the SS is usd by another algo
<ddc>
if you have access to pudn can you please have a look
JohnDoe_71Rus has joined #linux-sunxi
Amit_t_ has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Equilibrium 4.2.0, revision: 42021, sources date: 20120701, built on: 2013-10-21 12:25:22 UTC 42021 http://www.kvirc.net/]
<MoeIcenowy>
Maybe the HawkView ISP will be a real disaster to linux-sunxi developers...
<MoeIcenowy>
they are blobs and blobs
<KotCzarny>
are there any blobs?
<MoeIcenowy>
hawkview
<MoeIcenowy>
the isp of a31+
avph has quit [Ping timeout: 260 seconds]
<nove>
ddc: there isn't much that i can look, i get blind as soon as i see that the sources don't have a proper license compatible with open-source
avph has joined #linux-sunxi
<nove>
and i finished reading about MAE scaler, the scaling method matches what was observed with the veisp subengine scaler
<nove>
MAE scaler uses 6 * 32 luts of filter coefficients
<nove>
our scale appears to use only 2 * 32 (or 1 * 64) lut
<ddc>
some of the files have a proper license
<ddc>
(:
<nove>
well at least we have a datasheet that explain the math behind (if proved equal)
avph has quit [Ping timeout: 260 seconds]
<ddc>
I can also see some implementation of the h264 whcih is using ffmeg kibraries
<ddc>
libraries
reinforce has quit [Ping timeout: 260 seconds]
montjoie has quit [Ping timeout: 244 seconds]
avph has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
montjoie has joined #linux-sunxi
fredy has quit [Excess Flood]
avph has quit [Ping timeout: 260 seconds]
fredy has joined #linux-sunxi
zerotri has quit [Remote host closed the connection]
steev has quit [Remote host closed the connection]
nihcas has quit [Remote host closed the connection]
reinforce has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
avph has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
zerotri has joined #linux-sunxi
steev has joined #linux-sunxi
oneinsect has joined #linux-sunxi
apritzel has joined #linux-sunxi
avph has joined #linux-sunxi
enrico_ has quit [Quit: Bye]
apritzel has quit [Ping timeout: 244 seconds]
nihcas has joined #linux-sunxi
massi_ has quit [Quit: Leaving]
ricardocrudo has quit [Remote host closed the connection]
pitelpan has quit [Quit: I am going to fishing!!!]
yann|work has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 4.9.2, revision: git-6627-gf708225, sources date: 20160102, built on: 2016-05-12 17:32:15 UTC git-6627-gf708225 http://www.kvirc.net/]
Netlynx has quit [Quit: Leaving]
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
<nove>
this is it
<nove>
from a blob trace, i plotted the coefficients and got a nice sinc as window function