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
mosterta|2 has quit [Ping timeout: 276 seconds]
apritzel has quit [Ping timeout: 244 seconds]
TheSeven has quit [Ping timeout: 276 seconds]
TheSeven has joined #linux-sunxi
<lvrp16> dave0x6d: depends on what your requirements are, the 3.4 kernel from armbian is pretty comprehensive
tsuggs has joined #linux-sunxi
<dave0x6d> lvrp16: is it decently maintained though?
<lvrp16> yes
<dave0x6d> lvrp16: Does armbian have it's own repos, or does it use Debian?
<lvrp16> some from armbian some from debian if i recall correctly. tkaiser can correct me if I am wrong.
<dave0x6d> heh, this annoys me :p
<dave0x6d> wget -q -O - http://upgrade.armbian.com | bash
<dave0x6d> not even HTTPS =(
KotCzarny has quit [Ping timeout: 265 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
lennyraposo has quit [Quit: Leaving.]
kaspter has joined #linux-sunxi
ninolein has joined #linux-sunxi
ninolein_ has quit [Ping timeout: 276 seconds]
lennyraposo has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
testing has joined #linux-sunxi
testing is now known as Guest18284
<willmore> lennyraposo, I will be getting a pine64 this week, what does a total noob need to read to get started? I don't need video out, just network.
<lennyraposo> well in development?
<lennyraposo> told ot study the dts files
<lennyraposo> understand the hierchy
<lennyraposo> or just getting your board up and running?
<lennyraposo> if that's the case
<lennyraposo> longsleep's image build is a good place to start
<lennyraposo> he has base image for xenial
<lennyraposo> or if you prefer to do your own hsi simple image is agreat place to start
<lennyraposo> but for learning I would say looking at his github is agood place to staart to get familiar
<lennyraposo> I'm just experimenting with what does what at this time
<lennyraposo> reviewing the history of changes on things to see what is going on to better understand
KotCzarny has joined #linux-sunxi
<lennyraposo> this will help
<lennyraposo> it's based on his current work
<lennyraposo> if there is anything more I am still not at that level to dictate what comes next
<lennyraposo> aprtizel is a cornucopia of knowledge
<lennyraposo> stuff I'm not familiar with yet
<lennyraposo> he's believes mainline is the more important goal
<lennyraposo> and he is right
<lennyraposo> my understanding is that there are a few obstacle sat this time
<lennyraposo> things that require a bit of digging into especially with the u-boot portions (boot0)
<willmore> Sorry, for the delay, lennyraposo, I was catching up 12 hours of logs.
<lennyraposo> network (gmac) is last I checked still a wip
<willmore> So, BSP for now?
<lennyraposo> but apparently similar to the H3
<lennyraposo> montjoie can probably give you details in his battles with that
<lennyraposo> USB last I read apritzel had something but it isn't funcitonign yet
<willmore> I've been reading, so most of those are familiar issues.
<willmore> Okay, mainline is the goal, but it's not ready, yet. Hmm, wonder if I can find something useful to do.
<lennyraposo> I test
<lennyraposo> I look at things
<willmore> You look for things? Things that make us go?
<lennyraposo> try out different recipes when compiling a kernel/u-boot
<willmore> Gotcha.
<lennyraposo> try to understand what makes thigns tick
<willmore> Okay, I'll go do some reading and see where that leaves me.
<willmore> Thanks, lennyraposo.
<lennyraposo> ATF
<lennyraposo> Arm Trsuted Firmware
<willmore> I may actually have time to read and do things now that the two weeks of in-laws, my family, and childrens birthdays are over.
<lennyraposo> hehe
<lennyraposo> brb
<willmore> Yeah, ATF is always an issue. The odroid people are having issues with it as well. It's a great idea, horrible implementation.
Guest18284 has quit [Ping timeout: 250 seconds]
<lennyraposo> yep
<lennyraposo> now I may be getting this wrong but if I understood correctly
<lennyraposo> ATF will/can simplify a lot
luoyi has joined #linux-sunxi
<lennyraposo> perhaps someone who knows better can chiime in if I am getting it wrong
ganbold has quit [Quit: Leaving]
<luoyi> any one knows something about the oob interrupts in the brcm driver ?
<lennyraposo> broadcom wireless?
ganbold has joined #linux-sunxi
<lennyraposo> wish I could help you but I'm afraid I am lacking in that department
<lennyraposo> ;)
<luoyi> in the bpi m1+, I use interrupts = <7 15 0x00000008>; and in the cubietrunk, we use interrupts = <10 8>; /* PH10 / EINT10 */
<luoyi> can some body give me a hint on how to get the right value about this .
<wens> it should be <bank pin flags>
<wens> PH10 -> <7 10 FLAGS>
<lennyraposo> any documentation
<lennyraposo> willmore
<lennyraposo> soem of the stuff that longsleep did
reev has joined #linux-sunxi
<lennyraposo> he was able to get values from the Docs were up on the site
<lennyraposo> for the DTS
luoyi has quit [Ping timeout: 250 seconds]
p1u3sch1 has quit [Ping timeout: 276 seconds]
p1u3sch1 has joined #linux-sunxi
vickycq has quit [Ping timeout: 260 seconds]
vickycq has joined #linux-sunxi
IgorPec has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
IgorPec has quit [Ping timeout: 252 seconds]
<lennyraposo> hey longsleep are you about?
engideavr has joined #linux-sunxi
engideavr has quit [Quit: Konversation terminated!]
engideavr has joined #linux-sunxi
Graf_Ithaka has joined #linux-sunxi
luoyi has joined #linux-sunxi
<luoyi> sorry, I've left for a while for lunch
<luoyi> it should be <bank pin flags>
<luoyi> I've read the log, and which secion should I look up ? I've A20 User Manual on my hands
prasannatsm has joined #linux-sunxi
<wens> could you elaborate?
<wens> which pin the OOB is hooked up to depends on the board design
<KotCzarny> just go to http://linux-sunxi.org/GPIO
<wens> so you need to look at the schematics
<luoyi> I've download the M1+'s schematic file. can't find how the sdio wifi chip connect to the cpu
<KotCzarny> wifi connects via usd i think
<KotCzarny> if its in lsusb
<KotCzarny> s/usd/usb/
<luoyi> bpi m1+ use brcmfmac driver, and it's a sdio wifi card. not a usb card
<KotCzarny> ahm
IgorPec has joined #linux-sunxi
<luoyi> because in the bpi M1+, I've to use interrupts = <7 15 0x00000008> ,which is differ from that patch. so I don't know how to get the right value of that line
<luoyi> away for a while.
prasannatsm has left #linux-sunxi ["Part"]
<wens> pine64 finally arrived
<wens> surface mail... sheesh
<lennyraposo> hehe
<wens> also the "R.O.C" portion of the mailing address was redacted lol
<lennyraposo> still awaiting the rest of my shipment
<lennyraposo> a lot to do for their campaign I suppose
<KotCzarny> wens, maybe that was the reason of the delay, lots of hand made art work ;)
<wens> IR receiver sticks up too high for the case :p
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
<wens> the case is huge compared to other boards :/
akaizen_ has joined #linux-sunxi
akaizen has quit [Ping timeout: 240 seconds]
Gerwin_J has joined #linux-sunxi
IgorPec has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
IgorPec has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
IgorPec has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
<luoyi> back now
<luoyi> any one familiar with brcmfmac driver can give me some hint ?
IgorPec has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
reev has quit [Read error: Connection reset by peer]
reev has joined #linux-sunxi
KotCzarny has quit [Ping timeout: 265 seconds]
<wens> doesn't the cubietruck dts already have it
<wens> use that as an example
reev has quit [Ping timeout: 252 seconds]
<luoyi> well, cubietrunk's interrupts line is : interrupts = <7 10 IRQ_TYPE_LEVEL_LOW>;
<luoyi> and bpi m1+'s interrrupts line is : interrupts = <7 15 0x00000008>
<wigyori> Date: Sat, 24 May 2014 20:53:49 +0200
<wigyori> that's probably an old one, not sure if it was updated since
<luoyi> well, I've used this value to get my dtb file, and wifi is working well
<wigyori> mkay
<luoyi> it says: , with the interrupt pin number modified according to the schematic diagram
<luoyi> don't know what's the excat interrupt pin number means
IgorPec has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
massi_ has joined #linux-sunxi
KotCzarny has joined #linux-sunxi
reev has joined #linux-sunxi
<wens> 7 == H, so <7 10 X> is EINT on pin PH10
<wens> luoyi: exact interrupt pin number means whatever pin (ex. PH10) the OOB interrupt line from the brcm chip is connected to
<wens> it is something in the board design
FlorianH has joined #linux-sunxi
caog has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel> willmore: what makes you think ATF is a horrible implementation? (just asking)
<Amit_T> apritzel: Hello, Just to check that how do I make sure that PHY is really powered up, I see that there is no special PHY driver is required and Gen PHY driver should be enough.
<apritzel> Amit_T: that is the million dollar question ;-)
<KotCzarny> multimeter?
<KotCzarny> :>
<wens> afaik the LEDs will start flashing if the PHY is powered
<Amit_T> apritzel: ok, any thing I could try in this regard ?
vickycq has quit [Ping timeout: 252 seconds]
<apritzel> wens: Is it? Does the PHY without initialization and programming drive the LEDs according to the link status?
<Amit_T> wens: In case of orangepi pc , if we set proper emac clock , LEDs will start flashing
<apritzel> Amit_T: as KotCzarny said: you could try a multimeter if you have one
<apritzel> Amit_T: also digging through some BSP crap to see which regulator rail the driver enables
<wens> apritzel: i thinks it what the PHY does by default, but of course it is configurable
<wens> Amit_T: yes
vickycq has joined #linux-sunxi
FlorianH has quit [Ping timeout: 244 seconds]
premoboss has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
yann|work has joined #linux-sunxi
yann|work is now known as yann
<luoyi> wens: thanks for your explain. but I can't find the wifi oob interrupt line or flag in the cubietrunk schematic diagram file
<wens> there's a line named "WIFI-HOST-WAKE"
<luoyi> in the wifi&bt page, it just says: SDIO-D1/SDIO-D2/.../WL-HOST-WAKE and so on ...
<luoyi> OK, I'll give a check
IgorPec has quit [Read error: Connection reset by peer]
<luoyi> OK, find this line, but how can I know that it connect to PH7 ?
<luoyi> hmmm.. great
<luoyi> page 2
IgorPec has joined #linux-sunxi
<luoyi> and in bpi m1+'s schematic , it's PH15
<luoyi> wens: very thanks for your explainaion.
caog has left #linux-sunxi ["Ex-Chat"]
ricardocrudo has joined #linux-sunxi
IgorPec has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
FlorianH has joined #linux-sunxi
juri_ has quit [Ping timeout: 260 seconds]
creemj has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
hrw has left #linux-sunxi [#linux-sunxi]
juri_ has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
FlorianH has quit [Ping timeout: 260 seconds]
webmind has quit [Ping timeout: 260 seconds]
matthias_bgg has joined #linux-sunxi
kaspter has joined #linux-sunxi
andoma has quit [Remote host closed the connection]
andoma has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 252 seconds]
iamfrankenstein1 is now known as iamfrankenstein
<igraltist> hi
<igraltist> i use on cubietruck the wifi as accesspoint with kernel 4.4.9. when i set this ht_capab=[HT40] the connection always stall after short time inactivity. without this all running fine.
<igraltist> so could the chip become to hot because somehow powersave does not work?
ricardocrudo has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
<wens> i've not tried this, but it seems more of a problem with the chip itself?
<oliv3r> lo
arete74_ has quit [Ping timeout: 260 seconds]
Tusker has joined #linux-sunxi
arete74 has joined #linux-sunxi
<luoyi> does your dmesg have 'brcmfmac: power management disabled' such line ?
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
<igraltist> luoyi: i dont have such line
paulk-collins has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
tsuggs has quit [Ping timeout: 276 seconds]
<luoyi> igraltist: maybe you can try to disable the power management
tsuggs has joined #linux-sunxi
<Tusker> FYI: I'm just testing an autobuild script for the BPiM3 (builds a bootable SD card, with jessie installed) - http://pastebin.com/a5zqELgZ
<Tusker> any comments would be appreciated
<KotCzarny> tusker: post it to armbian forums maybe?
<Tusker> yeah, that might be a good idea
<KotCzarny> hrm
<KotCzarny> which package provides 'mount' in diablo?
staplr has joined #linux-sunxi
nabblet has joined #linux-sunxi
<nabblet> hi, I installed gentoo (with your sunxi modfied u-boot and kernel) and saw that you now recommend going mainline for u-boot and kernel if the server is headless (which is the case for me). What upgrade path do you recommend?
<nabblet> Do you know of any incompatibilites between certain versions of uboot and the linux kernel (also taking in account that right now i am using the sunxi mods)
tkaiser has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
<tkaiser> lvrp16: Regarding Armbian repos. We use an own for u-boot, kernel and board support package (other stuff like Cedrus accelerated video players might follow) but for the main stuff the repositories configured through /etc/apt/sources[.d] are used (defaulting to standard locations for Debian and Ubuntu)
reinforce has joined #linux-sunxi
<nabblet> My question is also motivated by "While the mainline kernel should work on any bootloader (with the major exception being the A20), you'll need a recent sunxi U-boot, or even better a Mainline_U-boot." from https://linux-sunxi.org/Mainline_Kernel_Howto
Gerwin_J has quit [Quit: Gerwin_J]
staplr has quit [Remote host closed the connection]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
FlorianH has joined #linux-sunxi
<willmore> apritzel, Just that it's meant to be a trusted bit of code that always runs on a little processor that has god like control of the SoC, but the code on it is written at the last minute and is likely buggy as all hell. One could write a very nice ATF, but I don't see that happening a lot.
<willmore> Has anyone seen an STL file for a Pine64 case, yet? :)
arossdotme has quit [Ping timeout: 252 seconds]
IgorPec has joined #linux-sunxi
Shirasaka-Hazumi has quit [Ping timeout: 260 seconds]
arossdotme has joined #linux-sunxi
<willmore> Found a nice plain one: http://www.thingiverse.com/thing:1428977
Shirasaka-Hazumi has joined #linux-sunxi
book`_ has quit [Quit: Leaving]
<apritzel> willmore: I think you are mixing things up here: ATF is running on the ARM cores, not the arisc
<apritzel> also it's not "last minute and buggy as hell", it's a proper OpenSource project (driven by ARM) and actually used my the majority of ARM64 server boards out there
<apritzel> for instance it cares about errata workarounds and the proper sequence of suspending and resuming CPUs (taking care of the GIC setup, for instance)
<apritzel> willmore: were you be any chance referring to that Allwinner SCP blob, which runs on the arisc
<apritzel> ?
<willmore> apritzel, I'm thinking of the bit of code that runs on a little Cortex-M(something) in many SoCs--like the S905 and handles a lot of low level settings of the SoC.
<apritzel> willmore: yeah, that's not ARM trusted firmware
<willmore> Okay, sorry for the misunderstanding, then.
<apritzel> ARM Trusted Firmware is AArch64 only and it runs in EL3 on the ARM cores
<willmore> What does it do?
book` has joined #linux-sunxi
<apritzel> initializing the cores and the interrupt controller, and providing PSCI services (=SMP bringup)
<willmore> Okay, that's useful.
<apritzel> traditionally U-Boot tends to cover those things on ARM(32) cores in the past
<apritzel> willmore: also it cares for errata workarounds
<apritzel> it gets updated with the latest erratas and may enable chicken bits or the like to fix them
<apritzel> think of what the core BIOS code does on a PC
<apritzel> the good thing is that you can hide all those nasty details of a SoC specific setup in firmware
<apritzel> and _any_ operating system can just use it easily
<apritzel> and for the SCP bits (Allwinner code running on the arisc): I guess you are right, that's why I removed it from my latest image
<apritzel> (and coded some of its functionality in ATF)
<willmore> Understood. What are 'chicken bits'?
<apritzel> bits in the core that enable or disable certain optimizations
<apritzel> so if you introduce a new feature, say an agressive prefetcher or branch predictor, you add bits in the core to disable it
<apritzel> so in case something goes wrong (a bug is found, which is not unlikely if it's new _and_ agressive), you can turn this feature off
<apritzel> and ship the silicon anyway
<willmore> Handy. Thanks for the education.
Tusker has quit [Quit: Time wasted on IRC: 2 hours 45 minutes 12 seconds]
<apritzel> you wouldn't believe how useful this has been in the past - for every chip vendor out there
<willmore> Looks like there was a lot done right in AARCH64.
<apritzel> willmore: here you see some "chicken bits:" http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0488h/way1382037666700.html
reev has quit [Ping timeout: 244 seconds]
juri_ has quit [Ping timeout: 252 seconds]
<willmore> apritzel, yeah, that's deep into the weeds.
juri_ has joined #linux-sunxi
<ssvb> apritzel: "the good thing is that you can hide all those nasty details of a SoC specific setup in firmware" <- this is good as long as we still have full control over what's going on there
<ssvb> which is not the case for ODROID boards
<apritzel> but works for OpenSource firmware like ATF
<ssvb> yeah, this is called https://en.wikipedia.org/wiki/Tivoization
<ssvb> and even worse, we don't have the exact sources for these firmware blobs
<apritzel> but Allwinner does not prevent running modified versions of "their" firmware (if you happen to have the matching source)
<ssvb> yes, Allwinner is a very rare exception
<apritzel> so the ODROID firmware is signed?
<ssvb> I believe that they have a signed boot0 equivalent and an open source U-Boot - http://odroid.com/dokuwiki/doku.php?id=en:c2_building_u-boot
<ssvb> though I'm not sure about it being signed in C2, it could be just a binary blob
<ssvb> probably somebody can try to patch it and see if it still boots :-)
<apritzel> it says: "Bootloader signing process is not necessary for ODROID-C2 at all. "
<apritzel> whatever that means exactly ;-)
<ssvb> it means that signing is not needed for U-Boot
<apritzel> and it looks like they describe how to build their U-Boot branch and run this, so I guess that works
<apritzel> ssvb: yeah, but that bl1.bin.hardkernel is signed, I guess
<ssvb> willmore: if you have a C2 board, then maybe you can try to patch one of the text messages inside of the bl1.bin.hardkernel binary, write it to the SD card and check if the system still boots
<ssvb> willmore: if it boots, then it will be technically possible to eventually have an open source firmware for it
<ssvb> willmore: but again, there may be a checksum in the header, so it's not completely trivial...
<ssvb> apritzel: the samsung based odroids used to rely on blobs signing - http://odroid.com/dokuwiki/doku.php?id=en:u3_building_u-boot
<rtp> odroid c2 is s905 versus samsung for the others iirc
<ssvb> yes, amlogic may be less evil than samsung :-)
<ssvb> of course, normal users don't really care about these things, and signed binary blobs allow the SoC vendors to hide any kind of crap there
apritzel1 has quit [Ping timeout: 244 seconds]
<apritzel> ssvb: well, "any kind of crap" sound like usual semiconductor business - you mess it up, get embarrassed, put something in firmware
<apritzel> not sure that's really evil
<apritzel> as I mentioned the other day: if it sets some secret chicken bits on power up and does some "magic" initialization here and there and then _stays out of the way_ for the rest, I am not so much against firmware blobs
premoboss has quit [Quit: Sto andando via]
<ssvb> apritzel: in GP variants of OMAP3 and OMAP4, the boot ROM was dropping the CPU into the non-secure mode before passing control to the bootloader
<apritzel> ssvb: yeah, I know, there was all kind of trouble with this in the past
* apritzel prefers to not look back too much if possible
<apritzel> that's why I kind of like Allwinner in this respect: they are unbrickable and one can completely replace the firmware
cnxsoft has quit [Quit: cnxsoft]
<wens> the brom is sane, if not really flexible
juri_ has quit [Ping timeout: 276 seconds]
premoboss has joined #linux-sunxi
juri_ has joined #linux-sunxi
Amit_t_ has joined #linux-sunxi
nabblet has quit [Quit: leaving]
<apritzel> wens: ah, good to know, has someone looked at it more thoroughly already?
premoboss has quit [Quit: Sto andando via]
<wens> i think we have sources for some, disassembled and annotated versions of others
alain__ has joined #linux-sunxi
<alain__> Quick question with Armbian running on OPI Plus, will I get both USB and Ethernet with the mainline kernel?
<montjoie> alain__: no
<alain__> too bad :) Any sight of your ethernet driver making it to mainline?
<montjoie> need concensus on how to "driver" PHY
apritzel1 has joined #linux-sunxi
nove has joined #linux-sunxi
alain__ has quit [Quit: Page closed]
<wens> the phy and syscon bits will most likely be folded into the driver
pietrushnic is now known as pietrushnic`away
<wens> i will make time to do the modifications
pietrushnic`away is now known as pietrushnic
tkaiser has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
lemonzest has joined #linux-sunxi
jernej has joined #linux-sunxi
Andy-D has quit [Ping timeout: 260 seconds]
<igraltist> btw, what is a good hz frequenzy for the cubietruck in kernelconfiog?
<willmore> ssvb, I'll give that a try later this week when I get my SBC 'farm' back up. The 3D printer evicted them from where they had been.
<montjoie> wens: do you want that I do it ?
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
apritzel1 has quit [Ping timeout: 244 seconds]
Andy-D has joined #linux-sunxi
zuikis has joined #linux-sunxi
adj__ has quit [Ping timeout: 276 seconds]
yann has quit [Ping timeout: 260 seconds]
adj__ has joined #linux-sunxi
massi_ has quit [Read error: Connection reset by peer]
Andy-D has quit [Ping timeout: 265 seconds]
vagrantc has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
Ultrasauce has joined #linux-sunxi
massi_ has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
jstein has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
jstein has quit [Remote host closed the connection]
avph has joined #linux-sunxi
FlorianH has quit [Ping timeout: 260 seconds]
avph has quit [Ping timeout: 260 seconds]
IgorPec has quit [Ping timeout: 265 seconds]
staplr has joined #linux-sunxi
avph has joined #linux-sunxi
buZz has quit [Ping timeout: 244 seconds]
avph has quit [Ping timeout: 260 seconds]
buZz has joined #linux-sunxi
buZz is now known as Guest43496
Guest43496 is now known as buZz
avph has joined #linux-sunxi
massi_ has quit [Remote host closed the connection]
avph has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
cosm has joined #linux-sunxi
prasannatsm has joined #linux-sunxi
FlorianH has joined #linux-sunxi
bmeneg has joined #linux-sunxi
<bmeneg> hello everyone, are there any way to know where a GPIO pin is being used on my board? I mean, I would like to use a specific pin as normal GPIO, but the kernel reports me it is already in use, I would like to know who (which kernel module) is using it.
<bmeneg> board: cubietruck, kernel: 3.4.79-sun7i NAND version.
Andy-D has joined #linux-sunxi
Amit_t_ has quit [Ping timeout: 250 seconds]
<NiteHawk> bmeneg: for a 3.4.x kernel you should probably start by investigating the configuration in the .fex file - http://linux-sunxi.org/Fex_Guide
prasannatsm has quit [Ping timeout: 260 seconds]
prasannatsm has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
<bmeneg> NiteHawk, the problem is I would like to use some pins as GPIOs that I had already configured on .fex file.. other places has the same pin number, but the module is not even being used, like "[mmc_para] ... sdc_used = 0"
<NiteHawk> hmm... probably depends on the kernel whether it still 'claims' the gpio pin in question. for a test it should be simple enough to remove the "offending" definition from the .fex completely
<bmeneg> let me see. I'll try with PG00, which was declared as 'gpio_pin_9 = port:PG00<1><default><default><1>' on fex.
<bmeneg> so 'echo 9 > /sys/class/gpio/export' should work, right?
prasannatsm has quit [Ping timeout: 244 seconds]
<bmeneg> NiteHawk, same results: sunxi_gpio_request can't request '[gpio_para]' '', already used ?
<NiteHawk> i'm not sure which numbering scheme the 3.4 kernel uses there. PG00 might also be (6 * 32 + 0) = 192; if that's the cases you're asking for "PA09" with 9
<bmeneg> NiteHawk, at https://linux-sunxi.org/GPIO says 3.4 schema uses the number after "gpio_pin_" declaration, this one you presented is true to the mainline kernel, but I'll try it anyway.
<NiteHawk> yes, according to http://linux-sunxi.org/GPIO#Accessing_the_GPIO_pins_through_sysfs_on_sunxi-3.4 your approach is right
<bmeneg> NiteHawk, both ways didn't work.
<bmeneg> =/
<bmeneg> I'll try to export from 0 to 500 and see what happens.
mossroy has joined #linux-sunxi
prasannatsm has joined #linux-sunxi
<bmeneg> NiteHawk, just PH20 and PB18 were exported successfully.
<bmeneg> ;/
<bmeneg> nothing about PG00.
<NiteHawk> :D well... you probably have to dig up what else claims the other gpios, or you might need to make them available explicitly (by adding pin definitions to the .fex)
apritzel has joined #linux-sunxi
<NiteHawk> reading the GPIO page gives me the impressions the latter is actually a required step
avph has quit [Ping timeout: 260 seconds]
<bmeneg> NiteHawk, the latter? I already explicitly added 67 GPIOs on .fex
<NiteHawk> oh. i thought you might not have done that yet - but that's a different picture then. can you pastebin the .fex?
prasannatsm has left #linux-sunxi ["Part"]
apritzel has quit [Ping timeout: 244 seconds]
<bmeneg> NiteHawk, yep.. just a sec.
avph has joined #linux-sunxi
FlorianH has quit [Quit: Leaving]
<NiteHawk> you're missing gpio_pin_4 - maybe .fex compiler or kernel choke on that, or the resulting mismatch in gpio_num ?
<bmeneg> as you can see lots pins were declared explicitly. others didn't, because I'm using them somehow different from GPIO, for instance UART or SPI pins.
<bmeneg> NiteHawk, Hmm... that's a good point .
<ssvb> bmeneg: PH10 is used in the wifi_para section, and it probably clashes with your gpio_pin_2 = port:PH10<0><default><default><0>
<ssvb> bmeneg: I would not be surprised if this gpio list is only parsed until the first error and then everything else is ignored
<NiteHawk> not sure if they all have to be sequential (and free of collisions with other sections) but it's remarkable that the two pins you mentioned working are right at the top of your gpio definitions
<bmeneg> ssvb, but PB18 is exported wuth success.
<bmeneg> yeah
<NiteHawk> i agree with ssvb, that might be a case of "bail out" early...
<bmeneg> ssvb, NiteHawk indeed. I'll take a close look again in all these pins.
<bmeneg> I'll be back soon with some more info! thank you both!!
<NiteHawk> yw
<NiteHawk> btw: you might test it via a "round-trip" of .fex -> .bin -> .fex and compare the result, i suspect anything above gpio_pin_3 might already be missing
yann has joined #linux-sunxi
<NiteHawk> ssvb: do you think we could/should include apritzel's boot0img tool on the A64 branch of sunxi-tools? see https://github.com/n1tehawk/pine64/commits/for-sunxi-tools
<bmeneg> NiteHawk, your guess were right, although the "round-trip" showed exactly the same results compared to the original .fex file, the missing gpio_pin_4 corrupted everything above it!
<bmeneg> NiteHawk, I made the right sequence till 8 and all 8 pins were exported.
<NiteHawk> bmeneg: the .fex compiler probably just takes gpio_num and goes looking for matching pin definition lines. it fails on the gpio_pin_4, and quits :P
<bmeneg> NiteHawk, probably! =P I didn't notice any kind of 'kernel warning' about it at dmesg, but it seems the correct answer!
<bmeneg> NiteHawk, thank you very much! ssvb thank you too ;D
rellla has quit [Read error: Connection reset by peer]
<ssvb> NiteHawk: unless I missed it, boot0img needs at least some basic documentation
<ssvb> NiteHawk: also unless it works with boot0 images for other SoC variants, maybe we need to add a64 into its name
<NiteHawk> yes, that's why i thought of keeping it in the branch for now, until we have decided how to proceed with "A64-support"
apritzel has joined #linux-sunxi
<apritzel> ssvb: I will write something up for boot0img and push it to my repo for the time being
<apritzel> I can check how it works with other SoC's boot0s, but frankly I don't see it being too useful once we have U-Boot SPL working
<apritzel> which we do already for every SoC aside from the A64 ??
<ssvb> apritzel: A80 has no SPL yet, but jemk had some experimental version of it
* vagrantc pities the A80
<ssvb> apritzel: IIRC the DRAM was unreliable unless significantly downclocked
<apritzel> but boot0's DRAM setup is more stable at higher frequencies? Or is that a general problem?
jernej has quit [Quit: Konversation terminated!]
<apritzel> so is the SPL DDR setup algorithm the reason for this, as we miss something that boot0 does?
jernej has joined #linux-sunxi
<buZz> this rootmydevice is very startkeylogger-esque :P
<jelle> buZz: yeah so this is why you run mainline right ;-)
<buZz> none of my sunxi's are running atm :P
<buZz> how is it exposed though? whats sunxi_root_procfs
lemonzest has quit [Quit: Leaving]
<jelle> buZz: echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug
<buZz> ah hmhm
<buZz> hmm actually this might come in useful
<apritzel> buZz: for what exactly?
<buZz> like grabbing the fex file from some cheapskate android a10 tablet
<buZz> without having to actually deal with android ^_^
<apritzel> ok, well, to actually open an existing closed system
<buZz> systems are ment to be open
<buZz> if you love something, gotta set it free
<apritzel> right, and in this case you don't need a "builtin su"
rellla_wc has joined #linux-sunxi
<apritzel> unless you have a broken design, where some unprivileged process needs root access to achieve something
<apritzel> like setting a GPIO pin or the like
<apritzel> or mmapping /dev/mem
Graf_Ithaka has quit [Ping timeout: 276 seconds]
apritzel has quit [Ping timeout: 244 seconds]
IgorPec has joined #linux-sunxi
datagutt has joined #linux-sunxi
<datagutt> Does Allwinner A64/H64 still support FES mode?
<ssvb> datagutt: do you mean the binary only LiveSuit tool for Windows?
<datagutt> Yes
<ssvb> no idea, I'm not using Windows myself
<ssvb> but https://linux-sunxi.org/FES works on top of a lower level FEL protocol, and FEL is supported on A64
<datagutt> Well, neither Remix Mini or Pine A64 seems to have a fes1.fex in their images
<datagutt> The Allwinner SDK has one, but it seems to freeze the device
<datagutt> What i am trying to do, is flash a boot.img to a Remix Mini using FEL or FES
<datagutt> I recall one or two people in here having a Remix device, while Pine is the main dev device for A64
<ssvb> Remix Mini is using eMMC, so it is nowhere as complicated as NAND
<dave0x6d> buZz: hah, I'm happy The Register retweeted me, at least this issue is getting some coverage now.
<ssvb> datagutt: IIRC apritzel has done some experiments with reading the eMMC data from the FEL mode
<ssvb> datagutt: what kind of image are you trying to flash to it?
<datagutt> As far as i have read, he could successfully read data
<datagutt> I am not even trying to flash a full image at this point, just an android kernel (boot.img) file
<dave0x6d> jelle: it's amusing, I was trying to find a mainline kernel for my Orange Pi because I was worried that Xunlong's kernel would have security issues, and then I stumbled across that lovely backdoor.
<dave0x6d> of course there's also tons of security issues due to it never being updated since early 2015.
<KotCzarny> dave0x6d: which opi you have?
<dave0x6d> The Orange Pi One.
<KotCzarny> is it based on a20?
<jelle> that's a H3
<KotCzarny> no mainline yet
<KotCzarny> usb will be in 4.7
<dave0x6d> what's the status of ethernet?
<KotCzarny> patch exists, not mainlined yet
<dave0x6d> what chip is the ethernet though? I was wondering if I could compile it as an external module.
Guest_ has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
<jelle> dave0x6d: nope you can't
<jelle> you could test the driver which is somewhere I guess
<dave0x6d> the Orange Pi One wiki on sunxi doesn't appear to give any links.
<KotCzarny> H3/A64 EMAC(Ethernet) driver
<dave0x6d> thanks, just found it.
<dave0x6d> I didn't know it was in the H3, I thought it was an external chip at first.
Netlynx has quit [Quit: Leaving]
<ssvb> datagutt: we can add SPI flash and eMMC read/write support to the sunxi-fel tool, in fact it's something that I'm trying to implement now
<KotCzarny> hmm
<KotCzarny> i think montjoie wrote mainline driver
<dave0x6d> I hope the debug backdoor shames everyone into hurrying up with mainline support. :p
<KotCzarny> unlikely
<dave0x6d> there isn't much work left to do, is there...?
<KotCzarny> see the mainlining page
<datagutt> ssvb: Interesting. I guess i will wait for your implementation :)
tipo has joined #linux-sunxi
<dave0x6d> I see that Hans de Goede has added USB support, and Chen-Yu Tsai has done networking.
<dave0x6d> and Siarhei Siamashka has SMP.
<ssvb> dave0x6d: not really, SMP is handled via PSCI now
<ssvb> and PSCI is implemented as part of U-Boot
Guest_ has quit []
<dave0x6d> ah
zuikis has quit [Remote host closed the connection]
<NiteHawk> ssvb: that fel-sdboot and the required workaround seems a bit fragile to me. wouldn't we possibly be better off by building seperate bin files for older SoCs (with "high" BROM) and those variants where BROM starts at 0?
tsuggs has quit [Ping timeout: 265 seconds]
<ssvb> NiteHawk: we still have exactly the same problem with multiple binaries, sometimes they do not work and need to be nudged a bit
<NiteHawk> oh, even if they consist of nothing but the FEL jump?
<ssvb> yes, if I rebuild the current fel-sdboot.sunxi file from git master using my GCC 4.7.4 croscompiler, then it does not boot on A10
<ssvb> because it generates slightly different code and does not match the current binary in the bin directory
<NiteHawk> i tried that with my gentoo-crossdev-gcc a while ago for A20, and the generated file was fine and worked. i should probably re-check that
<NiteHawk> (i noted you changed some compilation flag in one of your patches to address this)
<ssvb> did I?
<NiteHawk> ah, no - think that was only related to thumb2 vs. arm32 (https://github.com/linux-sunxi/sunxi-tools/commit/776cf5543b567f781b1b87c31ade51cb04c98e8f)
<ssvb> btw, my first attempt which was reading the VER register and having a switch construct was working correctly on all my devices (which did not include a80)
<ssvb> probably that's because it had a larger code in the beginning before trying to pass control to the FEL handler
<NiteHawk> yeah, i wonder what's causing that behaviour - in theory checking the pc register should have been fine too
<ssvb> yes, checking the pc register also works fine, unless we hit this strange bug
<NiteHawk> addings nops to solve it smells a bit like it might be related to caches or jump prediction, imho
<ssvb> yes
<ssvb> I suspected that it has something to do with branch prediction and maybe passing control from 0x000000xy to 0xFFFF00xy
<ssvb> when the lower part of the address matches
<ssvb> and shifting the code a bit somehow resolves this
apritzel has joined #linux-sunxi
<apritzel> datagutt: hey, you are playing around with the Remix Mini?
<apritzel> I managed to boot ssvb's U-Boot on it using FEL and could access the eMMC
<apritzel> as well as the SD card
<apritzel> so I can copy stuff between the two
<apritzel> didn't dare to write something to the eMMC yet, though
<apritzel> I quickly tried to boot a (32-bit) kernel back then and it did start somehow, but then stopped
<apritzel> but I didn't investigate (only 24 hours/day here, you know)
<ssvb> NiteHawk: here are the disassembly logs - https://gist.github.com/ssvb/5f68caade9c76fd671f68135a6d96643
<ssvb> NiteHawk: as you can see, there are some minor differences, and you can try to test it too
<ssvb> NiteHawk: adding lots of NOPs in the beginning makes it always work, and different number of NOPs works fine too
<datagutt> apritzel: yes i played around with it a bit too much, and wrote boot.img using fastboot :P
<datagutt> i wasn't thinking straight
<ssvb> :-)
<apritzel> so it doesn't boot anymore from eMMC
<datagutt> Yes
<NiteHawk> ssvb: thx, i'll have a look at that
<datagutt> well, it simply freezes at jide tech logo as it can't boot android
<apritzel> I found that it doesn't use boot0, but something else (which was mentioned in the Wiki somewhere)
* apritzel looks for the dump ...
<ssvb> datagutt: does Jide provide some sort of recovery tool of their own?
<datagutt> i have a full update zip
<datagutt> non-ota
<datagutt> doesn't really help though, but it does contain full /system contents
<datagutt> but .fex files are shipped full in the otas
<datagutt> ssvb: They will send you an update.zip for use in their recovery, but if you can only boot into recovery if kernel boots
<apritzel> wouldn't it consider MMC0 eventually if the FEL button is pressed?
<datagutt> It doesn't try to boot from SD when pressing FEL, no
<datagutt> Well ,not as far as i can see
<ssvb> apritzel: nope, the FEL button works for only for USB OTG boot - http://linux-sunxi.org/BROM#A64
<apritzel> ssvb: ah, right
<ssvb> it is interesting that different Allwinner SoCs used different boot order and this stuff evolved over time
<apritzel> datagutt: do you have a FEL setup? USB A-A cable and sunxi-tools
<datagutt> Yes
<apritzel> I found that one DRAM parameter was different
<ssvb> apritzel: btw, have you dumped a dedicated eMMC boot partition or was it the main data area?
<datagutt> I will idle in here for tonight, and come back tomorrow if you would like to run any tests
<apritzel> ssvb: no idea, I told U-Boot about mmc2 and dumped the first sectors
<apritzel> there was something at sector 16 (I think) but it wasn't EGON, but that other thing ...
<ssvb> apritzel: then it wasn't a boot partition
<ssvb> probably boot0 is stored in a dedicated boot partition
<ssvb> datagutt: if you need an urgent fix, then I'm sorry to disappoint you and you might need to wait longer (as in days or weeks)
<ssvb> datagutt: I'm primarily looking at SPI flash now, but eMMC is next in the list because it should be also doable
<ssvb> maybe you can try to contact Jide? it is also their problem after all
<apritzel> ssvb: there is a TOC0.GLH signature at 8KB
<apritzel> and a partition table at 0
<ssvb> apritzel: maybe it's some other blob?
<ssvb> but you mentioned the DRAM parameters, do they look sane?
<ssvb> something like 672MHz
<apritzel> that magic number was different
<apritzel> ssvb: yeah, Google just told me as well ;-)
<apritzel> ddr voltage = 1500 mv
<apritzel> DRAM Type = 3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3)
<apritzel> DRAM zq value: 003d3ddd
<apritzel> DRAM init OK
<apritzel> DRAM clk = 672 MHz
<apritzel> DRAM size = 2048 MB
<apritzel> DRAM init ok
<ssvb> datagutt: either way, your device is very likely perfectly recoverable in principle, at least you will be able to run GNU/Linux on it :-)
<ssvb> apritzel: do you see these numbers in the TOC0.GLH header area? at least a 32-bit int with 672
mossroy has quit [Quit: Quitte]
<apritzel> yes, "A0 02 00 00" at 0x2084
<apritzel> (header starts at 0x2000)
<apritzel> the magics in this SINOVOIP header file seem to match as well
<ssvb> ok, looks like that's it
<apritzel> also the dd 3d 3d 00 at 0x208c
avph has quit [Ping timeout: 260 seconds]
<apritzel> there is some ARM code later, looks like exception vectors mostly
avph has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
<apritzel> well, the usual boot sequence, reset vectors, cp15 read/modify/write sequences, then one jump a bit off
* apritzel tries to not procrastinate away from the ATF work ;-)
reinforce has quit [Quit: Leaving.]
Andy-D has quit [Ping timeout: 260 seconds]
paulk-collins has quit [Quit: Leaving]
vagrantc has quit [Quit: leaving]
nove has quit [Quit: nove]
rellla_wc has left #linux-sunxi [#linux-sunxi]
cosm has quit [Quit: Leaving]
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
[Awaxx] has quit [Quit: "My GNU/Linux has gone to reboot. ZZzzzzzzzzZZzzz...zZz...z"]
Andy-D has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
iamfrankenstein has joined #linux-sunxi
<igraltist> luoyi: its seems that when i disable powersave in kernelconfig the connection stall is gone even when enable some cap
<dave0x6d> KotCzarny: so sunxi-debug is finally getting a bit of coverage.
tsuggs has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1 has joined #linux-sunxi
[Awaxx] has joined #linux-sunxi
[Awaxx] has quit [Client Quit]
[Awaxx] has joined #linux-sunxi
IgorPec has quit [Ping timeout: 244 seconds]
jernej_ has joined #linux-sunxi
jernej has quit [Ping timeout: 240 seconds]