akaizen has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
akaizen has joined #linux-sunxi
lvmc has quit [Quit: Page closed]
kaspter has quit [Ping timeout: 260 seconds]
<wens>
wonder if the kernel halt() loop should have a WFI inside
<wens>
currently it's just a while (1); loop
<wens>
the h3 gets pretty hot...
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
reev has joined #linux-sunxi
kaspter has joined #linux-sunxi
IgorPec has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
zuikis has joined #linux-sunxi
akaizen has quit []
akaizen has joined #linux-sunxi
lvmc has joined #linux-sunxi
lvmc has quit [Quit: Page closed]
JohnDoe_71Rus has joined #linux-sunxi
The_Loko has joined #linux-sunxi
<KotCzarny>
wens: lol
jernej has quit [Ping timeout: 244 seconds]
jrg has quit [Ping timeout: 244 seconds]
<lennyraposo>
sounds rather interesting
<lennyraposo>
wrong window
jrg has joined #linux-sunxi
zuikis has left #linux-sunxi [#linux-sunxi]
mosterta has joined #linux-sunxi
diego_r has joined #linux-sunxi
jrg has quit [Ping timeout: 276 seconds]
staplr has quit [Remote host closed the connection]
dearfibonacci has joined #linux-sunxi
reinforce has joined #linux-sunxi
jrg has joined #linux-sunxi
mosterta has quit [Ping timeout: 246 seconds]
The_Loko has quit [Quit: Leaving]
IgorPec has quit [Ping timeout: 240 seconds]
yann|work has quit [Ping timeout: 276 seconds]
fredy has quit [Excess Flood]
oneinsect has joined #linux-sunxi
fredy has joined #linux-sunxi
<oneinsect>
hello friends...any idea on how to Extract changes (create patch) from one github tree and then apply them on another clonned branch
iamfrankenstein1 has joined #linux-sunxi
* jonkerj
is interested in that as well, oneinsect
<jonkerj>
what I mostly do is checkout the cloned branch, and manually download and apply the changes from the one tree
<jonkerj>
to manually download the patch, copy the link to the commit, add ".patch" to it, and wget it
<jonkerj>
but I am really open for something easier :-)
<oneinsect>
how do i manually download the changes from the tree ??
<oneinsect>
is it like on big patch file jonkerj:
<oneinsect>
i mean there are multiple commits
<oneinsect>
can i just squash all commits and reapply them?
premoboss has joined #linux-sunxi
xcasex_ has quit [Ping timeout: 240 seconds]
phipli has quit [Ping timeout: 276 seconds]
<NiteHawk>
oneinsect: you can "git pull" from a 'remote' repo/branch too. create a local branch first (usually based on master), check it out and retrieve the foreign commits via "git pull <URL> <branchname>"
<oneinsect>
aha
<NiteHawk>
from there you can edit commits, or merge them into your stuff (with or without squashing)
<NiteHawk>
or cherry-pick
pzabielo has quit [Remote host closed the connection]
<oneinsect>
NiteHawk: say i clonned git clone git://git.denx.de/u-boot.git and changed into that directory and then i just git pull -b sunxi-changes git-url
<oneinsect>
is that how it is?
massi has joined #linux-sunxi
<NiteHawk>
i'm not sure if pull supports that "-b", but that's the basic idea - yes.
iamfrankenstein has quit [Ping timeout: 252 seconds]
iamfrankenstein1 is now known as iamfrankenstein
iamfrankenstein2 is now known as iamfrankenstein1
apritzel has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
<apritzel>
Hi, what is the purpose of having a SoC's memory map in the Wiki?
<apritzel>
If there is a perfect one in the publicly available manuals?
<apritzel>
(just asking ...)
<KotCzarny>
apritzel, easier to google than browse pdf?
<apritzel>
but it's redundant information, prone to copy&paste errors
<apritzel>
also the manual is the reference anyway
<NiteHawk>
well, allwinner manuals aren't always error-free too :P
<KotCzarny>
;)
<apritzel>
also the comment on the A64 page says: "These pages have been put together by scraping information from the SDK."
<apritzel>
which I seriously doubt
iamfrankenstein1 has quit [Ping timeout: 246 seconds]
<apritzel>
KotCzarny: re: errors in Allwinner's manuals: I see that, but then I'd prefer a particular error noted
<apritzel>
so now I have two sources of information, both _possibly_ identical, but it's actually hard to tell
<oliv3r>
ssvb: ok i'll try to find time, but the thing is, an identical lime a10 does work, same revision pcb etc. so i was just curious if this is a known thing or if too aggressive timings cause timeouts
<oliv3r>
apritzel: also, when we started writing the mmap in the wiki, we did not have docs maybe :)
<oliv3r>
apritzel: and when we did have docs, it was questionable if we could use it :) (nda/confidential etc)
<oliv3r>
apritzel: it was after about a year? maybe more when AW granted us the free usage of such
<oliv3r>
apritzel: also, in theory a wiki works better then a pdf, as you can better add changes and track changes. the big problem however is putting all the info into the wiki :(
<oliv3r>
apritzel: i find the aw manuals to be a horrible source of information. they often copy paste stuff, delete the wrong stuff, add errors when adding stuff
<oliv3r>
and it's not even a manual, it's just a register booklet if anything
<oliv3r>
ontop of that, they are fine with adding chapters about parts, without any info
<ssvb>
apritzel: yes, the manual has mistakes (for example, the size of SRAM C in A64) and has poor description for some hardware registers (you need a bit of guesswork to figure out what they mean)
Worf has joined #linux-sunxi
<ssvb>
apritzel: reporting bugs against the manuals has not been very efficient so far, you can check the Allwinner's github repository
<ssvb>
apritzel: so what would be the best way to handle this?
<oliv3r>
ssvb: do you have a probable starting point or any clue around which commit i should start to investigate?
<apritzel>
ssvb: I'd like to see some kind of manual errata page
<ssvb>
oliv3r: do you have two copies of U-Boot (compiled from source), so that one of them works correctly and another does not?
<apritzel>
(the remarks including pointers to missing IP blocks)
<ssvb>
oliv3r: you can always try the oldest mainline U-Boot with A10-Lime support as a starting point
[7] has quit [Disconnected by services]
<oliv3r>
ssvb: fair point; i just hoped it would ring some bells :) it's still quite possible that the board is somehow broken
TheSeven has joined #linux-sunxi
<apritzel>
and for the A64 some arguments really don't count: for instance we had the manual (even without the "confidential" water mark !1!!1!) since the beginning
<oliv3r>
ssvb: though the only thing i remember doing on it, was running burn in tests with boris's nand driver 6 months ago
<KotCzarny>
apritzel: but that means having to check 2 documents
<ssvb>
oliv3r: if there is an U-Boot build which works correctly on this board, then the problem is probably somewhere in the software
<oliv3r>
KotCzarny: and updating the wiki, so that the wiki becomes the main point of reference :
<oliv3r>
ssvb: i'll check if i am at the office again tomorrow
<apritzel>
KotCzarny: ??? Do you want to copy the _whole_ A64 manual into the Wiki?
<oliv3r>
apritzel: ideally, absolutly
<oliv3r>
but what we need for that really, is a nice template where we jsut fill in some values and generate a nice online user manual :)
<apritzel>
oliv3r: maybe, but I think that's a different story
<KotCzarny>
apritzel: sure, why not?
<ssvb>
apritzel: for the undocumented hardware blocks, we have no choice other than the wiki
<apritzel>
KotCzarny: the A64 manual is 702 pages, I think it's pointless to copy that
<KotCzarny>
apritzel, wiki has page/subpage structure
<apritzel>
every manual has bugs (even the well maintained ones)
<oliv3r>
apritzel: well you don't wanna wikify the docs twice :p
<KotCzarny>
so it can have chapters
<ssvb>
apritzel: it's not pointless to copy, but there are some copyright concerns
<apritzel>
frankly: the A64 manual isn't sooo bad that it justifies some man month of work
<oliv3r>
apritzel: but all manuals miss bits and pieces, so having 1 source for them all :)
<apritzel>
instead I'd rather see people help debugging and coding ;-)
<KotCzarny>
apritzel, not everyone is a coder, updating wiki will be perfect job for such people ;)
<ssvb>
copying the manual to the wiki would have been actually really straightforward, and this could be partially automated
<apritzel>
ssvb: well, but as mentioned this is a separate project
<apritzel>
I was actually just asking of the point of having the memory map copied into the Wiki without a comment about it's state
<apritzel>
and this table for the A64 is obviously copied from the manual, not "scraped from the SDK"
<ssvb>
I only see copyright problems, and also making sure that people don't start filling the wiki with unverified bullshit :)
<apritzel>
(because if carries comments from the manual and describes IP block for which I am pretty sure not even BSP Linux has drivers)
<apritzel>
*because it*
<oliv3r>
apritzel: also it helps in getting started and understanding
<apritzel>
ssvb: that's my point: who tells me that the Wiki information is actually more reliable than the PDF?
<oliv3r>
when i did the a10 pages, i was just getting started in ARM and sunxi, and sunxi was very young
<oliv3r>
it helped me understand quite well how these cpu's are glued together
<apritzel>
oliv3r: I am not so much arguing pages for older SoCs
<ssvb>
apritzel: you can always use both the wiki and the PDF
<apritzel>
ssvb: no, I need the PDF because it gives me the actual information about the registers
<apritzel>
also: I was wondering about having a better memory map already
<apritzel>
for instance one which is sorted
<ssvb>
apritzel: in fact, the PDFs, because sometimes you need to cross-check the information between different SoC variants
<apritzel>
but this page is a direct copy of the PDF version, with no comments about what's different
<ssvb>
still the point is that the information about the registers is not always very good in the manual, sometimes it is necessary to check the source code to understand it better
<apritzel>
ssvb: I agree that it would be nice to have a "real" manual
<apritzel>
which is generated by some scripts
<ssvb>
in the ideal world, Allwinner would listen to the feedback and update the manuals
<apritzel>
so a SoC description file can just reference the IP block (the H3, A64 and A83T for instance to the same instance of the EMAC register description)
<apritzel>
but I think that's a separate project and not really our call
<apritzel>
instead we could gather known defects and omissions to the Allwinner manual
<apritzel>
and hope that Allwinner produces updated copies
<apritzel>
(I think they did for some SoCs)
<ssvb>
they update the manuals sometimes, but not necessarily make them public
<ssvb>
people have tried to report problems, but nobody seems to care
<KotCzarny>
because why they should
<KotCzarny>
chips are selling
<KotCzarny>
devs (paid) arent complaining
<ssvb>
apritzel: nope, we document the problematic parts in the wiki, that's how it is handled now
<KotCzarny>
and wu responsible for github arent paid for that stuff
<apritzel>
ssvb: that was my point ;-)
<apritzel>
ssvb: but having a full (unverified?) copy of the manual's memory map is not really helpful, I think
<apritzel>
instead collecting known errata against the published manuals
<KotCzarny>
what about unpublished errata?
<ssvb>
apritzel: that wiki editor guy apparently has nothing better to do, he is free to waste his time
<apritzel>
ssvb: what is the best known practise to discuss this (with him?)
<ssvb>
apritzel: and I don't want to waste my time, trying to tell him what to do :-)
<ssvb>
I'm a bit worried about potential copyright violations though
<ssvb>
the wiki edit page already has a warning: "You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!"
<ssvb>
if you think that he is breaking the law, then we should probably remove that page
<ssvb>
oliv3r: if the firmware uses AR100 for SCP, then it's a bit difficult to use it in remoteproc
<oliv3r>
ssvb: what's the abbreviation scp
<ssvb>
The System Control Processor (SCP)
<oliv3r>
ahh okay
<ssvb>
it's the thing invented by ARM
<oliv3r>
hmm i did read something along those lines
<Amit_T>
oliv3r: But atm , it only has support to boot rtos or baremetal from linux master core
<oliv3r>
Amit_T: openamp? yeah i think so. i think it's 2 major comps behind it, xilinx and something else, with most recent commits from xilinx
<oliv3r>
and they do it to do things like split a dual core system into two
<Amit_T>
Yes, openamp
<Amit_T>
freescale recent proposed a new patch
<wens>
ssvb: the brom has a different code path for when super suspend flag is set
<wens>
there should be something we could use?
<oliv3r>
Amit_T: but i think one of the most basic functionalities, that doesn't even sound so strange, is to use remote proc to start, stop, reset and load firmware into a remote processor
<ssvb>
wens: do you mean boot0?
dearfibonacci has quit [Quit: Leaving]
<wens>
ssvb: nope, i mean brom
<wens>
at least on the a80, i did a partial disassembly to look at the boot path, as part of SMP
<wens>
i didn't look into the super suspend stuff though
<ssvb>
ok
<ssvb>
still even if it does something in a different way, it still has to do a normal boot?
premoboss has quit [Ping timeout: 246 seconds]
<wens>
i suppose one could leave some resume code in some sram, set the flags and re-entry address
<ssvb>
or does it bring the dram back from self refresh and can execute some code in it?
<ssvb>
ok, this sounds useful
premoboss has joined #linux-sunxi
<wens>
ssvb: brom is probably not that sophisticated
<ssvb>
is the SRAM always powered up?
<ssvb>
or some part of it?
<wens>
and the pmic has a mode that you can shut down various regulators, and have it turn them all back on on an interrupt
<wens>
ssvb: that's a good question, the manual does not mention which SRAM is part of which power domain
<wens>
my guess is the openrisc sram might be in the rtc domain, all the others in sys domain
IgorPec has joined #linux-sunxi
<ssvb>
that's an interesting point
<ssvb>
and probably one of the reasons why Allwinner is keeping their ATF in the DRAM
<wens>
the rtc domain is always on, but we could always leave sys on
<wens>
the openrisc core makes more sense if you want a remote control to turn on the power, like in an HTPC
<ssvb>
can we also have wake on lan?
<ssvb>
it's probably the most interesting thing, at least for me
<wens>
not sure if that is a function of the phy or the mac
<KotCzarny>
wake on wifi?
IgorPec has quit [Ping timeout: 260 seconds]
<ssvb>
I could not care less about smartphonish/tabletish suspend
<JohnDoe_71Rus>
wake on lan and network boot
<wens>
but a) the phy's don't have their interrupt lines connected, b) mac is powered off during suspend
<KotCzarny>
or wake on usb
<ssvb>
wens: are you talking about the existing boards?
<KotCzarny>
wake on time wouldnt be bad too
<wens>
ssvb: yes, existing boards
<ssvb>
so some new board can be probably designed to route the necessary interrupt lines
<ssvb>
this is probably worth investigating
IgorPec has joined #linux-sunxi
<ssvb>
wens: but anyway, just supporting the power button on Orange Pi PC would be probably a good start
<ssvb>
this must be relatively easy
<wens>
h3 is the one that really needs openrisc :/
<KotCzarny>
i wonder how many khashes would it have
enrico_ has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
alexxy[home] has quit [Ping timeout: 276 seconds]
utente_ has joined #linux-sunxi
premoboss has quit [Ping timeout: 250 seconds]
IgorPec has joined #linux-sunxi
popolon has quit [Ping timeout: 250 seconds]
tomboy64 has quit [Ping timeout: 244 seconds]
pmattern has joined #linux-sunxi
dearfibonacci has joined #linux-sunxi
afaerber has joined #linux-sunxi
afaerber has quit [Read error: Connection reset by peer]
staplr has joined #linux-sunxi
Amit_t_ has joined #linux-sunxi
popolon has joined #linux-sunxi
<oliv3r>
wens: how so? does it not have it?
<wens>
there's no pmic
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 has joined #linux-sunxi
cnxsoft1 is now known as cnxsoft
disik has joined #linux-sunxi
TheSeven has quit [Ping timeout: 258 seconds]
TheSeven has joined #linux-sunxi
xcasex has quit [Quit: reboot!]
<dearfibonacci>
Hello. Im trying to setup Olimex A20 Micro board. Tried to set it up with multiple options/kernelversions/ubootversions but cant get the desired final img. Also I need advanced sunxi kernel/uboot because I need video/Xorg graphics aswell. Any advices for versions tips or something ?
steeve has joined #linux-sunxi
reev has quit [Ping timeout: 260 seconds]
tkaiser has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
pmattern has quit [Quit: Genug für heute.]
<tkaiser>
ssvb: Don't know if this is not already known. But with the H3 BSP kernel wake from 'suspend to RAM' is easy by adding one line to the fex
maz_ has joined #linux-sunxi
<ssvb>
tkaiser: yes, because the H3 BSP kernel loads and starts a proprietary firmware on the OpenRISC core, which does the job
<ssvb>
we were discussing about what is happening under the hood and how to implement this functionality when running the mainline kernel
<ssvb>
on A64 everything is different and the bootloader is responsible for starting the OpenRISC firmware
staplr has quit [Ping timeout: 260 seconds]
ganbold has quit [Ping timeout: 258 seconds]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
ganbold has joined #linux-sunxi
enrico_ has quit [Ping timeout: 240 seconds]
staplr has joined #linux-sunxi
<tkaiser>
ssvb: And on A83T it's the PMIC's job? Just to increase confusion? ;)
maz_ has quit [Ping timeout: 260 seconds]
<ssvb>
tkaiser: the PMIC is a relatively dumb thing which can do a few tricks, but the OpenRISC core can run any arbitrary software on it
fathead has quit [Quit: leaving]
<tkaiser>
dearfibonacci: If this image http://www.armbian.com/olimex-micro/ runs then at least there's a build system where you can have a look how to tweak things.
<tkaiser>
ssvb: I had a look in the wiki, but an AR100 page A83T isn't mentioned and vice versa
<oliv3r>
btw, we can use the H3 completly on mainline, without using the OpenRISC core, right?
enrico_ has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
<ssvb>
oliv3r: yes, it's more like a nice to have thing
<ssvb>
but not really critical for running the system
<oliv3r>
yeah, but that means in thoery, we can experiment and rewrite the whole thing at our own pace
<ssvb>
yes
utente_ has quit [Quit: Sto andando via]
vinodh has joined #linux-sunxi
vinodh has quit [Client Quit]
dearfibonacci has quit [Quit: Leaving]
pstef has quit [Remote host closed the connection]
fredy has quit [Excess Flood]
Mr__Anderson has joined #linux-sunxi
fredy has joined #linux-sunxi
nove has joined #linux-sunxi
enrico_ has quit [Ping timeout: 276 seconds]
enrico_ has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
vickycq has quit [Ping timeout: 252 seconds]
vickycq has joined #linux-sunxi
<ssvb>
tkaiser: any news with the h3 banana's dram?
reinforce has quit [Quit: Leaving.]
<tkaiser>
ssvb: Not really, just the recommendation to stay away from this device since it's overheating way too much. Same with first tests on NaniPi M1 (OPi PC clone). Gets insane hot and we have to use the throttling settings from BPi M2+ now to get any results.
<tkaiser>
Also 1.3V VDD_CPUX are confirmed instead of the 1.2V from schematics.
<NiteHawk>
ssvb: i've been considering the FEL uEnv thing back and forth, and played around some more with that. i think your suggestion of some magic comment at the beginning (indicating the uEnv format) makes a lot of sense. can i have your opinion on https://gist.github.com/n1tehawk/9899b3f91ae2bdb9235e162cc16fe26c ?
<ssvb>
NiteHawk: actually I was suggesting it for the sunxi-fel tool, but not for U-Boot
Nacho_ has joined #linux-sunxi
<NiteHawk>
but the ability to recognize the format would save us from using a new (data size) field in the SPL header? U-Boot won't try any antics if the magic signature isn't present
libv_ is now known as libv
<ssvb>
NiteHawk: if the SPL header fields are properly documented in the comments, I don't see any problem with having zero size as an indicator for boot.scr and non-zero as the size for uEnv.txt
<ssvb>
NiteHawk: we can even add a new field for the boot script format in the SPL header if it is really needed
<NiteHawk>
well, i don't think so. if we're going for some "magic" string, then .scr format and uEnv.txt style can be distiguished reliably
<ssvb>
but uEnv.txt still needs an extra size field, while boot.scr doesn't
<ssvb>
if we are introducing the magic uEnv signature string in U-Boot, then this change has a bit wider scope than just sunxi
<ssvb>
and people may not like it
<NiteHawk>
not quite. the key is to have sunxi-fel do a proper NUL-termination of the string (buffer) and make sure that NUL is included in the upload. from the U-Boot side it then boils down to a simple strlen(script) - see line 67 in the gist
Mr__Anderson has quit [Remote host closed the connection]
<ssvb>
this is already getting a bit ugly, because we are implicitly appending some stuff to the uEnv.txt content
<ssvb>
you can still post the patch though, maybe I'm wrong and people will like it
<ssvb>
we can have a nice discussion there
<ssvb>
NiteHawk: "save us from using a new (data size) field in the SPL header" is not an issue, a few more bytes don't make a big difference
<NiteHawk>
i vaguely remember folks complaining "you're taking away our last 'reserved' entry" :D
<ssvb>
on the other hand, unless we bump the SPL header format version, the sunxi-fel tool will not know if this particular u-boot-sunxi-with-spl.bin image supports the uEnv.txt feature or not
<ssvb>
so either way, the SPL header has to be updated
<ssvb>
I believe that "you're taking away our last 'reserved' entry" was never a really serious argument :-)
<NiteHawk>
yes, that's a valid point. an older u-boot would just attempt do use "script" on that data (which should fail 'gracefully' due to the mkimage header missing)
JohnDoe_71Rus has joined #linux-sunxi
zuikis has joined #linux-sunxi
<TheLinuxBug>
Wow, Orang Pi Plus 2E is not very stable in Android it seems without a heat sink, I can't even run the CPU/GPU stability test
<TheLinuxBug>
it runs about 10 seconds then the whole thing freezes and reboots
<TheLinuxBug>
:(
<TheLinuxBug>
guess I will need to get a heatsink for it
jernej has joined #linux-sunxi
disik has quit [Ping timeout: 260 seconds]
<tkaiser>
TheLinuxBug: Undervoltage/undercurrent more likely. OPi+ 2E doesn't overheat that easy
<tkaiser>
Nearly impossible to get in trouble due to overheating.
Shirasaka-Hazumi has quit [Read error: Connection reset by peer]
<ssvb>
TheLinuxBug: what kind of test?
IgorPec2 has joined #linux-sunxi
reinforce has joined #linux-sunxi
IgorPec has quit [Ping timeout: 250 seconds]
<ssvb>
TheLinuxBug: also as tkaiser mentioned it, what are you using to power the board?
<ssvb>
IgorPec2: just picked up the opi+2e board from the post office, thanks!
<IgorPec2>
ssvb: you're welcome
<KotCzarny>
TheLinuxBug: yup, i also bet on amperage problems
<KotCzarny>
(or undervoltage)
<KotCzarny>
it NEEDS more than 2A on load, because it has more ddr ram
<KotCzarny>
and other things
Shirasaka-Hazumi has joined #linux-sunxi
<tkaiser>
KotCzarny: Not true. The amperage depends on how many USB devices you want to connect. That's why I wrote 3A in the wiki (the older boards were listed with 2A since that's just copy&paste from Xunlong's Aliexpress pages)
<KotCzarny>
tkaiser: crappy power bricks drop voltage on high amperage
<tkaiser>
With the fex settings of the Android image the board most likely won't be able to exceed 1A. But when the voltage isn't stable then that happens what TheLinuxBug is experiencing.
<KotCzarny>
tkaiser, that's what i meant, crappy psu == voltage drop
<KotCzarny>
for starters you can run limamemtester
<TheLinuxBug>
tkaiser: to be more specific -- it seems to be related to the GPU, when GPU utilization i high in the GPU/CPU test or even 1080p video it has issues and freezes. I am running the testing tool they incuded in their Android distribution as an app.
<TheLinuxBug>
ssvb ^
<ssvb>
KotCzarny: we still need to fix the lima-memtester
<KotCzarny>
ssvb, just curious if it would run
<TheLinuxBug>
it works ok
<TheLinuxBug>
I just found
<ssvb>
TheLinuxBug: maybe DRAM is clocked too high on your board
<TheLinuxBug>
that I can run the strait cpu test fine at 1.2ghz
<TheLinuxBug>
and its run about 40 times now
<ssvb>
because Mali is particularly sensitive to it
<TheLinuxBug>
but anything with GPU and it freezes
<TheLinuxBug>
hmm any way to change that in Android?
<TheLinuxBug>
I mean I know it can be changed on linux relatively easy
<KotCzarny>
android uses fex too
<TheLinuxBug>
ahh ok
<KotCzarny>
but its embedded somewhere in the image
<TheLinuxBug>
not sure why someone removed all that ;/
<TheLinuxBug>
was something wrong with the images?
tkaiser has quit [Ping timeout: 272 seconds]
<TheLinuxBug>
ahhhh
<TheLinuxBug>
nm
<TheLinuxBug>
I see
<TheLinuxBug>
someone reformatted
<TheLinuxBug>
(facepalm)
<TheLinuxBug>
ok anyhow..
<TheLinuxBug>
:Z
<KotCzarny>
welcome to wonderful world of allwinner :P
tkaiser has joined #linux-sunxi
<TheLinuxBug>
hmm trying to figure out which actual file for android I need to edit
<TheLinuxBug>
is that ahh
vagrantc has joined #linux-sunxi
<TheLinuxBug>
is it set in the uEnv.txt?
<TheLinuxBug>
ahh
<TheLinuxBug>
script.bin found it
<TheLinuxBug>
ok
<TheLinuxBug>
will have to drop it to 600 here
<TheLinuxBug>
and see if same issue
<TheLinuxBug>
Thanks guys :D
yann|work has quit [Ping timeout: 258 seconds]
<TheLinuxBug>
tkaiser, ssvb, you guys are always helpful, thanks :D
<TheLinuxBug>
you too KotCzarny ;p
<KotCzarny>
:)
<KotCzarny>
dont forget to update the wiki :P
Nacho_ has quit [Quit: No Ping reply in 180 seconds.]
Nacho_ has joined #linux-sunxi
<ssvb>
TheLinuxBug: be careful with it though, the reason is that the DRAM settings from script.bin become active only upon reaching the first thermal trip point
<ssvb>
TheLinuxBug: the system starts with the DRAM settings from the bootloader
fredy has quit [Excess Flood]
<tkaiser>
ssvb: Sure? This is u-boot 2011.09. I thought u-boot would read the sysconfig_fex stuff? At least you explained something like that regarding the bootclock entry in script.bin
fredy has joined #linux-sunxi
<ssvb>
tkaiser: no, I'm not sure :-)
<ssvb>
tkaiser: ok, maybe the Allwinner's U-Boot also respects script.bin, I have no idea what it does
<ssvb>
tkaiser: but as you know, with the mainline U-Boot, the DRAM settings from it are in use until the first thermal trip point
<KotCzarny>
you can always try to change something obvious, ie. disable hdmi ;)
<tkaiser>
In case Android allows shell access or accessing sysfs (rootmydevice here we come) then this here is the current DRAM freq: /sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/cur_freq
paulk-nyan-big has joined #linux-sunxi
<KotCzarny>
isnt there /proc/sunxi_debug?
<ssvb>
yeah, it's very convenient to have rootmydevice in such cases :-)
IgorPec2 has quit [Ping timeout: 260 seconds]
IgorPec has joined #linux-sunxi
<tkaiser>
TheLinuxBug: On which specific partition did you find a script.bin file?
<TheLinuxBug>
tkaiser: you would think that Xunlong would have provided it root or with an easy root available, but unfortunately not. I searched for a while and tried the comon methods. Honestly its annoying to me that they would realease it without root to begin with as they are basically dev boards.
<TheLinuxBug>
tkaiser: I haven't yet, I need to get an sdcard and boot the board, I don't have one where I am atm, they are all in my lab
<TheLinuxBug>
will have to go in there tonight and see what I can work out
<TheLinuxBug>
does rootmydevice work with Orange Pi Plues 2E?
<TheLinuxBug>
ahh
<TheLinuxBug>
nice
<TheLinuxBug>
found some documentation lets see what kinda of trouble I can cause :Z
<KotCzarny>
TheLinuxBug: can you check in adb shell that you have /proc/sunxi_debug ?
<KotCzarny>
or similar
<TheLinuxBug>
SWEET
<TheLinuxBug>
tkaiser: thanks again, your post to arbiam.com again saves the day
<TheLinuxBug>
now I got root :D
<TheLinuxBug>
after fighting that forever, eesh
<TheLinuxBug>
seems their image is not patched
<TheLinuxBug>
even for the OPi Plus 2E
<TheLinuxBug>
you think they would have taken a moment since its a new board to patch it... lol
<KotCzarny>
TheLinuxBug: it was me who found it :P
paulk-nyan-big has quit [Ping timeout: 250 seconds]
<ssvb>
it is a sun6i compatible SPI controller without any surprises, so there should be no problem with it in the mainline kernel (assuming that the SPI driver is in a good shape on older Allwinner devices)
<ssvb>
as for the BSP kernel, I have no idea
<tkaiser>
ssvb: IIRC Martin Ayotte sent .dts patches so that this works now in latest longsleep kernel
yann|work has joined #linux-sunxi
massi has quit [Quit: Leaving]
<xcasex>
so tkaiser about that opi armbian thread.
<xcasex>
are you looking for packagers of the desktop stack or did i misinterpret?
yann|work has quit [Ping timeout: 258 seconds]
popolon has quit [Quit: WeeChat 1.3]
<tkaiser>
xcasex: Sure, packaging all stuff properly so we can put all this stuff in a nice apt repository, provide updates this way and also allow upgrade from server/CLI images to desktop images.
<tkaiser>
xcasex: At the moment in such a situation then 2D/3D/video acceleration (Cedrus/vdpau) is missing. This might the stuff most users might be missing
<xcasex>
tkaiser: and this in particular is related to the opi plus 2e devboard? because generically is far superior for all the supported platforms. :)
enrico_ has quit [Quit: Bye]
<tkaiser>
xcasex: The development is something all boards Armbian supports should benefit from. And this desktop stuff is at least something for A10/A20/H3 boards.
<xcasex>
tkaiser: well then its entirely doable.
<tkaiser>
But we're currently able to throw around with a couple of OPi+ 2E to encourage users to join in community efforts (thanks to Xunlong being pretty generous)
<xcasex>
tkaiser: is there a irc channel (the #armbian channel was v. quiet last i looked) or other forum for coordination?
<tkaiser>
xcasex: Not that I know of. Ask IgorPec ;)
* xcasex
poked IgorPec
<IgorPec>
do we an irc channel? :)
<xcasex>
tkaiser: heh i'm up for it, is there a formal process or just digging in?
<xcasex>
IgorPec: haha there's an #armbian channel :p
Netlynx has joined #linux-sunxi
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
<IgorPec>
ok, well
<IgorPec>
tkaiser: btw. serial console on xenial. did we broke it or it was never done?
Mr__Anderson has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
<tkaiser>
IgorPec: Ah, I think it never worked (just got irritated today about the same issue though)
<tkaiser>
xcasex: Please write in the thread in armbian forum what you're trying to contribute.
<IgorPec>
ok, will take a look
paulk-nyan-big has joined #linux-sunxi
yann|work has joined #linux-sunxi
paulk-nyan-big has quit [Ping timeout: 244 seconds]
<TheLinuxBug>
tkaiser: what was you thought regarding the number of partitions there? Were you just curious?
<KotCzarny>
nope, probably just pointing ridiculous amount of them
<tkaiser>
TheLinuxBug: Since I wiped out eMMC on both new OPi I was curious. And I'm also curious whether you'll find something like script.bin on one of them.
tkaiser has quit [Read error: Connection reset by peer]
<KotCzarny>
and no anything fex/bin related
Shirasaka-Hazumi has quit [Ping timeout: 276 seconds]
tkaiser has joined #linux-sunxi
<KotCzarny>
grep disp_init /dev/mmcblk1p1
<KotCzarny>
Binary file /dev/mmcblk1p1 matches
<KotCzarny>
Binary file /dev/mmcblk1p6 matches
<KotCzarny>
Binary file /dev/mmcblk1p7 matches
<KotCzarny>
Binary file /dev/mmcblk1p9 matches
<KotCzarny>
Binary file /dev/mmcblk1p10 matches
<KotCzarny>
so it looks like it could be in places
<TheLinuxBug>
tkaiser: I will let you know when I get an sdcard tonight and load armbian or something and look, not sure if I can mount it in android or not, may try that as well. Either way I will let you know my outcome. Which do you think is better for my settings change if I do find it, 600000 or 648000?
<KotCzarny>
TheLinuxBug: why not both?
<IgorPec>
tkaiser: serial console works when it's defined in kernel command line :)
<KotCzarny>
um, im stupid, .bin is compiled fex, not plain
<TheLinuxBug>
more so interested in if either would render it bricked if it didn't work, cause not sure I have the stuff to flash FEL on it again here :Z
<KotCzarny>
TheLinuxBug: boot order is to prefer microsd
<KotCzarny>
so if you have bootable sd card and a backup you're good
Shirasaka-Hazumi has joined #linux-sunxi
<KotCzarny>
/dev/mmcblk1p10 has .fex
<TheLinuxBug>
awesome
<tkaiser>
TheLinuxBug: I would start with a pretty low value just to see what happens. And it may sound absurd but I had so many situations where a single piece of hardware (rated ok) failed that I never ever trust in that again. I try to have two pieces each of everything (PSUs, cables and so on) just to interchange before starting to go mad
<TheLinuxBug>
I will check it out here shortly, currently working and just got busy :( (much rather play with my boards :p)
<tkaiser>
IgorPec: This is something we have to try out too. Whether we can send output to serial and display at once (on H3 -- remember only either or worked)
<tkaiser>
KotCzarny: If there's a fex then it's clearly the wrong partition. But since I now mention the 3rd time the same link I give up.
<KotCzarny>
but it has plenty of fexes, arisc, sys_config, config, sys_partition, boot0_nand
<KotCzarny>
tkaiser, it might have bins too, its not a fs
<tkaiser>
KotCzarny: Either u-boot supports script.bin (then there must be a FAT or ext4 partition where this file sits) or not. Then it's something *before* all these partitions.
<TheLinuxBug>
If I recall
<TheLinuxBug>
there shoutl be a fat partition with script.bin
<TheLinuxBug>
from when I built the images for A10
<TheLinuxBug>
unless something has changed drastically
<TheLinuxBug>
I just haven't had time to go dig into it yet
<KotCzarny>
TheLinuxBug: not if its android
<tkaiser>
TheLinuxBug: I won't copy&paste the same link a fourth time ;)
<KotCzarny>
they embedded it in binary
<TheLinuxBug>
ohh thats right eesh and I have even done it before I am just failing to remember
<TheLinuxBug>
tkaiser: np I understand :)
<TheLinuxBug>
I will dfienently figure it out here tonight or very soon as I have time
<TheLinuxBug>
maybe Ill doc the process in case others run into it
<KotCzarny>
tkaiser: /dev/mmcblk1p10 is interesting
<KotCzarny>
would be nice to compare with the decoded bin to see if there are differences
<KotCzarny>
also, ths_trip2_0 = 115, he he
<tkaiser>
KotCzarny: If you would've read the links before you would now. Wens extracted the binary stuff that's really used and most probably it's identical to what you found.
<KotCzarny>
most probably.
<KotCzarny>
there is plenty of stuff that i havent seen in decoded fexes
<tkaiser>
And if you look at the cooler_table then it's obvious that 115*C will never be reached since the board is single core running at 504 MHz before. But funny, that all these crappy settings are used again
<KotCzarny>
or i just dont remember
<KotCzarny>
also, it includes lots of comments, which are lost when decoding bin
<KotCzarny>
also, at the bottom it looks like a descirpion what goes where
<KotCzarny>
ie mmcblk0p5 is env.fex
<KotCzarny>
etc
<KotCzarny>
or its just unrelated cruft stuff
<tkaiser>
KotCzarny: You won't believe but all this stuff is on Github. Uploaded by various parties, even Allwinner themselves. 'BSP sources' ;)
<KotCzarny>
:)
staplr has quit [Ping timeout: 276 seconds]
tkaiser has quit [Ping timeout: 250 seconds]
raknaz has joined #linux-sunxi
tkaiser has joined #linux-sunxi
raknaz1 has joined #linux-sunxi
raknaz has quit [Ping timeout: 246 seconds]
raknaz1 is now known as raknaz
zuikis has left #linux-sunxi [#linux-sunxi]
Netlynx has quit [Quit: Leaving]
raknaz has quit [Ping timeout: 244 seconds]
staplr has joined #linux-sunxi
raknaz has joined #linux-sunxi
pstef has joined #linux-sunxi
<nove>
wouldn't be good to have in the wiki a uniform template for message boxes?
steeve has quit [Remote host closed the connection]
paulk-nyan-big has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
xcasex has quit [Read error: Connection reset by peer]
xcasex has joined #linux-sunxi
staplr has quit [Ping timeout: 258 seconds]
martinayotte has joined #linux-sunxi
umiddelb has joined #linux-sunxi
<martinayotte>
tkaiser, about SPI on A64, I've never been able to make it work, since enabling it with "okay" make the ethernet disappear, I dont know why
aballier has quit [Ping timeout: 246 seconds]
aballier has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
umiddelb has quit [Ping timeout: 250 seconds]
apritzel has joined #linux-sunxi
<apritzel>
ssvb: SPI on Pine64> I have the DT runes here in my repo already, and indeed it should be a no brainer
<apritzel>
but I couldn't test this properly yet
<apritzel>
I think spidev should be the way to go, but it wasn't obvious to me what was needed on the userland side to utilize this
<apritzel>
but frankly I was more hoping I would get access to the SPI flash I have connected here anyway
<apritzel>
not sure that would mean using the whole MTD framework
<longsleep>
apritzel: well if you have some code to do whatever protocol that thing has it should be the same
<apritzel>
I was hoping for something like i2c-get or the like
<longsleep>
apritzel: but to just test SPI a simple LED with resistor works
<apritzel>
so I'd like to send commands to the flash chip and read some ID registers, for instance
<apritzel>
that would really prove that it works
<longsleep>
sure, if the software for it exists
<apritzel>
some blinking LED really doesn't mean much in terms of SPI communications setting, frequency, ...
<longsleep>
sure
<longsleep>
but if it starts blinking when you send commands and stops when you do not its something
<longsleep>
thats my first test all the time
<longsleep>
after that some prototype c code implemeting the payload
<xcasex>
tkaiser: written in the thread, im guessing we're using github as well.
<apritzel>
longsleep: I think this spidev.c from the tools directory should do
<longsleep>
apritzel: did you modify the dtb already to have spidev loaded? martinayotte seems to have problems with that on the BSP kernel with Pine64
<apritzel>
longsleep: I have the spi DT node
<apritzel>
and then tried both an MTD node and a spidev node
<apritzel>
then got confused about all this and stopped looking at it
<apritzel>
longsleep: do you have a pointer for a working example on some other SoC?
<longsleep>
apritzel: inside the spidev@0, muliple devices can be added, they have a touch screen there, but it can be replaced by an spidev or whatever
<apritzel>
longsleep: thanks will take a look - though it seems to be from yet another BSP kernel ;-)
<longsleep>
apritzel: yeah sorry, its what i have to work with :)
nove has quit [Quit: nove]
<longsleep>
apritzel: it actually depends on the spi driver itself if and which pins can be used for spi. In case of the odroid-c only one of the pins is a hardware spi, the others are software and handled by the driver
<longsleep>
apritzel: no idea for the Pine64 driver or whatever spi driver you use in mainline
<ssvb>
apritzel: spidev has too many moving parts, moreover SPI0 pins are multiplexed with NAND (which is not a problem for the Pine64 though) which may add some extra complexity
<ssvb>
apritzel: of course, everything is doable, put keeping all of this in a usable shape may be tricky in the long run
<apritzel>
ssvb: I just want the spidev for testing, I guess
<apritzel>
in the DT I'd just put the nodes for the SPI "host driver"
<ssvb>
apritzel: BTW, regarding a potential 'secure' setup, where the firmware updates the SPI flash
<ssvb>
apritzel: is it possible for the ATF to stop all the other cores while it is doing something?
<apritzel>
ssvb: architecturally that sounds doable
<apritzel>
why would you want to do this?
<longsleep>
apritzel: i guess just add an spidev node as subnode of the spi@whatever
<ssvb>
apritzel: because if we have the SPI flash write protect pin controlled by the firmware, then we don't want anyone else getting in the way when the SPI write protect is temporarily disabled
<apritzel>
longsleep: yeah, that's what I tried already, but then couldn't find out whether this was successful or not
<ssvb>
apritzel: or is this usually handled in some other way?
<apritzel>
longsleep: I guess this spidev_test.c should do this
<apritzel>
ssvb: I think SPI0 can be switched to secure
<ssvb>
apritzel: what about GPIO bit-banging?
<ssvb>
apritzel: if the whole GPIO port C is set as secure, then we possibly cripple NAND and eMMC
<apritzel>
well, this isn't a well architected, bullet-proof server
<ssvb>
it might be reasonable to allow the kernel to access SPI0, but have the write protect pin under exclusive control by the firmware
<apritzel>
that would need to be a PortL pin, then
<ssvb>
so that the kernel temporarily releases SPI0, and asks the firmware to program the flash, the firmware could verify digital signature, freeze all the other CPU cores, unlock write protect, do the flashing job, restore write protect, return back
<apritzel>
because you can only switch the whole of the other GPIOs to secure, if I get this correctly
<ssvb>
and split the whole flashing job into smaller parts, so that the system is not frozen for a long time :-)
Mr__Anderson has quit [Remote host closed the connection]
<apritzel>
I am not sure if this is really worth the effort if in the end the user could just write something to the SD card as well
<ssvb>
this is also covered in the wiki, a removable SD card could be probably moved to MMC1 and become non-bootable :-)
<apritzel>
yeah, just read this
<ssvb>
yes, I'm not sure if a perfectly secure system has much practical use on A64, but it's a bit fun trying to figure out whether it is doable in principle
<apritzel>
agreed, but a bit of a moot exercise at the moment ;-)
<apritzel>
since there is still something missing to enable the secure controller at all, I am afraid
<apritzel>
So I could flip bits in the secure peripherals controller from ATF (and they also stuck)
<apritzel>
but I was still able to access those devices from U-Boot
<ssvb>
wtf is trustzone? is it something that can restrict access to some areas of the address space?
<apritzel>
TrustZone is the ARM marketing name for this whole secure/non-secure architecture
<apritzel>
it is basically a state (one bit: secure or not) that is all over the system
<apritzel>
it goes over the bus for instance
<apritzel>
so devices can differentiate
<apritzel>
the GIC is an example, it behaves differently if accessed from secure or non-secure state
<apritzel>
the A64 has two controllers to care about
<ssvb>
instead of flipping bits in some table ("Secure Peripherals Controller"), maybe it's possible to just use the "Secure Memory Controller" to block access to some memory areas where the hardware registers reside?
<apritzel>
the other is a simple (Allwinner designed) register block which can switch _devices_ between secure and non-secure
<apritzel>
ssvb: I need to check whether this controller covers DRAM only ...
<apritzel>
ssvb: btw: I quickly hacked some "FEL button" for the Pine64 yesterday: in sunxi/fel_utils.S:save_boot_params() I added some lines to check a GPIO (PC11)
<apritzel>
and either branch back to the SPL or go to 0x20 to start BROM's FEL boot
<apritzel>
so now I can have a bootable SD card in, but still load kernels quickly via FEL when I have a jumper over pins 39 & 40 on the PI2 connector
<apritzel>
ssvb: does that sound useful for upstream U-Boot? Or is this just for my hacking convenience?
<jrg>
weird. armbianmonitor -m doesn't work with an opi+2e?
pmattern has quit [Quit: Genug für heute.]
mosterta has quit [Ping timeout: 252 seconds]
<ssvb>
apritzel: not sure about this, but you can try :-)
<ssvb>
if the FEL activation GPIO pin can be optionally configured in the menuconfig or added to the board defconfig (disabled by default), then it should not harm
<ssvb>
it might be also useful for the Orange Pi PC or for any other board without the hardware FEL button
<ssvb>
but it's not my call and your patch may get rejected by Hans