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
apritzel has quit [Ping timeout: 244 seconds]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
vickycq has quit [Ping timeout: 240 seconds]
tipo has quit [Ping timeout: 260 seconds]
tipo has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
Wizzup has quit [Ping timeout: 244 seconds]
<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.
<dave0x6d> KotCzarny: https://i.imgur.com/J90VYUS.png
<dave0x6d> so if you guys have any questions you want to bug them with, now would be the time.
<dave0x6d> s/now/whenever they decide to show up/
<lennyraposo> interesting
<dave0x6d> lennyraposo: also, the sunxi linux team has officially converted to be the first Sunni muslim linux.
<lennyraposo> what???
<dave0x6d> lennyraposo: read the email :p
<lennyraposo> LMAO
<lennyraposo> the typo
<dave0x6d> her autocorrect wrote "linux-sunni"
wvusoldier has quit [Quit: Leaving]
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 244 seconds]
cnxsoft1 is now known as cnxsoft
<lennyraposo> hope they reach the proper chat
TheLinuxBug has quit [Ping timeout: 264 seconds]
TheLinuxBug has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
<plaes> ah.. Eva
fredc has joined #linux-sunxi
fredc has quit [Client Quit]
reev has joined #linux-sunxi
reev has quit [Max SendQ exceeded]
reev has joined #linux-sunxi
reev has quit [Read error: Connection reset by peer]
reev has joined #linux-sunxi
<KotCzarny> dave0x6d: lol @ sunni
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1_ has joined #linux-sunxi
<dave0x6d> KotCzarny: Is that going to be a problem?
<KotCzarny> if they join #linux-sunni, yes
<KotCzarny> :)
* NiteHawk Now talking on #linux-sunni :D
<KotCzarny> friday the 13th
<KotCzarny> the day china semiconductor company went sunni way ;)
<NiteHawk> #linux-sunny - always on the bright side ...
<lennyraposo> always lokk on th ebirght side...
<lennyraposo> ;)
Gerwin_J has quit [Quit: Gerwin_J]
<NiteHawk> ssvb: https://github.com/linux-sunxi/sunxi-tools/pull/43#issuecomment-218951760 - do you mind merging that PR now?
<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
<NiteHawk> ssvb: what's the status on https://github.com/linux-sunxi/sunxi-tools/pull/42 after jemk confirmed it works for A80?
<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
<ssvb> have you tried GCC 4.7.4 as mentioned in https://gist.github.com/ssvb/5f68caade9c76fd671f68135a6d96643 ?
JohnDoe_71Rus has joined #linux-sunxi
IgorPec has quit [Ping timeout: 260 seconds]
<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> you can try the crossdev command line from http://linux-sunxi.org/Toolchain#Gentoo and use 4.7.4 as the GCC version
<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]
medvid has quit [Ping timeout: 260 seconds]
massi_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
medvid has joined #linux-sunxi
merbanan has quit [Ping timeout: 276 seconds]
<montjoie> wens: I will check it
<montjoie> thanks
premoboss has joined #linux-sunxi
curlybracket has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
ganbold has quit [Ping timeout: 250 seconds]
iamfrankenstein has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
IgorPec11113 has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
<KotCzarny> woo-hoo, opi+2e shipped. awaiting delivery
<jelle> nice
IgorPec11113 has quit [Ping timeout: 240 seconds]
fredy has quit [Excess Flood]
IgorPec11113 has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
fredy has joined #linux-sunxi
<wens> so many boards from xunlong
<wens> should probably make a comparison table :p
<KotCzarny> wens, to be honest they have 2-3 boards, with optional configs :P
<jelle> hehe
<wens> KotCzarny: it's still confusing
<KotCzarny> yup
<jelle> I wonder when their a64 board comes out, it was rumoured they'd make one right?
<jelle> nice
<KotCzarny> Accoring to Steven, the H64 based OPIs also in production
<KotCzarny> info from 23th april
<KotCzarny> so the answer is 'soon'
* jelle has no hurry
<KotCzarny> i wonder how will they name it
<KotCzarny> opi3 ?
iamfrankenstein1 has joined #linux-sunxi
<wens> also a lot of rockchip boards lately
iamfrankenstein has quit [Ping timeout: 276 seconds]
iamfrankenstein1 is now known as iamfrankenstein
<JohnDoe_71Rus> KotCzarny: opiUM
<KotCzarny> orange pi UM ?
<KotCzarny> :)
<KotCzarny> orangpium
<wens> fake pine64 boards on taobao, really?
<KotCzarny> wens, lol, link?
kaspter has joined #linux-sunxi
IgorPec11113 has quit [Ping timeout: 260 seconds]
<wens> on cnxsoft, article was just posted
<KotCzarny> hehe, cnx posting about the sunxi_debug, 2 week old news :>
<KotCzarny> but at least honest description instead of social panic
<KotCzarny> nice price for a fake tho
<montjoie> wens: do you think split in two files could be a good idea ? sun8i_emac sun8i_ephy
hpeter has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
enrico_ has joined #linux-sunxi
<jelle> fake pine uh oh
<jelle> I wonder why I see yens
<KotCzarny> because its chinese site
<jelle> KotCzarny: hmm they use the same symbol as japanese yens?
<jelle> ohh TIL
<jelle> 40 euro.. that's steep :p
<apritzel> seriously, why would anybody fake a Pine64?
<KotCzarny> apritzel: because kickstarter team made some puclicity and are short on stock?
<apritzel> I am just wondering how you can make money out of the original Pine64, not to speak of a fake one ...
<KotCzarny> shipping
<KotCzarny> ;)
<apritzel> also is it really that popular that people crave for it?
<KotCzarny> apritzel, apparently someone thinks it is
<apritzel> except NiteHawk, that is ;-)
<wens> montjoie: the syscon/ephy code is 100 something lines, only called in _init/_uninit
<NiteHawk> apritzel: :P
<wens> montjoie: not sure what you gain from splitting it out
<NiteHawk> is that to suggest you already sent me a fake one? :D
<KotCzarny> is there any benchmark between h3 and a64?
<apritzel> NiteHawk: oh, you got me. I un-soldered the A64 from it and put an H64 on it and now sell the A64 on eBay ..
RzR has joined #linux-sunxi
<NiteHawk> apritzel: i figured as much...
<apritzel> KotCzarny: apparently H3 and A64 are the same die
<apritzel> just different bins
<apritzel> *H64*
<apritzel> I meant
<KotCzarny> apritzel, so their speeds should be roughly the same at the same clock?
<apritzel> KotCzarny: not roughly, but exactly
<apritzel> the H64 requires (even) more cooling, apparently
<KotCzarny> no point in wooing a64 then (apart from being groundbreaking into 64bit territory)
<apritzel> it's supposedly cheaper
<wens> ccaione: thanks for the heads up
<apritzel> NiteHawk: also faking the label print on the SoC was quit a pain ;-)
<apritzel> *quite*
<wens> remarked processors lol
<NiteHawk> apparently you did quite a good job there :)
<KotCzarny> well, opi1 is 9.99usd+3.64usd shipping
<KotCzarny> can you find cheaper a64based board?
<KotCzarny> i mean opi1 is h3
premoboss has quit [Quit: Sto andando via]
<apritzel> KotCzarny: how long does it take them to ship the OPi to Europe?
<apritzel> three weeks?
<KotCzarny> 7-15 days according to aliexpress
<KotCzarny> ahm,
<KotCzarny> Delivery: 15-34 days (ships out within 7 business days)
<KotCzarny> wonder what's the difference
<KotCzarny> probably boards are still in the furnace ;)
reev has quit [Ping timeout: 244 seconds]
<KotCzarny> anyway, i'll let you know how long it took for my opi+2e to arrive
<apritzel> KotCzarny: cheers!
<ssvb> my opipc had been delivered surprisingly fast, took only slightly more than 1 week
kaspter has quit [Ping timeout: 260 seconds]
luoyi has quit [Quit: Page closed]
<apritzel> ssvb: ah, good to know, I was tempted to order that one (best price/performance ratio, AFAICT)
<apritzel> ssvb: I got two SOIC8's yesterday :-P
<ssvb> lucky you :)
<apritzel> and hey, I also ordered two of those from the very seller on Monday, also still waiting
<agraf> ssvb: i still have a few in my closet
<agraf> ssvb: how far away do you live? :p
<wens> got psci_arch_init() working in C, though it is very ugly :p
<KotCzarny> wens: uglier than bsp code?
<KotCzarny> if not its the upgrade
<KotCzarny> ;)
<wens> you can see for yourself :p
<KotCzarny> cant review, asm is still black magic to me :P
<apritzel> KotCzarny: but this one is in C ;-)
<KotCzarny> this c is the kind of the c that would shoot you in the foot with your head. twice.
<wens> C with a whole lot of inline assembly :p
<KotCzarny> wolf in the sheep's clothes :P
<agraf> wens: why not just use a small asm trampoline to save/restore your non-volatile regs?
<agraf> wens: and call a c function from there
tsuggs has quit [Ping timeout: 276 seconds]
* apritzel was just thinking the same
<apritzel> was is the point of having a C function with some writel's and a lot of inline assembly
<apritzel> it's not portable anyway
<agraf> wens: the C compiler will make sure that registers 19-28 are in the same state at the end of a function call as they were when you entered it
<agraf> wens: so if you just move the few registers that you want to preserve into those, then do a bl to your c function, then restore them
<agraf> wens: you basically have everything you need ;)
<agraf> wens: or am i missing something?
<agraf> oh, wait, armv7
<agraf> wens: that document then ;)
<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: again, block sizes differ, known-good commands for erase/write differ, etc
<ssvb> agraf: ^
<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 ;-)
<apritzel> ... lunch
<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
<montjoie> so perhaps I have some problem
<KotCzarny> or its just too slow
<KotCzarny> and too simple
<montjoie> KotCzarny: the speed is not bad in my memory
<KotCzarny> i meant that algo used by that hwrng is not random at all (doesnt use physical source)
<KotCzarny> or you have some bug, and some registers are reset
ornitorrincos has quit [Ping timeout: 264 seconds]
tach_ has joined #linux-sunxi
cosm has quit [Ping timeout: 260 seconds]
ornitorrincos has joined #linux-sunxi
ornitorrincos has quit [Changing host]
ornitorrincos has joined #linux-sunxi
<MoeIcenowy> oh
<MoeIcenowy> when running mainline kernel on qemu's cubieboard emulation
<MoeIcenowy> it seems that some division by zero exceptions occured in mmc driver
<plaes> got traceback?
<MoeIcenowy> (The functionality of the emulation is very low, seems to only consists of A8 core, UART, AHCI
<MoeIcenowy> and EMAC
p1u3sch1_ has quit [Ping timeout: 244 seconds]
RzR has quit [Changing host]
RzR has joined #linux-sunxi
p1u3sch1 has joined #linux-sunxi
tomboy65 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 246 seconds]
<Amit_T> Has rsb initialized properly on pine64?
keesj has quit [Quit: leaving]
lemonzest has quit [Quit: Leaving]
<apritzel> Amit_T: ???
cnxsoft has quit [Quit: cnxsoft]
jernej has joined #linux-sunxi
Sakami_ has joined #linux-sunxi
<Amit_T> apritzel: I mean how to make sure that RSB has intialized so that pmic can be drived ?
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<Amit_T> Sorry if its just stupid question.
IgorPec11113 has joined #linux-sunxi
<apritzel> Amit_T: If I would know the answer I would be happy ;-)
<Amit_T> ok, also not able to find any reference of axp803 in u-boot source, is it not supported in u-boot ?
<apritzel> Amit_T: that's the whole point, the AXP is completely driven by the SCP code running on the OpenRISC arisc/CPUS core
<apritzel> which is not the worst idea, but horribly (and wrongly) implemented
<Amit_T> we want to leave out arisc out of picture ?
IgorPec11114 has joined #linux-sunxi
IgorPec11113 has quit [Ping timeout: 265 seconds]
<apritzel> for the moment I am hoping to program the PMIC once and for all in ATF
p1u3sch1 has quit [Ping timeout: 250 seconds]
<apritzel> eventually I would like some generic firmware interface to power regulators on
<apritzel> without providing details like the required voltage or the specific address of the regulator
<apritzel> more like: Dear firmware, please power on the PHY!
IgorPec11115 has joined #linux-sunxi
<Amit_T> ok, also I didn't get what it mean by , peripherals with the R_* prefix are going to be controlled by the OpenRISC core ?
<KotCzarny> dear: machine, please provide authentication key
IgorPec11114 has quit [Ping timeout: 252 seconds]
tach_ has quit [Quit: WeeChat 0.4.2]
ddc has joined #linux-sunxi
sonodivenutomort has joined #linux-sunxi
<ddc> Hi everyone I'm looking for an Alchemy au1300 databook or BSP, wondering if someone would be able to help?
jstein has joined #linux-sunxi
<ddc> meaning?
<plaes> start here
<plaes> otherwise noone knows what's Alchemy au1300
<plaes> besides, are you sure it actually has arm soc?
<ddc> plaese: thanx for the reply here is the https://en.wikipedia.org/wiki/Alchemy_%28microarchitecture%29
SJRvanSchaik has quit [Read error: Connection reset by peer]
<ddc> it is not an ARM it is MIPS32
<plaes> then why are you asking it here?
IgorPec11115 has quit [Ping timeout: 265 seconds]
<KotCzarny> :)
<KotCzarny> because friday
<plaes> yeah.. I'm a bit grumpy :P
<ddc> plaes : good question? I'm currently working on sun4i CSI driver and I came across this http://read.pudn.com/downloads76/sourcecode/others/288595/au1200_databook.pdf
IgorPec11115 has joined #linux-sunxi
<ddc> if you had a look at the CSI in the allwinner sun4i int the user manual you will understand
<ddc> why I'm asking this question
pietrushnic has quit [Quit: Coyote finally caught me]
<ddc> I looks like Allwinner is using the same IP
<ddc> more or less
<ddc> plaese: I hope you got my point
IgorPec11115 has quit [Ping timeout: 276 seconds]
<plaes> cool
<plaes> it has same register mapping?
<ddc> not really but you can get more meaninfull inforamtion for AMD datasheet
<ddc> what is really intersting the MAE block
<plaes> yup
<ddc> RMI has added h264 to the MAE in the au13xx series that why I'm looking for the data sheet
<ddc> I guess it may somehow help with understanding VE
<ddc> The fate of Alchemy SoC is so far unknown https://www.linux-mips.org/wiki/Alchemy
<ddc> but I would say CIM is more like the CSI in sun5i
<plaes> yeah, good luck getting anything from Broadcom
nove has joined #linux-sunxi
IgorPec has joined #linux-sunxi
<ddc> I know that but I was hoping that someone may had access to the datasheet from NetLogic Microsystems or RMI
heffer has quit [Ping timeout: 250 seconds]
sonodivenutomort has quit [Quit: Sto andando via]
gzamboni has quit [Ping timeout: 276 seconds]
heffer has joined #linux-sunxi
jernej has quit [Quit: Konversation terminated!]
reinforce has quit [Quit: Leaving.]
<nove> funny name
gzamboni has joined #linux-sunxi
<nove> media acceleration engine
<nove> ours video engine is sometimes referred as Media ACCelerate (macc)
<nove> they are both the same type of fixed function hardware
<ddc> may be not quite sure yet.
<nove> with very similar register bitfields, but complete different in others ways
ganbold has joined #linux-sunxi
<ddc> yup I can see that
<nove> dated 2005
<ddc> Alchemy was a big thing at the time
<ddc> it could be that Allwinner used it with some glue logic
<nove> is too old, maybe the best far fetched guess, is that was designed by the same people
<ddc> possible
<nove> we have indices that our video engine as designed by chipsbank, with does hardware designs for other socs vendors
Nacho_ has joined #linux-sunxi
<ddc> I've n't looked deeply into VE but the CIM and CSI are somehow similar
zuikis has joined #linux-sunxi
<ddc> some of the registers description has the same wording
vagrantc has joined #linux-sunxi
<nove> MAE backend scaler also looks similar to our VE isp subengine scaler, the part about scale filter coefficients
<nove> which we still don't know how to calculate them, (because of laziness)
* nove will read more in depth
<ddc> I hope you will find this information so you can speed up the development. Please let me know if you can find any info about au13xx
<ddc> I hope you will find this information usefull
<nove> ddc: thanks for the hit
reinforce has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 260 seconds]
iamfrankenstein1 is now known as iamfrankenstein
tipo has quit [Remote host closed the connection]
gzamboni has quit [Ping timeout: 244 seconds]
apritzel1 has joined #linux-sunxi
tipo has joined #linux-sunxi
formruga has quit [Quit: Konversation terminated!]
tipo has quit [Quit: Leaving]
gzamboni has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
apritzel1 has quit [Ping timeout: 244 seconds]
<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]
Netlynx has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
<nove> has nothing new in the scaler description
Amit_t_ has quit [Ping timeout: 250 seconds]
<nove> starts to make sense, now this is only a question of understanding the math of an 4-tap polyphase filter
<KotCzarny> all i can say its magic
paulk-collins has joined #linux-sunxi
oneinsect has quit [Ping timeout: 250 seconds]
Andy-D has quit [Ping timeout: 240 seconds]
staplr has joined #linux-sunxi
Nacho_ has quit [Remote host closed the connection]
Nacho_ has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
staplr has quit [Ping timeout: 276 seconds]
staplr has joined #linux-sunxi
Andy-D has joined #linux-sunxi
<ddc> nove: the following link contains a patch for the Alchemy au1xxx it contains a proper license.
ddc has quit [Quit: Page closed]
IgorPec has quit [Ping timeout: 246 seconds]
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
paulk-collins has quit [Quit: Leaving]
raknaz has joined #linux-sunxi
raknaz has quit [Ping timeout: 240 seconds]
raknaz has joined #linux-sunxi
staplr has quit [Remote host closed the connection]
raknaz has quit [Quit: raknaz]
reinforce has quit [Remote host closed the connection]
iamfrankenstein has quit [Quit: iamfrankenstein]
apritzel has joined #linux-sunxi
zuikis has quit [Remote host closed the connection]
Andy-D has quit [Ping timeout: 246 seconds]
Andy-D has joined #linux-sunxi
nove has quit [Quit: nove]
jstein has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
fdcx has quit [Ping timeout: 276 seconds]
fdcx has joined #linux-sunxi
clonak has joined #linux-sunxi