ganbold has quit [Quit: This computer has gone to sleep]
tomboy64 has quit [Quit: Uhh ... gotta go.]
tomboy64 has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
The has joined #linux-sunxi
The has quit [Client Quit]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
<wens>
montjoie: i do not have the chinese one
orly_owl has quit [Read error: Connection reset by peer]
<wens>
mentioned it because the a83 manual's emac is not correct, it is in fact a copy of the old gmac from a80
ninolein has quit [Ping timeout: 250 seconds]
ninolein has joined #linux-sunxi
ganbold has joined #linux-sunxi
orly_owl has joined #linux-sunxi
ganbold has quit [Client Quit]
ganbold has joined #linux-sunxi
ganbold has quit [Quit: This computer has gone to sleep]
cnxsoft has joined #linux-sunxi
ganbold has joined #linux-sunxi
sigjuice has quit [Ping timeout: 246 seconds]
sigjuice has joined #linux-sunxi
ganbold has quit [Quit: This computer has gone to sleep]
robogoat has quit [Ping timeout: 244 seconds]
Gerwin_J has joined #linux-sunxi
robogoat has joined #linux-sunxi
ganbold has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
<wens>
montjoie: bpi m3 needs rx/tx delay set in syscon register :/
ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 250 seconds]
p1u3sch1 has joined #linux-sunxi
ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-sunxi
ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-sunxi
reev has joined #linux-sunxi
ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-sunxi
ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-sunxi
<plaes>
ssvb: no luck.. 672MHz still fails with v4
IgorPec has joined #linux-sunxi
<plaes>
also, I have HDMI -> DVI cable for monitor and it doesn't turn on the display
leio has quit [Ping timeout: 250 seconds]
ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
ganbold has quit [Quit: This computer has gone to sleep]
IgorPec has quit [Ping timeout: 260 seconds]
JohnDoe_71Rus has joined #linux-sunxi
orly_owl has quit [Read error: Connection reset by peer]
leio has joined #linux-sunxi
lennyraposo has joined #linux-sunxi
orly_owl has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
reinforce has joined #linux-sunxi
IgorPec has joined #linux-sunxi
orly_owl has quit [Quit: leaving]
orly_owl has joined #linux-sunxi
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<lennyraposo>
Allwinner is building the Mali DDK DMA Buffer and not UMP
<lennyraposo>
just got the news
<lennyraposo>
for Pine 64
<lennyraposo>
been reading and it shouldn't be too difficult from my understanding to get it to work
<lennyraposo>
:D
vetkat has quit [Read error: Connection reset by peer]
orly_owl has quit [Read error: Connection reset by peer]
orly_owl has joined #linux-sunxi
slapin has quit [Remote host closed the connection]
willmore has quit [Ping timeout: 244 seconds]
clonak has quit [Ping timeout: 240 seconds]
<Amit_T>
Finally, just got my package of Pine64 :) :)
<KotCzarny>
straight or bent? ;)
<lennyraposo>
lol
<lennyraposo>
probably bent and tehn straightenend by the post man
<lennyraposo>
;)
<Amit_T>
I haven't opened it , looks very light though
<lennyraposo>
it's a light package
<lennyraposo>
but it's adecent box
<lennyraposo>
should prevent any serious nedning
<Amit_T>
but it doesn't contain "unattached power switch" as many has mentioned it comes up with ?
<lennyraposo>
bending
<lennyraposo>
that's what shutdown -r now is for ;)
<lennyraposo>
or reboot
ricardocrudo has joined #linux-sunxi
<lennyraposo>
or you can do a kill switch at the usb cable
<lennyraposo>
;)
<Amit_T>
lennyraposo: Sorry didn't get you but is it comes with unattached power switch ?
<KotCzarny>
he means there is no power switch on the board
<lennyraposo>
well I got a dev release I believe
<lennyraposo>
and it didn't come with one
<Amit_T>
so how to power it up?
<KotCzarny>
connect power
<Amit_T>
is it same as orangepi pc ?
<Amit_T>
I mean same power supply should work here too?
<lennyraposo>
is it 2A 5V
<KotCzarny>
i think it has microusb power connector, i might be wrong tho
<lennyraposo>
it does have a micro sub
<lennyraposo>
usb*
<lennyraposo>
I have powered it off a usb port on a dell gx620
<lennyraposo>
but power supply is best
<lennyraposo>
and aslo an auth key 5 port usb charging station
<Amit_T>
In that case I think I can apply same power supply as I am using for Orangepi pc
<Amit_T>
?
ricardocrudo has quit [Ping timeout: 250 seconds]
<KotCzarny>
yes, but as tkaiser already found out 1.8A on the microusb is too little under full load
<KotCzarny>
so either throttle or clockdown max mhz
clonak has joined #linux-sunxi
willmore has joined #linux-sunxi
<Amit_T>
ok , my only worry is , I should not damaged the board after applying wrong power supply
<KotCzarny>
nah, 5v either via microusb or some pin probably
<Amit_T>
ok Thanks I would give it a try.
apritzel has joined #linux-sunxi
orly_owl has quit [Read error: Connection reset by peer]
orly_owl has joined #linux-sunxi
clonak has quit [Ping timeout: 240 seconds]
<Amit_T>
montjoie: Thanks for your comments .
<montjoie>
:)
<montjoie>
Remove the first BIT(29) and with lucks it will work
<apritzel>
does the OPi U-Boot run with caches enabled? I guess you would need some cache maintenance then for the EMAC DMA buffers ...
<Amit_T>
montjoie: To be honest with you, I did try different combination of write order before posting it but nothing seems to work
<Amit_T>
apritzel: Yes, that is what I am going to ask, how should we take care of cache here ?
matthias_bgg has joined #linux-sunxi
<apritzel>
if the MMU is on I think you should do a "clean and invalidate by VA to the point of coherency (PoC)"
<Amit_T>
apritzel: Do you mean that I need to take care of invalidating the caches at right point ?
ricardocrudo has joined #linux-sunxi
<apritzel>
Amit_T: as a quick check you could also turn the caches off: CONFIG_DCACHE_OFF somewhere in some U-Boot board config file
<apritzel>
maybe you need also CONFIG_ICACHE_OFF to prevent the MMU from being enabled
<Amit_T>
apritzel: Ok Thanks for this idea
<Amit_T>
I would try it as soon as I got an access to board .
dlan has joined #linux-sunxi
vetkat has joined #linux-sunxi
vetkat has joined #linux-sunxi
clonak has joined #linux-sunxi
<Amit_T>
apritzel: To your point, "if the MMU is on" but if it is on then I should not be able to use RAW physical addresses as I am doing in code base ?
<apritzel>
the MMU is using an identity mapping, so virtual address == physical addresses
<apritzel>
the MMU is really just on because you can't enable the caches without it - and without the caches some things are noticeably slower
<Amit_T>
oh and this identity mapping would be gone once kernel comes up , right ?
<apritzel>
Amit_T: yes, the MMU is turned off before the kernel is entered (as required by the ARM and arm64 kernel boot protocol) and the kernel installs its own mapping then - more sophisticated, of course
<Amit_T>
ok
<Amit_T>
apritzel: But I used to read in text books like u-boot runs with MMU off, which I think is not right.
<apritzel>
this is per board setting
<apritzel>
many boards run with caches off, but most sunxi boards enable them, IIRC
<apritzel>
I turned the MMU off for the Pine64 to be able to run in HYP/EL2, because the U-Boot MMU code does not support EL2 page table, AFAIK
<Amit_T>
ok, This is useful information for me.
<wens>
text books are not to be trusted when it comes to customization :p
<apritzel>
Yeah, also I wonder if a "U-Boot textbook" would actually become outdated while you are still writing it ;-)
<ssvb>
apritzel: if SRAM A1 is really preferable for ATF, then the SPL can probably relocate itself to SRAM C immediately after getting loaded
<ssvb>
apritzel: but the BROM still initially loads the SPL to SRAM A1 either way
<apritzel>
ssvb: yeah, I thought something like that, or ATF gets loading into SRAM C and relocates itself
<wens>
if you need PMIC support in u-boot, let me know and i can whip up something quick for you
<apritzel>
wens: I started something myself already, but couldn't get access to the PMIC via RSB
<apritzel>
the RSB registers looked fine, but I couldn't get a transaction started
<ssvb>
wens: we still need to search for some magic rsb init sequence in the arisc code
<wens>
you mean switching the pmics into RSB?
<ssvb>
the arisc code is pretty easy to read because it loads 32-bit constants as high and low 16-bit parts, so accesses to all the hardware registers are easily visible
<wens>
didn't someone disassemble it?
<ssvb>
wens: I mean that the only reference code from Allwinner for working with the PMIC on A64 is inside of arisc
<ssvb>
wens: yes, I did disassemble it ages ago, but did not look at it yet
<apritzel>
ssvb: wasn't there some dead code in the BSP kernel?
<ssvb>
apritzel: oh, then I probably missed this particular part
<ssvb>
apritzel: I only spotted the SMP init in the SDK
<apritzel>
Or maybe it wasn't about the RSB, just about the PMIC commands using the mailbox interface
<ssvb>
if there is a real RSB code in the Allwinner's SDK kernel, then we can surely try it
<apritzel>
I just remember checking my code against _some_ reference, but that may just have been the upstream kernel RSB driver
<ssvb>
wens: with a working OpenRISC toolchain, disassembling the blob is only a matter of running objdump, so it never was anything even remotely difficult
tomboy64 has quit [Ping timeout: 276 seconds]
<wens>
ssvb: i'm just lazy :p
tomboy65 has joined #linux-sunxi
<mripard>
I started to hack a radare2 plugin for openrisc too
<mripard>
I should probably finish it
<apritzel>
ssvb: is the available OpenRISC toolchain reasonable? Or is it outdated and/or badly hacked?
<ssvb>
binutils and newlib officially support openrisc
tomboy65 has quit [Ping timeout: 252 seconds]
<ssvb>
and AFAIK the GCC port is blocked because of a single contributor, who did not agree to sign the papers to transfer his copyright to FSF
tomboy64 has joined #linux-sunxi
<ssvb>
something political I guess, but still the code is GPL licensed even without the proper ownership by the FSF
<apritzel>
so GCC won't accept patches without the copyright being assigned to FSF?
<wens>
seems to be a requirement for FSF projects?
<apritzel>
ssvb: anyway that sounds reasonable from a code's perspective, I was just concerned that the code was bit-rot or against an ancient GCC version
<ssvb>
but precompiled toolchain binaries exist too
<wens>
found arch/arm/cpu/armv8/wine/spl/rsb_spl.c
<apritzel>
ssvb: ah, great, 5.2.0 sounds pretty recent to me ...
<apritzel>
ssvb: and real men (TM) build their own cross-compilers ;-)
<wens>
from what i can tell, there's nothing new about the RSB code in there
<ssvb>
wens: nice, we can try it
<ssvb>
though the arch/arm/cpu/armv8/wine/dram/lib-dram sources under the same 'wine' subdirectory differ from the working libdram blob
<ssvb>
so it might be not exactly the A64 code
<wens>
fyi the RSB mode switch call can fail if the PMICs are already in RSB mode, just ignore it
mozzwald has quit [Ping timeout: 250 seconds]
<ssvb>
plaes: thanks for testing, can you confirm that it is at least not worse than the older fel-boot-lima-memtester-on-orange-pi-pc-v3.tar.gz test on your board?
<ssvb>
plaes: by bypassing the ZQ calibration step, we are removing one level of indirection and it is interesting to know if there are any negative consequences
cnxsoft has quit [Read error: Connection reset by peer]
<ssvb>
plaes: but if jemk manages to get the short periodic ZQ re-calibration work on H3, then of course that would be the best
cnxsoft has joined #linux-sunxi
<plaes>
well, currently v3 fails in less than a minute
<plaes>
err.. a bit more than a minute
<ssvb>
I mean, does the v4-zqdebug pass the test at 648MHz just like v3?
<apritzel>
libv: really? Last time I checked they didn't mention the CPU at all ...
<libv>
it doesn't
<ssvb>
plaes: but on my Orange Pi PC, the v4-zqdebug takes takes a lot longer to fail at 696MHz than v3 and both pass at 672MHz, so it feels like at least a minor improvement :)
<libv>
"At the core of THE 64 ™ is a low cost, high power ARM Cortex SoC, which provides all the modern interfaces demanded by today’s consumers. "
<plaes>
yeah.. 672MHz with v4 "feels" better
<libv>
hrm, true, they are not saying wether the thing has an actual 64bit soc
<apritzel>
libv: also it smells more like a simple C64 emulator, so the "64" is more about nostalgia than about bitness, I guess ;-)
<libv>
hrm, 10d old campaign and only 30% funded
<libv>
they are not going to make it
<plaes>
ok.. v4 fails after ~5 minutes
<plaes>
ssvb: could you add feature that writes seconds from start via UART?
<ssvb>
plaes: you can count the number of passed memtester rounds
<ssvb>
still it's all mostly about the probabilities and to some extent the temperature drift during the test
<ssvb>
I guess, we can model it as having a certain probability P to survive the test for 1 minute, surviving 2 minutes would be P ^ 2, surviving 3 minutes would be P ^ 3 and so on
<ssvb>
the a10-tpr3-scan program also has cool down pauses to take the temperature changes into account
<ssvb>
maybe the FEL based lima-memtester should implement them too
<speakman>
Seems like A20 doesn't provide much of external interrupts. Now I'm about to test an i2c multitouch driver (eGalaxy 3000) which seem supported by the Linux kernel, but requires interrupt to work. Any ideas if there are no external interrupts available?
<wens>
there are some pins that support external interrupts
<wens>
check the datasheet, pin functions sections
<speakman>
wens: there are two, and they are already busy :(
<wens>
should be more than 2
<KotCzarny>
ssvb, i can test it in the evening on my opipc if you want
<plaes>
should direct those guys back to board vendors ;)
<KotCzarny>
plaes, otoh those guys tend to spend money senselessly too
<KotCzarny>
;)
<KotCzarny>
just dont end up with the support contract ;)
pitillo has quit [Changing host]
pitillo has joined #linux-sunxi
techn has quit [Ping timeout: 250 seconds]
techn has joined #linux-sunxi
keesj has joined #linux-sunxi
a|3x has joined #linux-sunxi
gzamboni has quit [Ping timeout: 246 seconds]
IgorPec has quit [Ping timeout: 250 seconds]
JohnDoe_71Rus has joined #linux-sunxi
bananaN00b has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
Nacho__ has joined #linux-sunxi
Nacho_ has quit [Read error: Connection reset by peer]
leio has quit [Remote host closed the connection]
<bananaN00b>
hi, i am having a really bad time putting a vanilla debian on an encrypted sata using the Banana Pi board (A20). From what I read, the easiest way should be to use the universal SD card image (https://github.com/ssvb/sunxi-bootsetup/releases/) to run the debian installer. However, it seems the device does not even boot... I also tried to setup from an existing armbian/bananian using debootstrap, but then I don't know how to c
<bananaN00b>
So I actually need some general advice on how to proceed as I am kind of stuck...
<ssvb>
the manufacturer and model no. would not tell much
<ssvb>
the U-Boot bootloader is supposed to do automatic EDID detection and use your monitor/TV for output, but apparently this does not work right in your case
<bananaN00b>
So its either the monitor or some issue on the board...!? Guess I can't avoid that UART adapter then.
<ssvb>
yes, or maybe a bad HDMI cable
<bananaN00b>
The cable works with other devices. Could this still be a reason?
<bananaN00b>
Is it worth a try to check another monitor? I do not have easy access to one and if you say that won't work probably I'm going to skip it. The exact monitor and HDMI cable work fine with one of my laptops
<ssvb>
yes, if you have a standard LCD monitor (not a TV), then it is almost guaranteed to work
<TheLinuxBug>
The only way your going to know how it is failing is to see some type of output, so you either need to attach it to another screen or you will need to get a UART cable so you can see the serial console to find out whats going on.
<bananaN00b>
Ok. Thanks for your help. I'll do my homework and come back in case I can't do it on my own
leio has joined #linux-sunxi
bananaN00b has quit [Quit: Page closed]
yann|work has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
tkaiser has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 260 seconds]
Nacho__ has quit [Remote host closed the connection]
Nacho_ has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
dev1990 has joined #linux-sunxi
jernej has joined #linux-sunxi
bwarff__ has quit [Ping timeout: 252 seconds]
apritzel1 has quit [Ping timeout: 244 seconds]
kaspter has quit [Remote host closed the connection]
matthias_bgg has quit [Remote host closed the connection]
naraic has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
matthias_bgg has quit [Read error: Connection reset by peer]
lemonzest has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
<plaes>
ssvb: ran with v4@648MHz few times and works fine
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1 has joined #linux-sunxi
IgorPec has joined #linux-sunxi
Netlynx has joined #linux-sunxi
ssvb has quit [Ping timeout: 252 seconds]
<jemk>
plaes, ssvb: periodic zq cal on ddr chip side can be enabled with mw.l 0x01c63124 0x02000040 and mw.l 0x01c63128 0x02008000 in u-boot if you want to try
<KotCzarny>
ssvb: opipc failed after similar amount of time as in v3
<KotCzarny>
gotta check if 648 passes (it does in v3)
nove has joined #linux-sunxi
zuikis has joined #linux-sunxi
ganbold has quit [Ping timeout: 244 seconds]
bwarff__ has joined #linux-sunxi
<apritzel>
NiteHawk: are you sure that the "broken DT" comment for Linux 4.6 in the mainling effort wiki page actually still applies?
<NiteHawk>
broken DT, 4.6? doesn't ring a bell immediately - please bear with me for a moment, i'll have to check that
mossroy has joined #linux-sunxi
<NiteHawk>
ah, okay - i see. that comment wasn't from me, i just reformatted it. but i remember i had to rebuild my .dtb for A20 (bananapi), as something changed in 4.6 over previous versions
<apritzel>
NiteHawk: yes, you made that warning more prominent
<apritzel>
but I was under the impression that this is no longer true, as we didn't take the incompatible pll6 rework patch
<wens>
apritzel: the breakage lies with emmc ddr support
<apritzel>
oh
<wens>
ddr mode needs a stronger drive strength for the pins
<NiteHawk>
that's quite possible - i've checked it with the early RCs (-rc1 and -rc2) i think, so it might not be up to date
<wens>
a DT change is required, or the eMMC stops working
<apritzel>
wens: but why is this incompatible?
<apritzel>
did the driver change and interprets something in the DT differently?
<NiteHawk>
wens: as i'm not using emmc, i think for me it was the PLL change
<wens>
no, just that the drive strength specified in the DT pinmux node is insufficient
<NiteHawk>
if necessary, i can retrace my steps there / recheck it
<wens>
NiteHawk: i put the note there for MMC DDR changes
<wens>
apritzel: if you run a new kernel with old DT, you get a whole bunch of I/O errors for eMMC, on boards that are enabled of course
<apritzel>
is that for every sunxi mmc user?
<NiteHawk>
apritzel, wens: shall i simply rephrase it "Old device trees may not work with this version (i.e. you might have to rebuild your .dtb files)", and tone it down to a "note" entry?
<apritzel>
wens: mmh, I can't find any change say for Bananapi in this regard in origin/master
<apritzel>
wens: so is it only for specific SoCs or boards?
<apritzel>
appears only for eMMC for a80 boards?
vagrantc has joined #linux-sunxi
<apritzel>
and for the Sinlinx devel board, for instance?
<apritzel>
so only for those boards which have eMMC, which aren't so many ...
<apritzel>
so toning down the message or restricting it to the affected boards (or to eMMC) sound advisable
<wens>
only newer boards use eMMC
<wens>
old pre-a31 boards all have raw nand
<NiteHawk>
apritzel: i get "Can't get timer clock" (https://paste.fedoraproject.org/359589/16041651/) with -rc4 and an older DTB. admittedly it's not from 4.5 and might be outdated - i'd have to narrow that down further
avph has quit [Ping timeout: 250 seconds]
<apritzel>
NiteHawk: on what board? Bananapi?
<NiteHawk>
yes
<apritzel>
there was an incompatible DT change in 4.3 or so, I think
Amit_t_ has joined #linux-sunxi
<mripard>
there was pretty much at every release
<apritzel>
mripard: don't get me started ;-)
avph has joined #linux-sunxi
<apritzel>
mripard: thanks for taking the pll6 rework patch, btw.
<Amit_t_>
apritzel: It was indeed an issue with cache coherency, Thanks much for pointing it out :)
<apritzel>
Amit_t_: so does it work now?
<Amit_t_>
apritzel: I think , I am getting proper arp packet now
<juri_>
so, my mmcblk0 is not showing up on my compiled kernel.
<KotCzarny>
do a diff on your config and a working one
cosm has quit [Ping timeout: 246 seconds]
<KotCzarny>
on a funny note, opipc survives connecting power in REVERSE, at least for a few seconds. no smoke, woo!
cosm has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
ricardocrudo has quit [Remote host closed the connection]
Amit_t_ has quit [Quit: Page closed]
paulk-collins has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1 has joined #linux-sunxi
clonak has quit [Ping timeout: 240 seconds]
hulu1522 has joined #linux-sunxi
clonak has joined #linux-sunxi
zuikis has left #linux-sunxi [#linux-sunxi]
IgorPec has quit [Ping timeout: 250 seconds]
<juri_>
fwiw, instead of that, i converted an initrd to a uInitrd, and booted that.
yann|work has quit [Ping timeout: 250 seconds]
_whitelogger has joined #linux-sunxi
hulu1522 has left #linux-sunxi [#linux-sunxi]
cptG_ has joined #linux-sunxi
khuey is now known as khuey|away
cptG has quit [Ping timeout: 260 seconds]
ricardocrudo has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 240 seconds]
<lennyraposo>
hey ssvb are you about?
<ssvb>
lennyraposo: yes
<lennyraposo>
quick question about the mali
<lennyraposo>
got news that allwinner is going to provide some binary for DMA Buffer
<lennyraposo>
no UMP
<ssvb>
that's perfectly fine
<lennyraposo>
so it's a good thing still
<ssvb>
yes
<lennyraposo>
my understanding is that UMP is phased out
<ssvb>
well, of course some work needs to be done, but it is manageable
<lennyraposo>
then it's a matter of removing any calls to UMP am I correct?
<lennyraposo>
from my limited understanding
<ssvb>
the reference code from ARM for the DMA-BUF mali flavour is xf86-video-armsoc
<ssvb>
it has a lot of problems, but there are some forks which address them at least partially
<ssvb>
the odroid/exynos people have been using the DMA-BUF flavor of mali for a while, so we can use some of their code
<ssvb>
lennyraposo: what about the userland blob(s)? do we have them already?
<mripard>
ssvb: we should have some in a near future hopefully
apritzel has joined #linux-sunxi
<mripard>
(thanks btw for your mails on xf86-video-armsoc)
<NiteHawk>
ssvb: while you're around - you have admin privileges on the sunxi-tools repo i think? do you mind activating CI for it on travis.org?
<lennyraposo>
that's what allwinner is packaging up for us as we speak
<lennyraposo>
the message I sent you was from Allwinner directly
<lennyraposo>
and I got confirmation they are sending it along with BSP 2 for pine
<lennyraposo>
still kernel 3.10
<lennyraposo>
next week it wil be up for download ;)
<lennyraposo>
from what I have seen of the xf86-video-armsoc it seems be maturing at a remarkable rate :D
nashpa_ has quit [Quit: Going away]
nashpa has joined #linux-sunxi
avph has quit [Ping timeout: 250 seconds]
jero_ has quit [Quit: bye]
Gerwin_J has quit [Quit: Gerwin_J]
mossroy has quit [Quit: Quitte]
avph has joined #linux-sunxi
khuey|away is now known as khuey
tkaiser has joined #linux-sunxi
<tkaiser>
longsleep: No idea why Android/RemixOS fail on 1st boot with connected Ethernet. But it was 100% reproducible (tried it twice with RemixOS). Display shows Pine64 logo (u-boot?) but floating RemixOS logo never appears (kernel loaded?)
<longsleep>
tkaiser: mhm well - i was just wondering why that is not a prio 1 issue to be fixed within ours - but i really do not care about Android at all either
<longsleep>
+h
<tkaiser>
longsleep: Me too. I tried out RemixOS just to confirm how slow SD cards impact user experience. And wondered the first time why nothing happened.
reinforce has quit [Quit: Leaving.]
<tkaiser>
At least it explains negative media attention Pine64 gets: 'As of this writing, I have tested all of the software distributions on the Pine64 wiki. Only the Ubuntu distribution works poorly' (from http://hackaday.com/2016/04/21/pine64-the-un-review/)
<lennyraposo>
You think that's strange
<lennyraposo>
should look at the partition table errors when creatign iamges with the PhoenixCard program
<lennyraposo>
both android and remix
<tkaiser>
lennyraposo: Who thinks what's strange?
<lennyraposo>
why the ethernet causes remix not to boot
<tkaiser>
lennyraposo: I can confirm that (3 weeks ago). Tried it once with an Android image and twice with RemixOS. Ethernet connected --> no booting
<lennyraposo>
may 6th a new release is expected
<lennyraposo>
for Android and Remix from what I have read
<lennyraposo>
but I do not think they solved much
<tkaiser>
lennyraposo: Who cares? The Pine64 folks do NOT document anything. That's the problem.
<longsleep>
tkaiser: what - why do they say ubuntu works poorly? I honestly think it works great.
<tkaiser>
Does it really hurt to add this to their wiki? The information to disconnect Ethernet when trying out Android or RemixOS=
<tkaiser>
longsleep: I would suspect powering problems. Reboots. Maybe a 'smart charger' has been used providing 500mA max
<tkaiser>
And of course they did not test any of your images since the Pine64 people hide them but they referred to Michael Larson's (that is 7.2 GB in size)
<longsleep>
also what does it mean - 'only the Ubuntu ..' - is that even proper english. Did the guy only test Ubuntu ?
<tkaiser>
longsleep: That was on April 21th. Only Android, RemixOS, Larson's Ubuntu image and KH Goh's Arch XFCE image listed on the wiki.
<tkaiser>
The unreviewer only managed to get Larson's Ubuntu image to boot. None of the others
<longsleep>
ah - funny that
<longsleep>
and a assume to boot means hdmi showing something right?
<lennyraposo>
that is funny
<tkaiser>
longsleep: Of course. And Larson's Ubuntu image showed a Pirates of the Caribbean desktop desktop background image. And then sudden reboots. Maybe his image sucks but most likely the usual powering problems related with Micro USB occured.
<lennyraposo>
agreed
<lennyraposo>
Pirates background is funny gotta admit
<longsleep>
how are the RPi3 folks handling this issue? I mean my RPi3 also only works with 2 of my PSU and the 'good' cables only
<longsleep>
if i ever want to use one of those things in production i need to by new cables just for that :/
<longsleep>
or can the RPi3 be powered over the pins as well?
<tkaiser>
longsleep: Also the board used by the hackaday 'unreview' was a 512MB one. And the Arch image 'featured' in the Pine64 wiki maybe was that outdated that the wrong .dts has been used. No idea and not worth the efforts to think about. Given the state of documentation by Pine64 it's already game over.
<longsleep>
yeah, i am pretty happy with the Pine64 - they should open up their store and sell the 2GB ones and forget about the rest
<tkaiser>
longsleep: I would suspect, RPi 3 can be powered through GPIO pins like the older RPis. And I would also suspect that 80% of RPi boards out there are simply collecting dust since they don't run reliably.
<tkaiser>
Micro USB encourages users to use crappy Phone chargers, USB cables from hell and 'smart chargers' not exceeding 500mA (while 'up to 2.4A' is written on them)
<tkaiser>
This is a good one (20AWG). Unlike 99 percent of cables used in the wild ;)
<longsleep>
the price is funny, 6.5EUR for 0.3m, 8.3EUR for 3m lol?
<tkaiser>
Micro USB is rated 1.8A max anyway. So applying a heatsink on Pine64, adding a fan and then running cpuburn-a53 won't work when powered through Micro USB :)
<longsleep>
right, when do you make a do it yourself video guide for creating a hollow socket adapter?
<tkaiser>
TheLinuxBug: Hmm... Olimex uses 5.5/2.1, Xunlong, CubieTech and SinoVoip/Foxconn use 4.0/1.7 and only Hardkernel the 2.5/0.8.
<TheLinuxBug>
ah
<TheLinuxBug>
your right the one on A10 may be bigger
<TheLinuxBug>
would have to pull it out and see
<TheLinuxBug>
honestly I lost my motivation to play the other day when my Odroid C2 decided to hose its self and corrupt my whole camera project, still need to go and see if I can recover any of it... me being dumb I hadn't had a chance to back it up yet.. ;(
<tkaiser>
TL Lim from Pine64 said he didn't want to use the most popular 5.5/2.1 barrel plug since this is also used by many 12V PSUs (and given the amount of intelligence the average KS crowd has, he got a point here)
<TheLinuxBug>
well it hosed my sdcard
<TheLinuxBug>
tkaiser: good point I could easily see people trying 12v adapters
<longsleep>
hehe certainly, but well, the 0.8 one would have been nice
<TheLinuxBug>
well if you get desperate you can always cut off the barrel connector and solder to GPIO or use a coonnector for gpio I guess
<tkaiser>
TheLinuxBug: But you have to know before that Micro USB is simply asking for troubles.
<longsleep>
i want to build a female barell socket for the pine64
<tkaiser>
So many people simply don't get how 'smart chargers' or 'smart charging hubs' behave: They won't provide anything above 500mA to a dumb device like any SBC.
<TheLinuxBug>
tkaiser: tell me about it, especially with an external hard drive on USB , if you dont have the right USB cable and adapter it just wont work
<TheLinuxBug>
The actual adapter I got with my Pi2 couldn't even meat the requirement
<TheLinuxBug>
had to get a higher gauge usb cable and a nicer adapter
<TheLinuxBug>
meet*
<TheLinuxBug>
tkaiser: I think I was telling you about the silicon power 16gb elite cards, thats one of the ones I had die on me in my Ordoid C2 the other day, so may not have a good lifetime even though throughput was good
<tkaiser>
TheLinuxBug: Don't remember. But I wouldn't buy any SD card that is not from either SanDisk, Samsung, Toshiba or Transcend.
<tkaiser>
I don't like noname cards, Kingston and the like
<TheLinuxBug>
Well I had very good results in my A20s but I kept IO usage low on those devices, in the c2 I had constant IO on it with processing for zoneminder (I had intended to eventually attach a SSD via USB for this reason)
<TheLinuxBug>
and I came in the other day
<TheLinuxBug>
to find it in a weird state
<TheLinuxBug>
then restarted it and the kernel was corrupt I believe
<TheLinuxBug>
I am not sure if I lost everything, I need to put it in my A10 and see how the sd card actually is and see if I lost more than the kernel
reinforce has joined #linux-sunxi
<tkaiser>
lennyraposo: http://forum.pine64.org/showthread.php?tid=631&pid=7021#pid7021 Time for some unpaid helpdesk job. Burning RemixOS with dd can't work (and BTW: The whole OS X instructions linked to are wrong). Game over for Pine64. They lost since they do not want to provide appropriate documentation.
reinforce has quit [Remote host closed the connection]
<willmore>
longsleep, My pi3 undervolt throttles when running four cores of cpuburn when powered over USB. If I power it over the I/O connector, it can run at full speed (with a heatsink and a fan)
<ssvb>
willmore: the proprietary firmware running in rpi3 on the vpu core monitors the input voltage and if it drops too much, then reduces the cpu clock speed
<ssvb>
willmore: basically, it serves roughly the same role as the arisc (openrisc) core in a64
<ssvb>
willmore: moreover, the rpi3 can show the undervoltage warning on the monitor
<ssvb>
too bad that the pine64 board does not have any programmable LEDs, they could be used for indicating various types of errors
<ssvb>
we could probably workaround the power consumption problems in the pine64 in the bootloader after we get the PMIC support working
<ssvb>
that would just need to gradually increase the cpu load and read back the voltage
<ssvb>
if the voltage drop is observed, then just limit the maximum cpu clock speed in the device tree blob
<ssvb>
the users of the crappy USB cables will just have to run the board at half speed or something like this :)
tkaiser has joined #linux-sunxi
<tkaiser>
ssvb: What to do with 'smart' chargers not providing more than 500mA?
<ssvb>
tkaiser: I would guess that the voltage provided by these chargers also starts dropping when getting closer to 500mA?
<ssvb>
tkaiser: if not, then the board will just fail to boot anyway during this bootloader power load test
<tkaiser>
ssvb: According to a friend his 'smart charging hub' does not behave like that. Constantly providing 5.1V @ 500mA
<tkaiser>
ssvb: But currently Pine64 users simply experience stability problems. They're not even aware that undercurrent/undervoltage might be the reason.
andrewsh has quit [Ping timeout: 260 seconds]
nove has quit [Quit: nove]
<ssvb>
tkaiser: how is this even possible, for example if you connect a resistor with a low nominal to such a charger?
<ssvb>
tkaiser: I would still expect either some voltage drop or a "smart" poweroff
<tkaiser>
ssvb: No idea. I'm no hardware guy.
<ssvb>
tkaiser: still even with the current longsleep's software stack, we can probably try to see if we can talk to the arisc firmware via the mailbox interface and read the input voltage
<ssvb>
tkaiser: and then implement the voltage drop test in the bootloader
<willmore>
ssvb, I've not found a way to see any indication of the under voltage warnings. Any tips on where to look? There was nothing in the kernel logs.
<tkaiser>
ssvb: That would be great. But what will then happen? The Pine64 folks today only feature the 'wrong' OS images and supress every piece of information. When we improve something they simply rely on the older unimproved images.
<ssvb>
tkaiser: you are being a bit too negative :)
<ssvb>
the pine64 folks don't have much experience and probably prefer learning the hard way
<tkaiser>
ssvb: Sure, but it's too frustrating since with a little bit of maintained documentation so much could be improved.
<ssvb>
but yes, most of this mess had been pretty much predictable
<tkaiser>
ssvb: Game lost with BSP kernel and current state of Pine64. Let's focus on mainline stuff for A64 :9
<ssvb>
the game is not really lost, it's mostly the same story as with the opipc
<ssvb>
the problems can be fixed, but the first impression indeed does matter a lot
<ssvb>
now we will have a lot of archived information all over the Internet about how the pine64 board sucks
<ssvb>
and people will be making their buying decision partially based on this information
<apritzel>
clever Allwinner code for udelay compiles to ....
tomboy64 has quit [Ping timeout: 250 seconds]
<apritzel>
0000000040000cac <udelay>:
<apritzel>
40000cac: d65f03c0 ret
<tkaiser>
ssvb: True, then add the usual 'Allwinner sucks' to it... we'll see. Too tired now. I really hope they improve documentation a little bit. Since this would help a lot preventing those negative 'first experiences' with their board.
naraic has quit [Remote host closed the connection]
tomboy64 has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
tomboy64 has quit [Ping timeout: 260 seconds]
akaizen has joined #linux-sunxi
avph has quit [Ping timeout: 250 seconds]
avph has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
<apritzel>
ssvb: do I need to prepare anything for executing ARM code from SRAM?
<apritzel>
still trying to run ATF from SRAM C (starting at 0x30000), and it dies at the first branch
<apritzel>
I manage to get single characters via serial (via a handful of assembly instructions to do the "str")
<ssvb>
apritzel: don't know, AFAIK nothing special should be necessary
<apritzel>
but as soon as there is the first "bl somewhere", it stops
<ssvb>
you can try to upload & run the code in FEL mode
<apritzel>
this is 64-bit code
<agraf>
apritzel: how do you jump to it?
<apritzel>
and I am using FEL already to load SPL + U-Boot
<agraf>
apritzel: are you just running in ATF and memcpy() it over?
<ssvb>
yes, I mean the SRAM C should be at least usable in principle to run the code in the 32-bit mode
<ssvb>
do you setup the MMU?
<apritzel>
in the first "proper" U-Boot instructions I do the RMR reset to ATF
<apritzel>
that works perfectly fine when I load ATF into DRAM
<apritzel>
MMU is still off, I even turned I cache off
<apritzel>
ssvb: does the FEL loader run with caches off?
<ssvb>
on A64 it should run with the caches off
<apritzel>
agraf: are you thinking about cache maintenance? stale I cache does not hold what you just written?
<ssvb>
on other SoCs we enable the MMU and the I-Cache for the BROM addresses to improve performance
<agraf>
apritzel: yeah
<apritzel>
agraf: but I execute some meaningful code
<apritzel>
but it could be the branch predictor
<apritzel>
I think there is some instruction to flush or disable that
<ssvb>
can you at least read/write SRAM C from the 64-bit code?
<agraf>
apritzel: so you're saying it works until you hit a bl?
<apritzel>
agraf: exactly
<agraf>
apritzel: relative?
<agraf>
apritzel: or register based
<apritzel>
ssvb: do you suspect otherwise?
<apritzel>
relative
<apritzel>
agraf: ^
<agraf>
hmhm
<ssvb>
well, it's better to be safe than sorry
<ssvb>
is this BL instruction trying to transfer control to the code in the SRAM C or is it already a part of the code inside SRAM C?
<apritzel>
ssvb: it's already executing in SRAM C
jernej_ has joined #linux-sunxi
<apritzel>
it got transferred there via the RMR
<ssvb>
maybe it makes sense to experiment with the ATF in DRAM
<ssvb>
and probe what can be done with the SRAM C from there
ganbold has joined #linux-sunxi
jernej has quit [Ping timeout: 260 seconds]
<apritzel>
ssvb: yeah, good idea
<apritzel>
or I could even use U-Boot to load & execute something
<apritzel>
though this is running in AArch32 in my case
<apritzel>
but that shouldn't make a difference
<agraf>
apritzel: i also never managed to get the SPL working from sram
<agraf>
apritzel: in 64bit mode
<apritzel>
agraf: which SRAM was that? SRAM A1?
<apritzel>
so loaded via boot0 or via FEL?
<agraf>
loaded instead of boot0
<agraf>
wherever that put it
<apritzel>
A1 I think, at 64K just after the BROM
<apritzel>
interesting: a dummy bl sequence worked:
<ssvb>
just a random idea, I wonder if the address space layout is the same in the 64-bit mode?
<apritzel>
bl 1f
<apritzel>
b 2f
<apritzel>
2:
<apritzel>
1: ret
<ssvb>
or maybe something is simply clearing the SRAM when you are doing RMR reset?
paulk-collins has quit [Remote host closed the connection]
<apritzel>
ssvb: at least some code is working, I see "AB" on the serial, but the "CDE" is missing
<apritzel>
but I could prove this by using DRAM for ATF and loading something into SRAM C via FEL, then verify this with U-Boot's md.l command
<agraf>
ssvb: or maybe just using, not clearing
<agraf>
ssvb: the boot rom for example
<agraf>
ssvb: but that shouldn't execute in RMR, should it?
<apritzel>
agraf: no, RMR is architectural, so it's entirely in the A53s, no Allwinner involved
<agraf>
so no boot rom
<apritzel>
ssvb: btw: so lucky to have FEL working, makes this debugging so much easier!
<ssvb>
apritzel: still IMHO it makes sense to test whether there is any corruption in the SRAM anywhere in a reasonably large block
<apritzel>
ssvb: yes, doing this right now ...
<apritzel>
holy sugar ssvb, I owe you a beer!
<apritzel>
loading 64K to 0x30000
<apritzel>
reading looks fine until 0x33000
<apritzel>
afterwards all zero
<apritzel>
and guess what? that first bl goes to 0x343cc
<apritzel>
oh dear, either there is no SRAM after 0x33000 or it's somehow blocked
<apritzel>
"mw.b 0x32000 55 40; md.b 0x32000 40" works as expected
<apritzel>
the same at 0x33000 returns all zeroes
<apritzel>
apparently no SRAM between 0x33000 and 0x40000, from 0x40000 arisc IRQ vectors every 256 bytes until 0x42000 as expected, the rest of the SRAM matches the manual
<ssvb>
both in the 64-bit and the 32-bit mode?
<apritzel>
from AArch32 HYP (U-Boot)
<apritzel>
so could be secure only as well as per this experiment
<apritzel>
but RMR drops in AArch64 EL3
<apritzel>
and we have a liftoff!
<apritzel>
loading ATF to 0x20000 works
<apritzel>
uses less than 64KByte (with DEBUG=1 LOG_LEVEL=50)
<apritzel>
I think DEBUG=0 brings it down to under 32KB
<apritzel>
ssvb: thanks so much for that hint!
<ssvb>
you are welcome
<apritzel>
now on to remove ALL that debug code again ;-)
<apritzel>
but the code injected via FEL should run in monitor mode, right? so no security restrictions.