<Net147>
MoeIcenowy: wens: at least with sunxi-3.4 on my A20 board you can use both HDMI and LCD at same time showing different content with different resolutions
MXfive has quit [Quit: Sleep Quit.]
tuxillo has joined #linux-sunxi
<tuxillo>
hi
<tuxillo>
apritzel: here?
<tuxillo>
apritzel: I have used one of your images to start the pine64 with u-boot
<tuxillo>
but 'usb start' reports no usb controllers present
<tuxillo>
my goal now is to be able to tftp a program which will be loaded by u-boot
<tuxillo>
a test program that will print hello world in the uart
<tuxillo>
:)
<apritzel>
tuxillo: if you don't need TFTP, you can have this much easier ...
<apritzel>
tuxillo: have you checked uart0_helloworld in sunxi-tools.git?
<apritzel>
tuxillo: can be loaded via FEL, SD card, eMMC, NOR flash
<tuxillo>
i mean, i want to have a Makefile that generates the uboot image and puts is on a dir, so on a reset it'll pick up the latest program I have compiled, not sure if I'm explaining myself
<tuxillo>
no, I haven't checked that
<apritzel>
tuxillo: you want quick turnaround, I guess?
<apritzel>
write some code, make, test, right?
<tuxillo>
yeah the fastest thing possible without any manual step
<tuxillo>
yeah
<apritzel>
if you don't need network, I'd suggest the following:
<apritzel>
checkout sunxi-tools.git
<apritzel>
build the stuff in there
<apritzel>
and use sunxi-fel to load your code into the SRAM via USB OTG, then start it
<tuxillo>
you mean the computer and the pine64 are connected via usb directly?
<apritzel>
yes, you need an USB-A -> USB-A cable, though
<apritzel>
because the Pine64 does not have a real USB OTG port (microB)
<apritzel>
then if you don't have any SD card, the boot ROM will enable USB OTG and your host should detect a new USB device
<tuxillo>
i don't have that cable, let me check if they have it in amazon
<apritzel>
I got mine on eBay for a few Pound/Euro/Dollar
gumblex has quit [Read error: Connection reset by peer]
iamfrankenstein has joined #linux-sunxi
lemonzest has joined #linux-sunxi
pg12 has quit [Ping timeout: 265 seconds]
pg12 has joined #linux-sunxi
apritzel has joined #linux-sunxi
reinforce has joined #linux-sunxi
scelestic has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
jernej has joined #linux-sunxi
mossroy has joined #linux-sunxi
mossroy has quit [Client Quit]
mossroy has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
<montjoie>
wens: I lost my a83t source tree, which branch is the best, our a83-emac ?
<wens>
no idea :|
<dgp>
Maybe not the right place to ask; Is there a git version of the armbian kernels instead of having to use the crazy build system? I just want a kernel to compare something
<mdsrv>
u r crazy
<dgp>
me?
<mdsrv>
u
<dgp>
Not sure why that matters but please feel free to explain why
<mdsrv>
im just wasting ur time
<mdsrv>
dont listen to me
<dgp>
Thanks buddy
<mdsrv>
np
<mdsrv>
i think u will just need to download sources manually
<mdsrv>
and patch it
<dgp>
I've given in and I'm going to build it in a vm like their instructions say.. but what a massive waste of time just to compare something
<mdsrv>
wait wait
<mdsrv>
u do something according to official site?
<mdsrv>
or according to armbian developers?
<mdsrv>
ah, ok, nvm, i see now that also armbian devs use docker
<dgp>
I'm doing it according to the docs in the build system which say to use a vm with a specific version of ubuntu
<mdsrv>
yeah, i know
<dgp>
instead of just putting the patched sources somewhere which would actually be useful
<mdsrv>
there is a function fetch_from_repo in one of the bash scripts
<mdsrv>
so i think it can be used to download unpatched soft
<mdsrv>
and then u just need to manually patch it, but still u have no confidence u make anything properly
<dgp>
yeah, I can see all the patches as files in the git checkout but who knows how they are applied etc
<dgp>
going to let it build and take the resulting source code and bin the rest
<mdsrv>
yep
* dgp
is trying to fix the wifi driver for the orange pi zero..
<mdsrv>
what for
<dgp>
Reason to fix it? So that everything that's worth having works with a close to mainline kernel
<scelestic>
odd, my orange pi plus 2 seem to be running at a really low speed when using https://github.com/megous/linux/commits/orange-pi-4.9, from dmesg i get "SMP: Total of 4 processors activated (192.00 BogoMIPS)." which seems a bit low
<scelestic>
is there something in the kernel config that could cause this or am i doing something else wrong?
<dgp>
IIRC bogomips is measured at boottime and your uboot probably clocks the cpu down to some safe value
<scelestic>
oh right
<dgp>
I don't think it actually matters
<scelestic>
to be honest everything did feel very slow but i'm not running of a sdcard instead of emmc
<scelestic>
not/now*
<dgp>
slow when doing what?
<scelestic>
apt-get mostly as i'm still setting things up
<dgp>
From my experience apt etc aren't very fast on any ARM machine
<scelestic>
i might have had less sources on the armbian install i had before i screwed that up, now i'm just going for mainline debian + kernel, most things seem fast but when looking up a orange pi dmesg you'll see bogomips 100 times higher than mine
<scelestic>
just found that odd :)
<dgp>
use top on on another ssh session or whatever and look what apt does.. it probably looks like it's chugging when it's decompressing etc.
<dgp>
Try a mainline kernel and debian anyhow. If you know how to use debootstrap you don't really need armbian
<scelestic>
yeah it was way easier than i thought it would be, i just didnt do much kernel compiling for a while so i've noticed lots of new stuff in the kernel config
<scelestic>
only need to setup uboot to autoboot my kernel so i can get rid of the serial console
orly_owl has joined #linux-sunxi
interrobangd has joined #linux-sunxi
leviathanch has joined #linux-sunxi
jernej has quit [Ping timeout: 250 seconds]
<diego71>
scelestic: apt-get is disk intensive, and sd usually are very slow
<KotCzarny>
dgp: building 'armbian kernel' is trivial
<scelestic>
diego71: yeah i think that must be it, i'm about to move the install to emmc so that should make it fast again
<KotCzarny>
just download mainline kernel source, then apply patches with bash one liner
<dgp>
KotCzarny: for the legacy kernel?
<KotCzarny>
unless its for h3, then use proper kernel source tree
<KotCzarny>
but patching is the same
<KotCzarny>
im doing it for my boards (both a20 and h3)
<dgp>
KotCzarny: I already have a working mainline kernel, what I need to do is compare what the wifi driver does on the 3.x kernel and work out the difference on mainline
<KotCzarny>
source for legacy tree should be somewhere in the build scripts
<scelestic>
dgp: what board? i just got wifi working on my orange pi plus 2
premoboss has joined #linux-sunxi
<dgp>
scelestic: orange pi zero
<scelestic>
ah right, different wifi module
<dgp>
There is a driver from allwinner for it that works with 3.x, someone has made the changes for it to compile on mainline.. but on mainline it crashes the firmware running on the wifi chip :)
<dgp>
So I want to dump the sdio transfers and compare them to find what is triggering it
<scelestic>
sounds complicated but also that you already know where to look at
<dgp>
I know the hard way to get the source code. Just wish it was in a git repo I could just checkout
<KotCzarny>
told you, check scripts for git link
<dgp>
KotCzarny: yeah I got that but can't see how all the patches apply
<KotCzarny>
uh, for each in proper/patches/dir/*; do patch -p1 <$each; done ?
<dgp>
Get errors for hunks that don't apply
<KotCzarny>
might be proper order/sort required
<dgp>
yeah, so just easier to build it, check it works and then take the source from the build :)
<KotCzarny>
also, that build script allows you to build only kernel
<KotCzarny>
withouth whole image
<KotCzarny>
so you might use it as well
<dgp>
yeah that's what I'm aiming to do. It wouldn't work on my debian machine so doing it in virtualbox on ubuntu now
<KotCzarny>
i think it was working fine on my debian jessie
<KotCzarny>
even compiling natively
<dgp>
On debian unstable. It stops because it wants gcc 5 and unstable is now 6
<KotCzarny>
using debian unstable isnt the best idea
<KotCzarny>
also, cant you pin the gcc5 ?
<dgp>
been doing it for more than a decade..
<dgp>
gcc5 is available still, the build scripts don't know how to use it
<KotCzarny>
i've stopped trying testing/unstable when packages got messed up
<dgp>
That's a risk but not having easy access to newer packages is annoying
<dgp>
and using backports is more painful than just using testing or unstable
smashr_ has joined #linux-sunxi
jernej has joined #linux-sunxi
bugzc has quit [Ping timeout: 260 seconds]
tkaiser has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
<tkaiser>
dgp: Did you succeed with whatever you tried to do?
<smashr_>
tkaiser! :) can you may recommend me a 4.9 kernel tree for my orange pi one?
<tkaiser>
dgp: Please keep in mind that you also need correct fex settings.
<dgp>
tkaiser: I need to turn on debugging in the driver and add code to it to capture the sdio transfers
<dgp>
I'm aware of the fex stuff
<dgp>
I have code in my checkout of the mainline port of the driver to do the same stuff as the fex sets up (power, irq etc)
gumblex has quit [Ping timeout: 245 seconds]
<tkaiser>
dgp: Good. I just checked git log and it's just a single commit (as .patch as usual). So all you need is the fex setings and this single file to get it going with any 3.4 sun8i kernel
<dgp>
ok, I'll probably just let the build complete anyhow so I have a known working state.
<tkaiser>
dgp: great, hope you can figure out what's going on with the mainline version then :)
<dgp>
spent about a week on it on and off so far.. the driver is a piece of crap but it just seems to be not liking something it gets sent right after the firmware is loaded
<dgp>
it boots up, sends a hello message to the driver and then crashes after the driver talks to it
<dgp>
power, gpio and interrupts I have worked out. I can see the interrupt for the hello message from the firmware and then the interrupt for the crash ;)
<xdeniz>
who can i ask for this topic montjoie? i have to install trustzone on this board (optee) and i need help
phipli has quit [Ping timeout: 260 seconds]
phipli has joined #linux-sunxi
<NiteHawk>
xdeniz: what about #imx6-dev? vpeter suggested that to you yesterday already
<xdeniz>
NiteHawk i think there is no body who can help :-/ i dont get an answer for my question on yesterday. maybe no one was on the pc on this time but i ask in the channel again for help and iam waiting now
<vpeter>
Yes, I forgot to mention that this channel is not very active.
<vpeter>
imx6 doesn't have much users.
<xdeniz>
is imx6 uptodate? did it makes sense to work on this as IoT-Gateway?
<tkaiser>
longsleep: Do you use ZFS on Pine64?
<vpeter>
xdeniz: I think chips will be available for some time. 2022 or 2024 I think. Which is one factor.
netlynx has quit [Quit: Ex-Chat]
<KotCzarny>
hmm, xdeniz, maybe you should consider some a20 based board?
<KotCzarny>
or even h3 one.
<KotCzarny>
they are extremely cheap and quite well supported by linux-sunxi community
<KotCzarny>
though it much depends on your use case
<xdeniz>
the Allwinner A80 seems to be nice too. but the imx6 is what I have here right now :) iam trying to port optee on this board what seems to be very hard.
<KotCzarny>
forget it
<KotCzarny>
you want SUPPORTED board
<KotCzarny>
specs are good for a paperweigth
* jelle
thought imx6 was supported in debian jessie
<xdeniz>
yeah i have compliled everything for this board and its ready to flash. but this is my problem. i dont now how to choose the files on the windows tool. the board has fixed files for flashing form the tool and i have a little bit more files. I hoped someone has this board at home :)
f0xx has joined #linux-sunxi
leviathanch has quit [Read error: No route to host]
leviathanch has joined #linux-sunxi
whaf has joined #linux-sunxi
premoboss has quit [Ping timeout: 268 seconds]
<KotCzarny>
xdeniz: can it boot from sd card?
<xdeniz>
KotCzarny yes, but not like the raspberry pi. i have at frist configure u-boot for this board.
<jelle>
freemangordon: can you paste a real link :p
<freemangordon>
I don;t really care the cores, you know, maemo ;)
<KotCzarny>
you wont be using video encoders/decoders, so it doesnt matter
<Wizzup>
freemangordon: ack, I know, please let me know if you find something
<freemangordon>
jelle: I was not sure the channel policy allows it
<Wizzup>
freemangordon: what I was searching for was something that could be ordered for the next year, by individuals, so it's easy for people to get the same thing/device
<jelle>
doesn't look like a q8 :)
<Wizzup>
freemangordon: as I mentioned before, it's also possible to get a dev kit (olimex) and add a screen, but that's not a 'real' tablet
<miasma>
hm so why does the wiki still talk about TF cards. the name was changed to (micro)SD in 2005
jinzo has quit [Ping timeout: 246 seconds]
<miasma>
it was known as TF between 2004 and 2005 and after that most stores have used the secure digital terminology
<Pepe>
tkaiser: What I know he received feedback only for 3/4 users on forum, but it wasnt good neither bad feedback. He put it there to branch for gbe test to receive more feedback, but I think it goes bad..
premoboss has joined #linux-sunxi
<Pepe>
but you responded there, so you should know it :-)
<tkaiser>
Pepe: I was only a short time active in this horrible forum again. To nail down then GbE issue. I get a headache each time I look into. Especially the retarded super moderator makes me sick.
<Pepe>
Yes, you was posting this 1-2 days ago and I am going to try that. On forum I was the guy who was complaining about Android 7 that it isnt smooth, but I tested it with Sandisk Android card and also with Samsung Pro card and it wasnt smooth still. So I bought Evo+ and gonna try that also again. I'm running right know 5.1.1 w/o any major/minor issues
<Pepe>
, but what bother me is that there isnt any 5 GHz usb wifi dongle supported neither in Linux.
leviathanch has quit [Remote host closed the connection]
speco1 has joined #linux-sunxi
<Pepe>
Thanks for it. I will try to do something with it (right now I can complain about it on pine irc)
speco1 has quit [Client Quit]
<tkaiser>
Pepe: Nothing will change as long as this individual is granted censor status :) When we started with the GbE issue in September he deleted almost 10 of my posts there and banned me and 3 others since we just emphasized that his opinion is wrong.
<tkaiser>
Pepe: It's a waste of time trying to contribute somewhere where everything one person does not understand gets censored. But this is off-topic here and just a problem of 'the average Pain64 user' :)
<Pepe>
agree with that name of Pain64 :/ I expected better support from them (because they raised almost 3M $ on Kickstarter) also they have 6 months to solve GbE issue and still nothing :/
<Pepe>
I sent PM to three guys and we can hope that they can do something with it.
<libv>
tkaiser: device specific sites/communities are a waste of time
<Pepe>
libv: how can you say that? Look at Odroid for example.
<libv>
fleeting, and full of idiots
<Pepe>
I can agree that it is on Pine forum, but I can't agree that it is also happening on Odroid forum.
<libv>
Pepe: so what about the early exynos based odroids then?
dr1337_ has quit [Quit: Connection closed for inactivity]
<Pepe>
Dont know about it anything, but now it's really good even I had U2/U3 and can't find there any issues about it
<libv>
yes, it's better than linux-exynos today, but that's only because not enough people realized the superior value and longevity of an SoC community
<libv>
i am currently looking at rockchip, and i feel like it's the summer of 2012 all over again
<freemangordon>
tkaiser: jelle: so, there are chances that if I buy a random tablet, it will boot mainline kernel ? I don't care that much about 3d accel at that stage.
<Pepe>
I was thinking about Xiaomi tablet with Tegra for that price it should be amazing, but I really doubt about random tablet, maybe tkaiser knows more.
<jelle>
freemangordon: there are always chances you might have to do something
<freemangordon>
jelle: sure, at least I'll have to preapre a bootable image
<tkaiser>
freemangordon: And if I were you I would chose one tablet MoeIcenowy is hacking around with. Since... supported soon ;)
<freemangordon>
tkaiser: I looked at that, the point is that I know nothing about allwiner SoCs, I am comming from n900 world, where you can't replace the bootloader :)
<tkaiser>
freemangordon: Allwinner devices are nearly unbrickable since boot priority and FEL mode :)
<jelle>
problem is that the chinese tablets put different components / touchscreens in their tablets
<freemangordon>
ah, so the chances are that I will have bootable device, but without gfx/ts. I see
<jelle>
well fb is set by u-boot, but touchscreen will need some tweaking (if there is a driver for it even)
<freemangordon>
ok, I'll wait for MoeIcenowy to appear to see if I can get some advice
<freemangordon>
jelle: what I am trying to do is - rebase Maemo 5 on top of devuan and put it on modern hardware. There is plenty of work to be done already, that is why I want to find something that will (almost) work OOB
<freemangordon>
hmm, seems like no, it is with mediatek
<tkaiser>
Pepe: The GbE test script finished (forgot to stop it ;) so I updated the results. But IMO it's obvious that this is not a real fix what Pine Inc delivered. At least on my (non defective) Pine64+ performance drops drastically.
<Pepe>
nice!
<Pepe>
I wrote your problem about that moderator to someone who is very close to TL Lim. As soon as i will have result I will tell it to you.
apritzel has joined #linux-sunxi
<tkaiser>
Pepe: It's not my problem it's one of the average Pine64 user. They get shitty software and shitty advises when they rely on official forum and wiki. That's the only problem. Fortunately the moronic 'the Mali' hype now has stopped.
<tkaiser>
Pepe: But Pine Inc people seem to be happy with it. And users too. So why bother? :)
<willmore>
tkaiser, how's that mali going?
* willmore
ducks
* willmore
runs headless, too.
<willmore>
Oh, I have one box attached to a TV.
BigFellow has joined #linux-sunxi
<tkaiser>
willmore: As far as I understood situation with Mali450 on H5 looks nice. IIRC ssvb said arm64 blobs for HiKey might be useable.
<tkaiser>
willmore: Also curious how video situation looks like. 'My' OPi PC 2 arrived yesterday at jemk's location so we will know soon :)
<miasma>
wouldn't it be possible to run two linux instances simultaneously on these boards, one with mali's blob driver and the legacy kernel and the other could be mainline
<miasma>
arm hyp stuff
<jernej>
tkaiser: What video situation? H5 has similar video capabilities to A64
<jernej>
HDMI driver seems similar too, which in turn is similar to H3
<tkaiser>
jernej: Yeah, but I tested it already more or less by accident and HW accelerated video decoding didn't work. But maybe it's just a minor tweak (add SoC ID or stuff like that).
<jernej>
ah, you mean decoding, not displaying :)
<tkaiser>
jernej: IIRC lvrpi said a few months back after a meeting with Allwinner the video engine would be better. Yeah, only talking about video engine stuff. HDMI should be the same :)
deskwizard has quit [Quit: Leaving]
<jernej>
tkaiser: HDMI is not exactly the same. It seems that there are few registers more to set. But fortunatelly others are the same.
<tkaiser>
jernej: Did you do something already with H5?
<jernej>
not yet
<jernej>
still playing with U-Boot HDMI
<jernej>
and btw, tx-delay and rx-delay should not be modified by u-boot on H5
<jernej>
there is no reference to those two settings in u-boot source
<tkaiser>
jernej: And a more generic approach? Take sys_config.fex settings where available and override DT prior to loading the kernel?
<tkaiser>
jernej: At least modifying those values in .dtb has no effect at all. And I just wonder why...
<jernej>
hm... are you sure that fex file is even used in u-boot?
<tkaiser>
jernej: longsleep reported that it has to be there (version string is enough) otherwise u-boot (A64 in this case) can not be compiled
<tkaiser>
jernej: And I noticed while watching sinovoip github repo for R40 that those guys change settings sometimes in DT and sometimes in fex.
deskwizard has joined #linux-sunxi
whaf has quit [Ping timeout: 256 seconds]
<jernej>
tkaiser: I found no evidence that fex files are used at all, only references to fdt_*
bugzc has joined #linux-sunxi
<jernej>
tkaiser: in board/sunxi/common/board_common.c there is one interesting function named update_fdt_para_for_kernel()
<jernej>
which overrides mmc/nand, memory size and dram parameters
<jernej>
but nothing else
<tkaiser>
jernej: Thanks. Then it remains a mystery for now why adjusting tx-delay and rx-delay doesn't work.
<tkaiser>
jernej: Or more probably something really simple: wrong DT nodes instead :)
matthias_bgg has quit [Ping timeout: 258 seconds]
<jernej>
tkaiser: which kernel config file is used?
<tkaiser>
jernej: To be honest, I only used pre-compiled kernel from Xunlong download site. When running build.sh after downloading BSP things horribly got wrong :)
<jernej>
if you see /proc/config.gz or friends, check that CONFIG_GETH_SCRIPT_SYS=y is inside