<apritzel>
sdwrage: please note that the OS situation is far from ideal at this point and you can't expect the level of Linux support you would see on a PC or the Raspberry Pi
<sdwrage>
apritzel, oh I totally understand
<sdwrage>
I just want to try and get something to work
<sdwrage>
and hope for a gui to work right now
kaspter has joined #linux-sunxi
<apritzel>
hope dies last ;-)
kaspter1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 276 seconds]
TheSeven has quit [Ping timeout: 276 seconds]
TheSeven has joined #linux-sunxi
Tusker has joined #linux-sunxi
<Tusker>
heya guys, I have the A83T on the BPi M3, and based on http://linux-sunxi.org/Linux_mainlining_effort, it looks like the A83T has been merged into 4.6. Does that mean that it is expected to boot ?
apritzel has quit [Ping timeout: 244 seconds]
kaspter1 has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
FlorianH has quit [Read error: Connection reset by peer]
sdwrage has quit [Quit: Leaving]
tsuggs has joined #linux-sunxi
ninolein has quit [Ping timeout: 276 seconds]
<wens>
Tusker: expected to boot and nothing more :)
<Tusker>
wens: OK :) what is missing to have init starting ?
<Tusker>
i've got a copy of the uboot and linux from git, which includes your USB changes
ninolein has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
<wens>
then it should boot?
<wens>
remember to set a console
<Tusker>
OK, I will experiment with the code Vishnu and yourself. Do you have a list of things that you are working on, and/or need some help ?
<wens>
usb is done for the most part
<Tusker>
OK, but for a fully working system, there is probably more work to be done? Is there a list that Vishnu maintains ?
<wens>
don't think so
<wens>
emac is being worked on
<wens>
then comes pmic
<Tusker>
OK, I suppose I will find out the status once I try and get some initrd happening
<Tusker>
does uboot work OK so far ?
<wens>
it does
<wens>
what features are you looking for?
<Tusker>
well, I'm just trying to get a vanilla server install happening of jessie
<wens>
that should work
<Tusker>
want to start with a clean slate, and will be doing some GPIO and USB programming of TI chips
<wens>
though i use debootstrap instead of the installer
<Tusker>
do you have any build scripts that you use including ARCH targets ?
<wens>
it's all manual
<Tusker>
do you have a bash history that I could create a script ? :)
<wens>
probably not
<Tusker>
OK, I'll work on it then, see if I can script something to build a jessie image using the git versions of linux and uboot
<wens>
fyi sunxi_defconfig isn't useful when it comes to usb peripherals
<Tusker>
do you have a defconfig that you use ?
<wens>
i have a config that enables a bunch of stuff i use, yeah
<Tusker>
do you mind sharing as a starting point?
<Tusker>
(sorry if it is asking too much, just don't want to replicate work that has already been done/completed)
a|3x has quit [Ping timeout: 244 seconds]
<Tusker>
also, what toolchain do you use to build ?
p1u3sch1 has quit [Ping timeout: 244 seconds]
<wens>
cross compile toolchain in unstable :)
<Tusker>
:) OK
<Tusker>
is your defconfig in git somewhere ?
<wens>
nope
p1u3sch1 has joined #linux-sunxi
<wens>
i suggest you start with sunxi_defconfig and enable whatever usb peripherals are needed
<Tusker>
OK
<Tusker>
I'll try that out
<wens>
my config is littered with debug options
<Tusker>
to confirm, sunxi-a83-wip is the correct branch to be working off ?
diego_r has quit [Read error: Connection reset by peer]
nihcas has quit [Ping timeout: 276 seconds]
longsleep has quit [Ping timeout: 276 seconds]
ninolein has quit [Read error: Connection reset by peer]
avph has joined #linux-sunxi
arossdotme has quit [Ping timeout: 276 seconds]
[Awaxx] has quit [Ping timeout: 276 seconds]
bamvor has quit [Ping timeout: 276 seconds]
souther has quit [Ping timeout: 276 seconds]
tomboy64 has quit [Ping timeout: 276 seconds]
leio_ has joined #linux-sunxi
leio has quit [Ping timeout: 276 seconds]
[Awaxx] has joined #linux-sunxi
ninolein has joined #linux-sunxi
arossdotme has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
souther has joined #linux-sunxi
mpmc has joined #linux-sunxi
<oliv3r>
wens: you are right about the no-1.8v property, but why mention the supply, the supply is mentioned 3 lines higher, vmmc = reg_3.3
<oliv3r>
unless vqmmc is a eMMC specific thing, i cna't find anything in the do about it
<oliv3r>
docs*
<oliv3r>
wens: also, are you familiar with the cap-mmc-hw-reset? hw reset can be either via a pin or via a mmc command, which one is implied with this property? Since the reset line is hardwired to sdc2_reset on the lime2 and the chip supports the other reset aswell
kaspter has quit [Ping timeout: 260 seconds]
<oliv3r>
wens: and sorry about wronging your name! :)
bamvor has joined #linux-sunxi
<oliv3r>
it was not intentional :)
nihcas has joined #linux-sunxi
apritzel has joined #linux-sunxi
<wens>
oliv3r: vqmmc is something that was added in 4.6 by me
<wens>
basically for sd & emmc, there are 2 supplies, vmmc supplies power to the card's internals
<wens>
vqmmc supplies power for the i/o signals
<wens>
on allwinner boards the 2 are typically tied together, but they mean different things
<wens>
cap-mmc-hw-reset means the controller can signal the reset, as opposed to a gpio
<wens>
not sure if a10/a20 support it
<Amit_T>
apritzel:montjoie: Hello, able to tftp kernel and other images but I do see this when bootz , http://paste.ubuntu.com/16199625/
<Amit_T>
Now this needs to be taken by kerenl or u-boot source ?
<apritzel>
Amit_T: great!
<apritzel>
Amit_T: the mishap looks like you have to disable the EMAC properly before leaving U-Boot
<Amit_T>
apritzel: Thanks :)
<Amit_T>
ok
<apritzel>
Amit_T: do you have a patch somewhere?
DullTube has joined #linux-sunxi
<apritzel>
Can you maybe send it to the linux-sunxi list as a start?
<Amit_T>
oh sorry , not have access that machine now where patch is present
<apritzel>
Amit_T: well, don't have time for that now anyway
<Amit_T>
but do I need to send it to u-boot list or kernel list ?
<oliv3r>
wens: ahh so it is that, okay i'll add vqmmc as a 3.3 source as well
<apritzel>
u-boot list, of course
<Amit_T>
ok ,Also about this crash , is itn't it's duty of linux to take care of it , I mean I am just thinking
<oliv3r>
wens: well the host driver talks to the registers, and the eMMC chip supports it
ricardocrudo has joined #linux-sunxi
<apritzel>
Amit_T: maybe, needs to be investigated
<apritzel>
Amit_T: that's why I was asking for the U-Boot driver ...
<apritzel>
code
<apritzel>
Amit_T: also a driver does make certain assumption, like no pending DMA transfers, for instance
<Amit_T>
apritzel:ok , Also this code is running with cache off, so I have to take care of that as well , right ?
<Amit_T>
ok
<apritzel>
Amit_T: Do you mean your driver requires the caches to be off?
<Amit_T>
Yes
<Amit_T>
I mean I haven't tested it with cache on
<apritzel>
just send the code and we will see
<Amit_T>
but its likely to be failed
<Amit_T>
ok, I will send it.
<apritzel>
well, I'd love to play with it on the Pine64
kz1_ has quit [Quit: kz1_]
<Amit_T>
Me too :)
<apritzel>
U-Boot seems to be more hackable in this regard, so debugging a Pine64 MAC driver on U-Boot may be easier
<Amit_T>
Just waiting for USB to USB cable to come
<Amit_T>
Yes, it looks so
<apritzel>
btw: I managed to get my whole new image working yesterday night
<apritzel>
with 64-bit upstream U-Boot, heavily Allwinner-stripped ATF in SRAM and no arisc, all loaded from boot0
<Amit_T>
Nice, This images containes ATF and all?
<wens>
with u-boot you can play with registers, and shoot your feet in the process :)
<Amit_T>
ok
<apritzel>
wens: sure, but with it's quickly reset and re-loaded, with FEL boot you can even fix it very quickly
<wens>
true
<Amit_T>
apritzel: Just wanted to check, boot0 source present in sd card ?
<apritzel>
there is not boot0 source, I just take the binary blob from Allwinner
<apritzel>
we don't have an alternative to that yet
<apritzel>
needed some tricks and trampolines to convince boot0 to do what I wanted
<KotCzarny>
tkaiser: you are advocating 1.3ghz on h3, yet in armbian max_freq in fex is set to 1.2ghz?
FlorianH has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 250 seconds]
p1u3sch1 has joined #linux-sunxi
DullTube has quit [Quit: Leaving]
<wens>
montjoie: i guess it's still under debate?
<wens>
no one else replied
<apritzel>
wens: are you referring to that older thread on linux-sunxi?
<apritzel>
apritzel: so it's OK to revive this?
<wens>
apritzel: the actual ephy driver submission
<wens>
rfc
adj__ has quit [Ping timeout: 240 seconds]
adj__ has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
Amit_T has quit [Ping timeout: 246 seconds]
<KotCzarny>
wth hdmi is ifdeffed with config_switch
orly_owl_ has joined #linux-sunxi
Amit_T has joined #linux-sunxi
orly_owl has quit [Ping timeout: 246 seconds]
tipo has quit [Remote host closed the connection]
Shirasaka-Hazumi has quit [Ping timeout: 252 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
IgorPec has quit [Ping timeout: 246 seconds]
tipo has joined #linux-sunxi
reev has quit [Ping timeout: 260 seconds]
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Client Quit]
Amit_T has quit [Quit: ChatZilla 0.9.92 [Firefox 40.0/20150807094952]]
Amit_T has joined #linux-sunxi
tipo has quit [Remote host closed the connection]
<oliv3r>
mripard: the eMMC board was developped with Ultimaker (we needed eMMC over nand); I know olimex sells them allready, there are users on the armbian forums for example that have these boards as well. I do not know when olimex will update their web-shop for it.
premoboss has quit [Remote host closed the connection]
reinforce has quit [Ping timeout: 260 seconds]
nove has joined #linux-sunxi
afaerber has quit [Quit: Ex-Chat]
tkaiser has joined #linux-sunxi
tkaiser has quit [Client Quit]
tkaiser has joined #linux-sunxi
tkaiser has quit [Client Quit]
tkaiser has joined #linux-sunxi
<tkaiser>
KotCzarny: Armbian uses 1296MHz on all H3 boards that are equipped with SY8106A voltage regulator and therefore able to exceed 1.3V when necessary. On other boards (OPi One/Lite/Zero, NanoPi M1, BPi M2+) we limit this to 1200 MHz since there VDD_CPUX is 1.3V (max). So we've to fear reliability problems. It's still 100% unrelated to what you're thinking
<lvrp16>
tkaiser: you're not supporting my liquid nitrogen setup though, please support ln2 cooled orange pi ones capable of 2.0ghz
<tkaiser>
lvrp16: :P and same 'wrong' focus as KotCzarny. It's mostly about VDD_CPUX and realibility
reinforce has joined #linux-sunxi
<lvrp16>
everybody has access to LN2. your focus is too narrow
<lvrp16>
plus 2.0ghz performs way faster
<lvrp16>
;)
<tkaiser>
It's still about reliability. If you can increase VDD_CPUX so that 2.0 GHz are possible with liquid cooling (and longevity minimized to 14 days). Why not?
<tkaiser>
But you can't increase VDD_CPUX that much without getting in trouble. And that's the reason 1536 MHz are a problem and not temperature in the first place
<lvrp16>
but i want to have the highest score on the sunxi benchmark wiki
<lvrp16>
my life depends on it
<lvrp16>
sunxi wiki benchmark page
<lvrp16>
nvm
<lvrp16>
tkaiser: i didn't check myself but can you ssh as root/1234 after imaging?
<lvrp16>
to setup the user account?
<lvrp16>
or is it restricted to local login only?
<tkaiser>
lvrp16: Always SSH enabled, you just need a DHCP server or are able to deal with link local addresses (169.254.0.0/16 ;)
<lvrp16>
so root login is enabled by default right?
<Shirasaka-Hazumi>
yeah
<lvrp16>
ok thanks ;)
<tkaiser>
Sure, root/1234 and then new password, then new sudo enabled user account.
jernej has joined #linux-sunxi
Blauapause has joined #linux-sunxi
<lvrp16>
awesome, a lot of users complain about no video
<lvrp16>
i'm trying to see why it failed to negotiate the right res
<lvrp16>
vizio TVs are terrible...
<Shirasaka-Hazumi>
which version?
<wens>
oliv3r: still wonder if the pinmuxes actually have 8bit for sdc2
<wens>
oliv3r: i guess you could try it, since the signal traces are there on the board
<lvrp16>
this was on armbian 5.05, i will have them upgrade to 5.10
<tkaiser>
lvrp16: We use 720p50 or 720p60 (changed that back at 5.03). Some people experience massive overscan issues. But 'no display' is new
<Shirasaka-Hazumi>
caused by new kernel?
<tkaiser>
lvrp16: And people are asked on 1st boot to change display resolution to their needs using h3disp. It seems it's only an issue with first boot since they don't even see that they should login due to overscan issues.
<Blauapause>
Qucik (stupid) question: I am on a cubietruck running ubuntu LTS 14.x (with root on /dev/sda ) - would like to migrate to Debian (to get updates, etc) .. Any recipe on how I can do this? (booting with the Debian Installer image on sdcard seems to ignore sdcard, waits for sda)...
<lvrp16>
tkaiser: thanks, they are using a hdmi->dvi adapter, i told them about the -d switch
vagrantc has joined #linux-sunxi
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
<lvrp16>
tkaiser: did you fix the usb hub detection code between the plus and the one?
<lvrp16>
so that if you plug in a usb hub, it doesn't mistake it for a plus? in armbian 5.10?
<Blauapause>
ok.. I understand my sdcard is not working right, so cubietruck tries to fallback on sda
ganbold has quit [Ping timeout: 244 seconds]
<tkaiser>
lvrp16: Nope, we're still prone to 'auto detection gone wrong'. Also attached WiFi dongles create a mess. Will be fixed with one of the next releases. Simply recommend to not attach this stuff on first boot
<lvrp16>
ok thanks
<jelle>
hmm anyone got some clue if there is more info about the HDMI controller in the H3
cosm has joined #linux-sunxi
lemonzest has joined #linux-sunxi
zuikis has joined #linux-sunxi
tkaiser has quit [Ping timeout: 244 seconds]
<oliv3r>
wens: we decided to add the signal traces for 8 bits because the drop in replacement for the a20 might have all 8 lines, so no harm in adding them
<oliv3r>
wens: you might recall the image i posted on the wiki of the eMMC module we hand-solderd on a lime2, we used all 8 lines but failed to get it to work with those 8 bits. I posted it on the linux-sunxi mailing list as well
<oliv3r>
wens: and I think mmc-prwseq-emmc is what i want to add for the GPIO reset line
<oliv3r>
i'll see if i have time to test it, though i'm not quite sure yet as to how i want to test it
tkaiser has joined #linux-sunxi
IgorPec has joined #linux-sunxi
mossroy has joined #linux-sunxi
tipo has quit [Read error: Connection reset by peer]
<tkaiser>
733 jumps in. You could also delete 733 and increase the value in 734 and get 20 support requests more since a message appears when querying dmesg about 'missing extremity_freq'
<KotCzarny>
its like they just got lazy and just releasing alpha code for droid
<KotCzarny>
otoh it will make putting linux on those tablets harder
tkaiser has quit [Ping timeout: 244 seconds]
<longsleep>
I just rebased all Pine64 BSP Kernel fixes to the BSP 2.0 tree, if anyone wants to help testing if it would make sense to use that or rather stick with the 1.2 based tree check https://github.com/longsleep/linux-pine64/tree/pine64-hacks-2.0 and let me know please
Amit_T has quit [Ping timeout: 260 seconds]
apritzel has joined #linux-sunxi
tkaiser has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
Blauapause has quit [Ping timeout: 250 seconds]
<montjoie>
what is the exact sequence of cabling to do FEL for pine64, I got nothing in lsusb
<montjoie>
with sdcard it boot but whithout it I got nothing
<ssvb>
what kind of USB cable are you using?
<montjoie>
USE male A-A
<montjoie>
one side connected to upper pine64 usb the other on my USB hub
<KotCzarny>
try other port?
avph has quit [Ping timeout: 260 seconds]
<ssvb>
be sure to power off the board first, and also disconnect the UART cable
<montjoie>
I have disconnect all
<montjoie>
then FEL cable then power
<ssvb>
hmm, no idea then, normally this should work
<montjoie>
I am near sure to have seen an usb device on my last try, one month ago
avph has joined #linux-sunxi
<ssvb>
one more thing, I'm powering the board from the same powered USB hub when doing FEL experiments just to be sure that the 5V and GND voltage levels are perfectly matched
<montjoie>
same hub for both cable
tipo has quit [Remote host closed the connection]
<ssvb>
I don't feel very happy about the Pine64 board serving 5V to the VBUS pin of the upper USB receptacle by default
<ssvb>
maybe a bad USB cable? or defective/damaged board?
<montjoie>
it boot perfectly from sdcard, I will try another USB hub at work
<tkaiser>
ssvb: Is the upper the OTG?
<tkaiser>
ssvb: Consulted wiki, yes.
<montjoie>
I tried both upper and down
<ssvb>
montjoie: I mean the USB OTG part of the hardware, which might be potentially broken on your board (as one of the possible explanations)
<ssvb>
does the upper USB port at least work correctly as USB HOST in Android or with longsleep's Ubuntu images?
<longsleep>
i have never tried
* longsleep
searches an OTG adapter
<tkaiser>
ssvb: Just tried with an Apple keyboard and optical mouse: Nope. The lower does
<ssvb>
longsleep: the upper USB receptacle is expected to be configured as USB HOST in normal operating systems, I think the whole point of arranging it this way was to have 2 USB HOST receptacles
<ssvb>
tkaiser: hmm, I hope it's just a software problem and nothing is broken on the hardware side
<ssvb>
NiteHawk: can't you do this yourself?
<longsleep>
wasnt able to find an OTG adapter .. i guess it was in the bag i lost earlier this year ..
<longsleep>
the upper port works just fine with keyboard though
<ssvb>
longsleep: what are you going to do with an OTG adapter?
IgorPec has quit [Ping timeout: 240 seconds]
<NiteHawk>
ssvb: i would, but that requires administrative rights - if you temporarily grant me those, i'm happy to do it
<NiteHawk>
(travis needs an authorization/access token from github)
<ssvb>
longsleep: oh, it's good to know that it's working correctly as a USB host for you
<longsleep>
ssvb: connect it with the laptop - so the laptop becomes host
<longsleep>
ssvb: but for that i need a cable, or my fancy adapter
<KotCzarny>
longsleep, make one?
<ssvb>
longsleep: but there is no ID pin or anything that would be able to signal the switch to the device mode?
<longsleep>
ssvb: yes, both ports work just fine
<longsleep>
ssvb: mhm 5v on the extra pin - no?
<KotCzarny>
tkaiser: got a minute?
<longsleep>
KotCzarny: yeah, not in the mood for cable stuff right now
<tkaiser>
ssvb: Looks like it's 'just' power related and therefore hardware. I tried out the lower port, rebooted and only 1 out of 5 times the peripherals worked. And now with another try also the upper port works. This Apple USB stuff is crap
<tkaiser>
I remember that I was able to power off several SBCs when connecting both keyboard + optical mouse. So maybe it's just related to peak power requirements.
<tkaiser>
KotCzarny: ?
<longsleep>
funny A64 BSP 2.0 added CONFIG_RTL8723CS but the driver does not compile ..
<KotCzarny>
tkaiser: i cant get hdmi to work using armbian kernel of own compile. armbian pkgd one works, my compile doesnt, same uboot, same cmdline. cant find anything related different in .configs and dmesgs. do you know what it takes to get hdmi working?
<KotCzarny>
longsleep: alpha quality code ftw?
<tkaiser>
KotCzarny: optimize for size yes or no?
<KotCzarny>
let me check, but i think 'no'
<longsleep>
yeah, and the g2d stuff has undefines ..
<KotCzarny>
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
Netlynx has quit [Quit: Leaving]
<KotCzarny>
anything else before i recompile?
Amit_T has joined #linux-sunxi
<ssvb>
libv, Turl: what do you think about granting NiteHawk admin rights for linux-sunxi on github?
<longsleep>
g2d driver only for g2d_bsp_sun8iw11.c ... :/
<NiteHawk>
ssvb: i think the user/oauth token would be mine (logging into travis itself with my github account)? the repo is just read for group membership / access rights. travis rightfully refuses you to activate build testing for repos that you don't have admin access to
<tkaiser>
longsleep: That's the new A20E thingie I want to run headless only ;)
<KotCzarny>
tkaiser: are there any confirmed news about a20e?
<KotCzarny>
apart from bsp2.0
<tkaiser>
KotCzarny: Nope
<NiteHawk>
ssvb: but i'll also cross-check on github as to what rights travis requested / might have now
<ssvb>
longsleep: But there is still the 'transform' accelerator in A64, right? It implements a useful subset of what G2D did (pixel format conversion/rotation/scaling) and just gets rid of the ROP
<NiteHawk>
ssvb: travis has set a hook (you can check it under "Settings", "Webhooks&services") for sunxi-tools - i think that's about all it does
<ssvb>
longsleep: I did not try to experiment with it though, just checked the source code
<ssvb>
longsleep: the comment says "display engine 2.0 transform processing base functions implement", is it included in every device which has DE 2.0 hardware?
<longsleep>
btw - for now i see no point to go through the hassle with BSP 2.0
<lennyraposo>
one 46 inch with 1080p support and the 32 has 720p
<lennyraposo>
ya chekced last night
<longsleep>
network speed is unchanged, HDMI driver stopped working and codec needs DTB updates
<longsleep>
only trouble no gain
<lennyraposo>
not much changed
simosx has quit [Quit: Leaving]
<lennyraposo>
getting tired of internet throughput speeds being used as report cases in contrast to lan speed tests
<longsleep>
i have pushed everything to github, so people can try themselves and then try to convince me to give it another look that whatever works better with the 2.0 kernels
<longsleep>
lennyraposo: well, i am very good at ignoring things :)
<KotCzarny>
tkaiser: btw. hdmi works, and temperature is now 39C in idle with xorg loaded (xdm login screen)
<KotCzarny>
though my board is in horizontal position
<lennyraposo>
I htink routers switches used by most can be quite troublesome too
<tkaiser>
longsleep: Do you expect that one single individual on this planet will check out the BSP 2.0 changes?
<diego71>
ssvb: i think that emmc is slighter expensive than nand. But it should be easier to use (having a embedded controller)
<longsleep>
tkaiser: well, i still have some hopes for the people having network issues
<longsleep>
tkaiser: personally i think its just their PSU
<longsleep>
tkaiser: but who knows :)
<lennyraposo>
with the 1gb a64+ it's been pretty reliable headless
<lennyraposo>
but not production worthy
<tkaiser>
longsleep: Yeah, also my thought. But it's useless to repeat that again and again :)
<ssvb>
diego71: I guess, it depends on the volume, if emmc is produced in much larger quantities, then it may be even cheaper
<longsleep>
lennyraposo: why not - it works for me without any issue many weeks at heavy load
<tkaiser>
ssvb: diego71: How do you define 'storage performance'?
<ssvb>
diego71: still, this olimex board seems to be using SLC for eMMC, which makes it a better choice than MLC NAND at least as far as reliability is concerned
<ssvb>
tkaiser: run some benchmarks and compare results?
<diego71>
tkaiser: usually if you talk about performance, you talk about bandwidth, latency eventually
<ssvb>
tkaiser: btw, do you know if anyone has had a chance to try Orange Pi Plus 2E boards already?
<lennyraposo>
forgot to add for some others at the end of that
<lennyraposo>
got interrupted by th elittle one ;)
<tkaiser>
I'm talking about the difference between sequential speeds and random I/O. And found most recent eMMC implementations freaking fast regarding the latter even if sequnetial througput wasn't that high
<ssvb>
tkaiser: did Xunlong send any prototypes to anyone?
<lennyraposo>
for running a website it does the trick
<ssvb>
tkaiser: the sequential speeds can be also better for eMMC
<tkaiser>
ssvb: Not that I know. But Steven contacted me recently so should I ask him for linuzx-sunxi staff donations
<lennyraposo>
random i/o is the mmost important
<tkaiser>
ssvb: I know, especially when boards only implement the slow SDIO mode with 4 bit @ 50 MHz
<ssvb>
tkaiser: I think that Orange Pi Plus 2E looks very interesting, but we need to confirm if they are using a decent eMMC in it
<KotCzarny>
ssvb, ask them directly?
<tkaiser>
ssvb: If it's the same as on Plus 2 (WTC) then it's pretty fast.
<tkaiser>
I ask Steven for samples. You, wens, someone else? :)
<tkaiser>
Random writes with 16K blocksize approx. 100 times faster than with a usual PNY SD card :)
<longsleep>
tkaiser: btw, i sent tllim a list of things how they should apporach making a good official linux image - lets see what comes out of it
<jelle>
nice
<lennyraposo>
ya
<lennyraposo>
focus on 1 at most 2 variants
<KotCzarny>
tkaiser: you should only compare to decent sd card
<tkaiser>
longsleep: Good to know. I don't think that my 'approach' helps that much. As ssvb already said: Too much negativity :)
<lennyraposo>
ubuntu and debian as they are related
<lennyraposo>
I saw someone was attempting unity on ubuntu
<tkaiser>
KotCzarny: No, since no one knows what to buy. We did some tests and found that on the average sunxi board the cheap Samsung EVO perform best (since sequential speed is limited to 23 MB/s anyway)
<lennyraposo>
some sort of install script
<lennyraposo>
for gui
<lennyraposo>
btw longsleep I must say your work is great
<lennyraposo>
still no word on mali binaries from allwinner
<lennyraposo>
was suppose to be in the bsp hence why I looked
<lennyraposo>
but apprently not
zuikis has left #linux-sunxi [#linux-sunxi]
<longsleep>
jernej: interesting thanks - i have not enabled debugfs for disp - will certainly try it
<jernej>
longsleep: It can be done also through ioctl
<longsleep>
jeah but for that i need to read docs and write code
bonbons has quit [Quit: Leaving]
<lennyraposo>
major problem is that the pine marketing convinved the community at large that this is a viable unit for GUI usage
<jelle>
wutt
<lennyraposo>
it can be but not form the get go
<lennyraposo>
most peopel are expecting a gui linux distro for desktop type usage
<lennyraposo>
and watching videos etc
<lennyraposo>
which longsleep was correct in stating that android or remix is the only choices for that at the moment
<longsleep>
i marged the 2.0 bsp kernel tree as experimental and abandon it for now
<lennyraposo>
did they update the gmac
<lennyraposo>
nm
<lennyraposo>
will check for it myself
<longsleep>
yes, but i doubt that the changes have any effect - its just compatibility for whatever SoCs they have added
<longsleep>
at least i see no difference in speeds or anything with the new kernel
<nove>
don't forget about the "license issues", which are stoppers in progressing the mainline work
<longsleep>
yeah sure, kernel has two closed source libs, both related to hdmi
<nove>
for gui, hdmi is essential, how can a mainline driver be written, if the only hardware information source is the bsp driver which has no license, making default to "all rights reserved"
<longsleep>
i did not pay attention to the state of hdmi in mainline
<longsleep>
i am more concerned about the dram initialization which seems that they are unwilling to release
<longsleep>
so - blob boot0 is it for now
<lennyraposo>
and they are not budging anytime soon on that
<longsleep>
but hey, i do not need any display output :) - but booting without blobs would be nice
<lennyraposo>
for my purposes I do not need display
<nove>
what i am saying, is if the user wants gui, is not "US" that have to work harder, (we cant, because of the "license issues")
<longsleep>
really i think nobody does :)
<longsleep>
the only thing which i would need in a GUI is accellerated Chromium with hardware video decode and encode and full v4l and audio support
<longsleep>
fullscreen 1080p@60hz with 1080p uvc camera video grab without lags and no overheating
<longsleep>
that would be awesome
<longsleep>
for a 20USD board
<longsleep>
or any arm linux board for that matter
paulk-collins has quit [Quit: Leaving]
<nove>
that is possible, only the software (drivers) has to be written, and the reason why not is been done, you all know already
pmattern has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
fdcx has quit [Read error: Connection reset by peer]
<oliv3r>
ssvb: but nand has the advantage (with a good driver) that you have full control and open source. emmc is a 'black box' which requires firmware etc
<oliv3r>
diego71: that's pretty awesome :D
<oliv3r>
unfortunatly they keep calling it slc emmc, it is really just mlc afaik
<ssvb>
oliv3r: yes, that's a good point, some vendor really needs to start selling emmc with an open source firmware to get this issue resolved :)
<ssvb>
oliv3r: and we also need open source processors to eventually replace ARM
vagrantc has quit [Quit: leaving]
<ssvb>
oliv3r: hmm, why are they advertising this eMMC as SLC then?
<apritzel>
ssvb: U sure you really want _yet another_ architecture?
<oliv3r>
its wrong
<oliv3r>
the datasheet says mlc
<apritzel>
ssvb: looking at the effort it took to get arm or arm64 properly supported ...
<oliv3r>
i'll send an email to olimex to notify them
<oliv3r>
but in any case, we switched to emmc from nand as nand driver was still a no go and nand performance was very horrible
<oliv3r>
also the problem with the firmware of the mmc is, i know android has hotfixes for firmwares to fix problems
<oliv3r>
because, the firmwares can cause problems :(
<apritzel>
ssvb: speaking of other architectures: any idea why or1k-elf-objdump does not work properly for me on scp.bin?
<apritzel>
ssvb: I get:
<apritzel>
100: f2 38 00 00 *unknown*
<apritzel>
104: 00 00 00 15 l.nop 0x0
<apritzel>
so the nop is right, but why is the jump not disassembled?
<apritzel>
same for lot of other instructions later in the real code
staplr has quit [Remote host closed the connection]
fdcx has joined #linux-sunxi
<apritzel>
I tried -EB as well, but it only gets "wronger"
<ssvb>
apritzel: only substitute "arm-none-eabi-" with "or1k-elf-"
<apritzel>
ssvb: mmh, thanks for that info, but I thought that -EB would do the byte-swapping
<apritzel>
I read about the endianness swap on the bus ...
p1u3sch1 has joined #linux-sunxi
nove has quit [Quit: nove]
<lennyraposo>
tkaiser you kill me man
<ssvb>
apritzel: that's an interesting question, still avoiding byteswapping and pretending that we have a little endian openrisc processor does not work well, considering that we still have funny looking string constants
<lennyraposo>
some of your posts are so blunt and to the point
<lennyraposo>
"C'mon guys, in the upper right corner of your browser window is a search field. Try to do the obvious...."
<lennyraposo>
should use that as my signature
<lennyraposo>
had ot explain to someone how to use apt-cache search
<lennyraposo>
to check for nginx and php7
<ssvb>
apritzel: so byteswapping the firmware binary is the right thing to do and get it exactly in the same way how it looks on the openrisc side
<lennyraposo>
hey longsleep
<lennyraposo>
have you ever attempted loading the rootfs on usb sata drive?
<lennyraposo>
if not I will let you know how it goes
<ssvb>
apritzel: the main point is that FPGA and ASIC have become a lot more affordable nowadays, so the hobbyists now have a chance to challenge the proprietary IP vendors
<ssvb>
apritzel: and unless the ARM architecture license eventually becomes royalty free, it does not seem to have a bright future to me
<ssvb>
apritzel: but it still may take a decade or something like this :)
<apritzel>
I am not so much concerned about silicon, more about the software ecosystem
<apritzel>
looking back at _how much_ work it was to get arm (or arm64) to the current state
<apritzel>
where it is still missing things compared to x86
aballier has quit [Ping timeout: 260 seconds]
aballier has joined #linux-sunxi
<apritzel>
frankly: you need more than a toolchain and a kernel port to get a good architecture support
<ssvb>
what else do you need?
<apritzel>
support for runtime stuff like JITs or VMs
<ssvb>
well, this stuff is not strictly necessary
<apritzel>
optimization for all those packages that have assembly optimizations
<apritzel>
Linaro really spend a lot of time on this
<apritzel>
*spent* and is still spending
<lvrp16>
property right expiration for instruction sets?
reinforce has quit [Quit: Leaving.]
<ssvb>
apritzel: frankly speaking, Linaro is not particularly good at doing this work
<apritzel>
lvrp16: some early ARM stuff is already free, AFAIK
<apritzel>
ssvb: Linaro has many issues, but at least the porting stuff they did quite well
<apritzel>
ssvb: I know a lot of _really_ good guys working for Linaro
<ssvb>
apritzel: all that is really needed is the affordable hardware availability, which now has eventually happened for ARM64 after the introduction of PINE64, ODROID C2 and Raspberry Pi 3
<apritzel>
ssvb: agreed
<apritzel>
and having open firmware for that
<ssvb>
the ATF license encourages closed source implementations though
<ssvb>
let's see how long it will take to be hardcoded in the boot ROM
<lvrp16>
i mean all it takes is some lobbying for darpa funds...
<lvrp16>
isn't opensparc free?
<lvrp16>
and risc-v
<apritzel>
speaking of which, how do you like: $ ./boot0img -o pine64_atf_sram.img -u /src/u-boot.git/u-boot-dtb.bin -e -d trampoline64:0x44000 -s /src/arm-trusted-firmware.git/build/sun50iw1p1/debug/bl31.bin -a 0x44008
<apritzel>
this creates an image which you can write to 19096K of an SD card and combines upstream 64-bit U-Boot and a heavily stripped ATF running in SRAM A2
<ssvb>
is SRAM C still buggy and makes the use of SRAM A2 necessary?
<apritzel>
so far on this board: yes
<apritzel>
ssvb: I can use 0x2.0000 till 0x2.8000 just fine
<apritzel>
but a debug build is bigger than 32K, I get weird errors then
<apritzel>
also since boot0 load (what it thinks is the) scp.bin to 0x40000, this works just fine for me
<ssvb>
:)
<apritzel>
that --arisc-entry argument of my tool creates an OpenRISC jump to the entry point, which consists of 3 instructions to halt the arisc
<apritzel>
also I put the code for "ldr x9, =0x44000; br x9" to the part where boot0 assumes the ATF code
<apritzel>
this is the "--dram trampoline64:0x44000" part
<apritzel>
lennyraposo: longsleep: where is the best place to put a Pine64 Linux image these days?
<apritzel>
I guess something around 70 MB (compressed)
<lvrp16>
any1 know if the armbian orange pi plus image works for the plus 2?
<lvrp16>
apritzel, are you distributing it to customers?
<apritzel>
if you can live with "customers" being "everyone interested" ;-)
<apritzel>
it will be an image with upstream 64-bit U-Boot, (almost) upstream kernel and Ubuntu Core 14.04.4
ricardocrudo has quit [Remote host closed the connection]
<lennyraposo>
I have my own downloads section
<lvrp16>
apritzel: i have a image hosting server if you want to put it there, 50T bandwidth/month
<lvrp16>
i use like 100GB/month
<lvrp16>
if you will be using it for lots of images, i can set you up on it
<apritzel>
lvrp16: thanks, but ideally I hope to not add too much to that flood of images
<apritzel>
actually eventually it should work out of the box by just using some distro installer
<apritzel>
this "here is an image for you xyz ARM board" approach is getting really messy
<lvrp16>
thats something I want to tackle once i quit my formal job
<apritzel>
well, you don't need to quit for that ;-)
<lvrp16>
running a business and having a full time is too much, no spare time
<apritzel>
for arm64 it sounds doable
<lvrp16>
i gave notice yesterday, still have to give the 2 week courtesy
<apritzel>
no day jobs sounds great, but then there is this money thing ;-)
<ssvb>
apritzel: btw, could you try the addresses range from 0x1C000 to 0x28000 for the ATF?
<apritzel>
ssvb: doesn't that conflict with the FEL stack backups?
<apritzel>
or do they end at 0x1c000 already?
<lvrp16>
married to a rich wife, money's just a means now
<apritzel>
I wanted to keep that range free to make it FEL compatible
<ssvb>
we only need 16KiB for FEL
<ssvb>
at least this works on A13
<apritzel>
ssvb: oh, OK, but currently we use more?
<apritzel>
(I think I checked this and decided to start 32K into SRAM C)
<ssvb>
but if we try to enable the MMU for faster data transfers, then we probably need a little bit more than 16KiB because we can't get away with just section mapping
<ssvb>
so if 0x1D000 is good enough, then it would be probably the best choice for the ATF
<apritzel>
ssvb: right, either I missed a zero or I generously rounded up to 32K ;-)