<Tusker>
I've got a H3 to test out anyway (Orange Pi 2)
p1u3sch1_ has quit [Ping timeout: 265 seconds]
p1u3sch1 has joined #linux-sunxi
arossdotme has quit [Read error: Connection reset by peer]
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
<lennyraposo>
clearing out old debian rootfses
<lennyraposo>
oops wrong window
IgorPec has joined #linux-sunxi
orly_owl has joined #linux-sunxi
<Tusker>
anyway, time to go home, will let you know how my testing goes
Tusker has quit [Quit: Time wasted on IRC: 5 hours 28 minutes 30 seconds]
JohnDoe_71Rus has joined #linux-sunxi
keesj has joined #linux-sunxi
Andy-D__ has joined #linux-sunxi
Andy-D_ has quit [Ping timeout: 250 seconds]
reinforce has joined #linux-sunxi
al1o has quit [Ping timeout: 240 seconds]
al1o has joined #linux-sunxi
n3rd_dude has joined #linux-sunxi
<n3rd_dude>
hi, I'm looking at working on an Allwinner A83T tablet (The Onda v989) within this month for a custom, mobile (linux) development platform. I know what I need to do, but would this be a good/not good time for me to work on the 83T?
<n3rd_dude>
my hope is to just get one of my projects working "on-the-go" and I'd be happy to help the community while I'm at it
<n3rd_dude>
hey KotCzarny, you mean the unsupported one? I think I do because I need working gpu drivers for the ui
<n3rd_dude>
yes I have :-)
<KotCzarny>
then you probably have to use legacy, unless you know/can help developing mainline drivers
<n3rd_dude>
right. yeah I'm hoping to help with that too
<n3rd_dude>
actually I have to decide the actual requirement for GPU drivers. I'm not familiar with the PowerVR support for linux
<KotCzarny>
uh
<KotCzarny>
it has powervr?
<n3rd_dude>
I've only worked with an A10 and the Mali400
<KotCzarny>
bad luck
<n3rd_dude>
the SGX544MP1?
<n3rd_dude>
what's up?
<KotCzarny>
pvr is notoriously linux unfriendly
<n3rd_dude>
haha
<n3rd_dude>
cool, okay. This is what I need. A *base* linux platform on the A83T with a "workable" native resolution that doesn't suck when I look at it
<n3rd_dude>
I use Awesome DWM everwhere so, no fancy graphics really
<n3rd_dude>
KotCzarny: planning to do my homework before I get into this because, like everyone, I have obviously better ways to spend my time and very limited budget on junk. Unless I'm helping you guys of course, linux-sunxi is cool although allwinner is s**t imo :-P
<KotCzarny>
those boards are usually very compatible when using same soc
<KotCzarny>
so you might read about banana pi m3 too
<n3rd_dude>
which boards? I'm sorry?
<n3rd_dude>
oh cool, I will
<n3rd_dude>
I assumed that actually
akaizen_ has joined #linux-sunxi
<KotCzarny>
and some devs here started to work on bpi-m3
<n3rd_dude>
I've also got the datasheets. I'm making a thorough read. I'm personally good at hitting dead-ends
<n3rd_dude>
right
<KotCzarny>
things that might be different are out of soc components, ie. display, pmic etc
akaizen has quit [Ping timeout: 240 seconds]
<n3rd_dude>
yeah
<n3rd_dude>
does allwinner have any standard debugging methods that might be carried on to a tablet with "easy access"? like say, the UART through the headphone jack trick?
<n3rd_dude>
or even a hack through USB?
<KotCzarny>
most likely it would have uart pads on the board
<n3rd_dude>
ahuh
<n3rd_dude>
that's painful
<n3rd_dude>
I don't wanna open a brand new tablet as soon as I buy it, but I'll keep that in mind :-P
<KotCzarny>
if you disassemble/find out dont forget to add to the wiki
<n3rd_dude>
yes, of course
<KotCzarny>
putting alternative os voids warranty too usually :P
<NiteHawk>
https://linux-sunxi.org/MicroSD_Breakout might be an option, too. But you'd have to check if the SDCx pins of your desired SoC are "multiplexed" with a UART function. And this approach needs customized u-boot/kernel/dtb
<n3rd_dude>
KotCzarny: of course it does. I'm planning a microSD card boot, but I'm not planning to return it anyway.
<n3rd_dude>
KotCzarny: I'd be happy if it works with android if the whole thing flops
<n3rd_dude>
NiteHawk: thanks, I'll check that
<n3rd_dude>
so how *is* PowerVR supported in the mainline kernel anyway?
<n3rd_dude>
something like vesa?
<KotCzarny>
null, nada, zero?
<n3rd_dude>
or rather, just fb0 or something
<n3rd_dude>
lol!
<n3rd_dude>
in other words, no display at all?
<KotCzarny>
but i might be wrong and something changed
<n3rd_dude>
:-P
<n3rd_dude>
okay, I'll guess you're with Mali450?
<KotCzarny>
im just a power user, and yeah, my sbcs have mali chip
<n3rd_dude>
wish I go with that now...was looking forward to some OpenCL at some point
<n3rd_dude>
oh okay
<n3rd_dude>
oh btw, are there any known issues with using the motherboard serial pin header RX,TX,GND with any UART? I tried that with my currently malfunctioning Marsboard A10 and I get garbled text. The same for a Cortex-M3 platform with an RTOS :-/
<n3rd_dude>
planning on getting the USB adapter now
<KotCzarny>
voltage levels?
<n3rd_dude>
3.3v I believe?
<KotCzarny>
yeah
<n3rd_dude>
yeah as in, "known issues"?
<KotCzarny>
i think someone recently had troubles with uart
<n3rd_dude>
okay. thanks dude.
<n3rd_dude>
*:-)
<KotCzarny>
dont remember what was the problem tho
<KotCzarny>
for me defaults work
<KotCzarny>
ie. i just connect cable
<KotCzarny>
and it works
<KotCzarny>
i use pl-2303hx based one
<n3rd_dude>
okay, I'll check that out
<n3rd_dude>
thank you
<n3rd_dude>
KotCzarny: this is basically very much like what I already use on X on Archlinux;
<Tusker>
wens: A83T boots well all the way to bash prompt over UART
<Tusker>
thanks for the help
premoboss has joined #linux-sunxi
TheLinuxBug has quit [Ping timeout: 264 seconds]
TheLinuxBug has joined #linux-sunxi
<n3rd_dude>
Tusker: hey dude, you're on 83T?
<n3rd_dude>
Tusker: because I'm thinking of working on a 83T-based tablet and doing some, appetite-whetting before I buy the thing
<Tusker>
n3rd_dude: yeah, have a A83T (Banana Pi M3) just booted on jessie, with 4.6.0 kernel and latest uboot
<Tusker>
no video yet, just UART
<n3rd_dude>
Tusker: is it tricky to get it working? you have to build the kernel for video I assume
<n3rd_dude>
with the framebuffer enabled
<Tusker>
well, you'll probably need to use the closed source 3.14 kernels that will come with the device
<n3rd_dude>
Tusker: you think so? why exactly?
<Tusker>
I'm trying to build from scratch, and don't need video for now anyway, so happy to play with it
<n3rd_dude>
yeah, that's the advantage of a base-board
<n3rd_dude>
I mean, SBC -.-
<n3rd_dude>
my mind has stopped responding...
<n3rd_dude>
Tusker: what OS are you on, if you you don't mind my asking?
<Tusker>
no problem, but as far as I know, the work hasn't been done to support HDMI output (though there is some experimental code on uboot to enable it)
<Tusker>
running with Debian Jessie / Linux
<Tusker>
Linux BPiM3 4.6.0-custom1-94847-g2f74096 #10 SMP Thu May 5 17:17:01 AEST 2016 armv7l GNU/Linux
<n3rd_dude>
Tusker: nice. I'm thinking of Archlinux. But it's not released on anything other than the A20
<n3rd_dude>
I'm going to need at least fb0 on the default LCD panel
<Tusker>
yeah, you'll have to work something out for that part
<KotCzarny>
n3rd_dude: for now just: 1/ use android kernel (or rebuild yourself), 2/ if you have working kernel/uboot setup you can use just any arm/armhf distro
<n3rd_dude>
still trying to figure out a method for UART with online documentation on anything and everything related
<n3rd_dude>
KotCzarny: #2 is what I was thinking of
<n3rd_dude>
#1 is a little gross
<n3rd_dude>
I'm a purist
<n3rd_dude>
:-P
<Tusker>
anyway, time for my dinner
<n3rd_dude>
so, no, not even a little
<Tusker>
cya guys
<n3rd_dude>
Tusker: right, thank you and bon appetit ;-)
<Tusker>
my pleasure :)
<Tusker>
ciao
Tusker has quit [Quit: Time wasted on IRC: 15 minutes 43 seconds]
<KotCzarny>
if you find/write working sgx driver for mainline you will be hero of many ;)
<n3rd_dude>
haha
<KotCzarny>
also, you can apply for a job at sgx
<KotCzarny>
because they are looking for such guy
<n3rd_dude>
well, I haven't really done much on the linux drivers but, let's see
<n3rd_dude>
but I like systemd and never had a reason to hate it. lol. I'm being educated today :-P
<NiteHawk>
n3rd_dude: i think there are good reasons to be a bit sceptical about systemd. whether that justifies going out of your way and actively avoid it, is probably a matter of opinion and/or personal preference. a look of "mainstream" distros use / come with systemd these days
<NiteHawk>
s/look/lot/
<KotCzarny>
nitehawk, mostly becuase debian/rh duo went head on into the drain
<n3rd_dude>
NiteHawk: yeah, I use arch and I was just gifted with it's beauty (<- open to personal interpretation)
<NiteHawk>
i'm using a number of headless ("server") gentoo systems, and have banned systemd from those - i see no reason why i'd need it *there*
<n3rd_dude>
haha
<n3rd_dude>
you use gentoo servers?
<n3rd_dude>
very bad ass
<n3rd_dude>
or maybe I read that wrong
<NiteHawk>
sure. it helps me in keeping full control
<n3rd_dude>
yeah that's what I keep thinking
<NiteHawk>
source-based distribution = you can twist every nut and bolt
<n3rd_dude>
but no, it's too much apparently. Arch in my case of course. Gentoo is too much for me :-P
<n3rd_dude>
NiteHawk: I like that though
<KotCzarny>
you can use devuan if you prefer pkg based ones
<KotCzarny>
and i bet arch also has systemd-free route
<n3rd_dude>
eh, I've been brain-washed now
<n3rd_dude>
actually now
<n3rd_dude>
*no
<n3rd_dude>
udev was "flushed" afaik
<NiteHawk>
that's what we're good at :D
<n3rd_dude>
and remember
<KotCzarny>
there is eudev
<n3rd_dude>
lol, "eudev"
<KotCzarny>
:)
<n3rd_dude>
NiteHawk: you mean, you're good at brain washing?
<NiteHawk>
yup.
* NiteHawk
is searching for the bucket and sponge...
<n3rd_dude>
I meant, I've been washed by Archlinux and it's simplicity to the point that I'd scoff at full blown OS compilations. But you're getting there where Sysd is concerned. I think.
<n3rd_dude>
I guess I'd still be interested in Gentoo, I just don't really have the time and didn't have the internet capacity :-P
<KotCzarny>
systemd was a nice concept initially, then went the evil way of doing everything and doing it BAD
<n3rd_dude>
NiteHawk: lol, if brain washing was as simple as a bucket and sponge...
<n3rd_dude>
NiteHawk: you run Gentoo on sunxi/
<n3rd_dude>
*?
<KotCzarny>
bucket full of psychoactive drugs and sponge
<n3rd_dude>
KotCzarny: lol, I agree about the former. Never noticed the latter.
<KotCzarny>
also, there is a way with gentoo that uses packages too
<NiteHawk>
yeah, but that's a bit pointless. if you're going with binary packages anyway, you might just as well use arch
<n3rd_dude>
I think I've heard about that, but I tried fiddling somewhere in '09. I was very young :-P
<n3rd_dude>
NiteHawk: exactyl
<n3rd_dude>
I don't mind compiling everything. I'd do it in a heartbeat for ARM.
<KotCzarny>
well, not exactly pointless if packages are sane and stable
<n3rd_dude>
on better hardwareof course
<KotCzarny>
opipc-one sells for ~10
pmattern has joined #linux-sunxi
<KotCzarny>
buy 4 and make a tiny compilation farm
<KotCzarny>
:P
<n3rd_dude>
lol
<n3rd_dude>
I was interested in an Odroid farm actually
<n3rd_dude>
U1 or something
<KotCzarny>
you get the point tho
<n3rd_dude>
yep
<KotCzarny>
you can also use octacore pc, crossgcc and distcc
<n3rd_dude>
hey how's gentoo supporting AMD Radeon's? My R7 doesn't really "work" in KMS and now my linux HDD died anyway, so I'm curious.
<n3rd_dude>
I *might* jump for the fun of it:-P
<n3rd_dude>
I am in the mood for odd drugs these days...
<NiteHawk>
i can't really tell as i'm using mostly X-less systems
<n3rd_dude>
right :-P
<NiteHawk>
i need sshd and little else ;)
<n3rd_dude>
the problem isn't X. It crashes after logind :-d
<n3rd_dude>
* :-D
<n3rd_dude>
agreed
<n3rd_dude>
I use screen
<n3rd_dude>
*GNU screen
<KotCzarny>
nitehawk: and a working network connection? :P
<n3rd_dude>
haha
<n3rd_dude>
w3m?
<NiteHawk>
KotCzarny: that fully optional 0:-)
hrw has joined #linux-sunxi
<hrw>
forgot to join
<n3rd_dude>
lol
<n3rd_dude>
NiteHawk: are there friends at Gentoo ARM? I noticed ArchARM was taken over by 7 dudes who insult for no apprent reason on IRC.
<n3rd_dude>
I might try it on my Marsboard A10
<Wizzup>
I use gentoo on arm on many machines
<Wizzup>
What do you need help with?
<NiteHawk>
n3rd_dude: you mean #gentoo-arm ? i haven't frequented that channel often, seemed decent. but i didn't like how they let the Gentoo ARM handbook fall into disuse/non-existance
<n3rd_dude>
Wizzup: oh nothing atm I was just curious since NiteHawk was speaking good of the OS (by "brainwashing"). I'm here doing some research on the 83T to get on a tablet.
<n3rd_dude>
I might do gentoo on that if I get crazy enough
<n3rd_dude>
thanks
<KotCzarny>
its not being crazy, just patient
<Wizzup>
I wouldn't typically suggest compiling on such a device if the only storage you have is sd cards
<n3rd_dude>
NiteHawk: yep, that's what I meant :-)
<NiteHawk>
if you want crazy, use NetBSD on arm :D
<KotCzarny>
n3rd_dude: grab samsung evo+ card, its really fast on small writes
<Wizzup>
or minix
<NiteHawk>
(which is quite possible, no offense meant ;))
<Wizzup>
KotCzarny: you said that before, I still don't buy it
<Wizzup>
(and I actually got that card)
<n3rd_dude>
haha
<n3rd_dude>
I meant crazy for me, guys
<KotCzarny>
wizzup: 4MB/s on random writes isnt bad, and he doesnt run server on it, just home projects
<n3rd_dude>
KotCzarny: is that the one above Class 10?
<KotCzarny>
classX doesnt apply
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<n3rd_dude>
just the brand eh?
<KotCzarny>
its about random read/write not sequential access
<n3rd_dude>
oh of course
<n3rd_dude>
I'll check availability
al1o has joined #linux-sunxi
al1o has quit [Client Quit]
al1o has joined #linux-sunxi
<KotCzarny>
also, sunxi boards are limited in sd access to ~20-30M/s for now so sequential speeds dont matter at all
al1o has quit [Client Quit]
<n3rd_dude>
what? really?
<n3rd_dude>
the controller is it?
<KotCzarny>
you can also look at samsung pro+ ones, but those arent speedier much
<n3rd_dude>
hm, I might try gentoo on a vm at some point
<n3rd_dude>
feeling adventurous
<n3rd_dude>
and "crazy", since the word sets you off :-P
<montjoie>
n3rd_dude: Wizzup compiling on NFS is fast enought
<montjoie>
but you need a NFS server with "classic" storage
<n3rd_dude>
montjoie: no overhead?
<n3rd_dude>
i/o waits like in sshfs?
<montjoie>
I didnt try to optimize it, but it is fast enought (relative to sdcard speed)
<KotCzarny>
nfs over ethernet is fast enough
<n3rd_dude>
cool
<n3rd_dude>
thanks
<n3rd_dude>
montjoie: ^ :-)
prasannatsm has joined #linux-sunxi
<montjoie>
n3rd_dude: I need to take time to iozone NFS
<wens>
oliv3r: fyi the changelog should be after "---" so it doesn't get included into the commit message when the patch is applied :)
<montjoie>
even on rpi I compile over NFs, but rpi is a bit more slow:)
<n3rd_dude>
montjoie: that'd be nice to see
<n3rd_dude>
thanks for pointing out iozone, I haven't come across that oddly
<oliv3r>
wens: crap; well it was the reason why i kinda ommitted it, i wasn't aware of the --- trick
<oliv3r>
wens: since it was supposed to be a simple single patch :)
<oliv3r>
wens: who will merge the patch?
<oliv3r>
wens: i see there's even a typo: 'Changeslog' .... my head is not on right :(
<oliv3r>
i hope mripard can fix the changelog when he applies the patch :) *wink*
<oliv3r>
wens: btw, i saw chris* repeated the 8 bit experiment and had the same findings, which is nice to have as a confirmation
<apritzel>
hrw
<apritzel>
hrw: I guess you missed this yesterday: the ATF version in my image is tailored to be loaded in SRAM, so it will not work easily with agraf's script and Fedora U-Boot
<apritzel>
montjoie: can you drop the UBSAN dmesg somewhere?
paulk-collins has joined #linux-sunxi
laga has joined #linux-sunxi
<hrw>
apritzel: ok
<apritzel>
hrw: the new ATF bits are still missing, my local git tree is a real mess (which I partly blame AW for ;-), I will fix this later and push it tonight
<hrw>
apritzel: thanks
<hrw>
apritzel: I am looking (at spare time) how to get pine64 some kind supported in fedora 24
<apritzel>
hrw: what kernel does that have?
<apritzel>
I was thinking about a backport of Pine64 support to 4.4
<hrw>
apritzel: 4.5.2 now
<apritzel>
hrw: will it stay on 4.5.x? or move on to 4.6 once this is released?
<hrw>
apritzel: may move to 4.6 but install media will stay at 4.5
<hrw>
once fedora releases there are no install media updates (strange for me)
prasannatsm has left #linux-sunxi ["Part"]
staplr has joined #linux-sunxi
<n3rd_dude>
NiteHawk, KotCzarny, montjoie, thank you for your advice. I have to go now. I might be back in a couple of hours :-) ttyl
n3rd_dude has quit [Quit: Page closed]
<apritzel>
hrw: is there an installer kernel&initrd for Fedora?
<hrw>
apritzel: there is install ISO but useless on non-uefi aarch64
<hrw>
apritzel: so far all our aarch64 targets were uefi powered servers
<apritzel>
hrw: my image should support EFI ;-)
<apritzel>
because of agraf's U-Boot EFI support
<apritzel>
can you give it a try?
<longsleep>
yeah agraf did EFI support - i have not tried it either tough
<hrw>
apritzel: we have it enabled in fedora uboot as well. I launched uefi grub with it
<apritzel>
if someone could try to launch a kernel and/or grub on the Pine64 via UEFI, I'd be grateful for reports
<apritzel>
hrw: actually my goal in pushing this firmware image is to avoid any kind of special treatment for the Pine64
<apritzel>
hrw: so I'd rather fix the firmware to work with EFI than adding magic bits to every distro
<hrw>
hm. grub-efi and loading 30MB initrd ends in halt...
<longsleep>
apritzel: i think agraf did that, he pushed some patches to my kernel tree which allow it to boot with UEFI
<hrw>
~curse board vendors for lack of 2MB nand chips
<apritzel>
hrw: but grub-efi alone works?
<hrw>
apritzel: yes
<hrw>
no issue
<apritzel>
is that a special Fedora grub?
<hrw>
normal fedora grub2 built for aarch64
<hrw>
same I use on apm mustang
<apritzel>
I am tempted to move some grub binary to my image
<apritzel>
hrw: does the mustang still use their own U-Boot these days?
<hrw>
apritzel: nope
<hrw>
apritzel: they were told many times to ship with uefi
<hrw>
apritzel: I saw u-boot on mine once - when tested unbricking procedure
<apritzel>
I remember when you had to wrap your kernel in an arm32 uImage to make it boot ;-)
<apritzel>
so did they ditch U-Boot at all or is it just hidden?
<hrw>
apritzel: no idea how it looks out of the box - never had such situation as my mustang came from Red Hat with uefi firmware
<hrw>
apritzel: will check your image once find spare microsd card
<apritzel>
hrw: thanks!
avph has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
Amit_T has quit [Ping timeout: 244 seconds]
* ssvb
has just booted Orange Pi PC from SPI
<plaes>
o_O
<plaes>
spi flash?
Amit_T has joined #linux-sunxi
<ssvb>
plaes: almost, I don't have SPI flash, but trying to emulate it with the help of another board
<plaes>
haha, that's what I actually thought :)
<hrw>
btw - is there a way to tell allwinner soc to check for spi flash instead of mmc?
<apritzel>
ssvb: who did the SPI load? the boot ROM?
<ssvb>
hrw: every Allwinner SoC tries to boot from SPI0, but the SPI boot may have different priority depending on the SoC type
<ssvb>
apritzel: yes, the boot ROM
<hrw>
ssvb: thx
* apritzel
thinks to have some old 4Mbit SPI flash chips still lying around somewhere
<ssvb>
actually I tried to boot the PINE64 board first and I can see SPI0 chip select getting asserted there, but it still does not work correctly for some reason
<ssvb>
then I tried to test the Orange Pi PC and the SPI boot works nicely there
<apritzel>
mmh, sound like nice to solder one of those cheap SPI flash chips on a tiny board with a connector that fits directly on the headers
<apritzel>
and having U-Boot plus DTs on there
<apritzel>
actually board vendors should integrate this on the board - cheap on board storage for firmware
<hrw>
apritzel: but that's whole 10¢ per board!!1!! ultra expensive! no one will buy!
<apritzel>
hrw: actually the EFI specs demands a board to have some non-removable on-board storage to be compliant ;-)
<hrw>
apritzel: it is not the first specification which got ignored by vendors
<wens>
for some reason no one sells SPI flash over here...
<wens>
I had a friend pick some out of their trash (at a PC motherboard vendor) for me
<apritzel>
ssvb: does the boot ROM simply load the first 32KB from SPI into SRAM A1 and executes it?
<ssvb>
apritzel: yes
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<ssvb>
though it loads 256 bytes at the address 0 first, then restarts from the address 0 again and reads data as 2048 byte blocks
<NiteHawk>
ssvb: as a preparatory step towards A64 support i'd like to get https://github.com/linux-sunxi/sunxi-tools/pull/41 in. i got 0 feedback on the ML submission, could a have a "go" / "no go" from you?
laga has quit [Remote host closed the connection]
<longsleep>
sunxi framebuffer acts strange when the physical resolution gets changed, anyone here has looked in details of dev_fb.c in the disp2 driver?
<ssvb>
NiteHawk: yes, the ML has proven to be pretty much useless, I guess there is no reason to use it anymore
<NiteHawk>
i wouldn't call it useless, but at least the peer review process doesn't seem to work
<NiteHawk>
ssvb: wrt to your github comment - you suggest not to bother with multiple readl/writel (i.e. just stick with the original base implementation of single uint32_t)?
<ssvb>
NiteHawk: I don't really care :) It does not seem to be particularly useful (still I may be proven wrong), but this is not a good reason to reject these patches either
<NiteHawk>
i guess for now you don't have any particular use cases yet (e.g. transferring some "larger" chunks to the openrisc core or something like that)? as of now, pretty much the only we'd be doing with that is the SID retrieval. so i agree it shouldn't matter much
<NiteHawk>
it just seems to require very little extra effort to support those multiple transfers, that's why i added them
<ssvb>
NiteHawk: in fact I do, I just need to clean up and post the OpenRISC patch set
<ssvb>
NiteHawk: but it does not conflict with your patches
<NiteHawk>
yes, i kept wrappers for the original functions on purpose
<NiteHawk>
(as they're also used for the "readl" / "writel" command line options)
<NiteHawk>
btw: gz on the SPI NOR work - i'm also interested in that
<ssvb>
apritzel: yes, there was a private discussion on google+ started by hrw about the boot ROM implementation on Allwinner SoCs, where he was not very happy about it ;-)
<Amit_T>
Is it true that on ARM, the cache ops have to be aligned to cacheline length ?
<ssvb>
NiteHawk: I'll post the SPI demo code a bit later
Shirasaka-Hazumi has quit [Ping timeout: 260 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
<KotCzarny>
longsleep, is it related to a10disp in any way?
<apritzel>
hrw: g+ profile returns -ENODEV here ;-)
pmattern has quit [Quit: Genug für heute.]
arossdotme has joined #linux-sunxi
<longsleep>
KotCzarny: i looked at that a while ago - so it it similar - but i have something more in mind (if it works properly) to have it integrated with the boot process to set resolution based on kernel cmdline args
<longsleep>
KotCzarny: and i wanted to investigate how to do ioctl from Go
<longsleep>
KotCzarny: so i figured i make something useful
<KotCzarny>
uhum
<KotCzarny>
if you can integrate a10/20 support into it it would be nice
<longsleep>
should be all the same
<longsleep>
its the same syscall after all, args also the same - but the A64 Kernel lacks all syscalls to do anything with the framebuffer ..
tsuggs has quit [Ping timeout: 276 seconds]
reev has quit [Ping timeout: 244 seconds]
<hrw>
apritzel: k
<hrw>
apritzel: all started from:
<hrw>
Is Allwinner group of morons? First stage bootloader is stored at 8KB from start of SD card. GPT partitioning takes first 17KB...
<hrw>
When SoC vendors will finally get to the point where distribution live will be easier...
<hrw>
1
<hrw>
apritzel: then 59 comments followed
<longsleep>
funny
<hrw>
longsleep: the part of problem may be the fact, that I usually look from distribution perspective
<longsleep>
hrw: they only look from Android sales perspective
<hrw>
longsleep: fully aware
<longsleep>
hrw: did you find a solution to have a GPT partition table and the bootloader?
<hrw>
longsleep: it is tricky on allwinner systems
<hrw>
longsleep: you can generate GPT which will fit in <8KB but no warranty that any of GPT manipulation tools will not erase whole 17KB
<longsleep>
yeah just saw in the spec "he EFI stipulates a minimum of 16,384 bytes be reserved for the partition table arra"
<hrw>
longsleep: exactly
<longsleep>
mhm so if there is no alternate boot0 location other than 8k i do not see how this is going to work
<longsleep>
maybe they have another location where they look when nothing valid is found
<KotCzarny>
or just hang
<hrw>
yep
matthias_bgg has quit [Read error: Connection reset by peer]
matthias_bgg has joined #linux-sunxi
al1o has joined #linux-sunxi
<apritzel>
hrw: maybe a hack, but can you disguise some boot code as a bogus partition table entry?
nove has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
simosx has joined #linux-sunxi
IgorPec has joined #linux-sunxi
<apritzel>
hrw: so the boot ROM loads 32KB from sector 16+, which contain an ARM jump instruction as the first word and some small piece of code that loads the rest of boot0 from a more appropriate location
premoboss has quit [Quit: Sto andando via]
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<hrw>
apritzel: and then you run gpt-partition-mangling-tool and it happily clears first 17KB before writing new table occupying just first 2KB
Amit_t_ has joined #linux-sunxi
<hrw>
and from tool author's view it will be perfectly fine cause this is gpt space
<Amit_t_>
apritzel: Hello, Just wanted to check that is it required to have DMA desc aligned to cache line size for cache ops to perform ?
reinforce has quit [Quit: Leaving.]
IgorPec has quit [Ping timeout: 260 seconds]
<apritzel>
Amit_t: not if you do cache maintenance by VA
<lvrp16>
hrw: can't you use the protective mbr space to jump?
<Amit_t_>
apritzel: I am trying do it through PA
<apritzel>
Amit_t: but you have the MMU on, right?
<hrw>
lvrp16: if you use mbr then you just create first partition at 4MB and boot loaders are safe.
<apritzel>
Amit_t: in this case U-Boot has an identity mapping, so VA=PA
<apritzel>
Amit_t: "by VA" only means as opposed to "by set/way", which is most probably not what you want
<lvrp16>
"GPT fdisk operates mainly on the GPT headers and partition tables; however, it can and will generate a fresh protective MBR, when required. (Any boot loader code in the protective MBR will not be disturbed.)"
jernej has joined #linux-sunxi
<lvrp16>
idk about parted
<lvrp16>
at my company, i have both efi and mbr booting enabled with this very mechanism
<apritzel>
lvrp16: but as hrw correctly stated, GPT tools are free to nuke the first 16 (or 17) KByte
<Amit_t_>
apritzel: oh , but how do I know mmu is on , I am not using SYS_DCACHE_OFF, SYS_ICACHE_OFF now
<jernej>
longsleep: It should fix your issues with resolution switching
<apritzel>
Amit_t: then the MMU should be on (on sunxi, at least)
<Amit_t_>
Also if I don't DMA desc struture to cache line size I do see ERROR: v7_dcache_inval_range - stop address is not aligned - 0x7bf47650 messages
<Amit_t_>
*I don't align
<lvrp16>
apritzel: ahh sorry i skipped this message: "First stage bootloader is stored at 8KB from start of SD card."
<apritzel>
lvrp16: I think it can be done by just limiting the number of GPT entries to end at 8KB and having a protective partition around the boot0 code (from 8K-40K), but still it would violate the spec
<apritzel>
in my image (using MBR only) I also used a "bogus" partition of type 0xDA to protect U-Boot
<apritzel>
and hope that nobody touches the first MB ;-)
jernej has quit [Quit: Page closed]
<Amit_t_>
apritzel: I should not invalidate all the cache, I should only invalidate only a range, right ?
<lvrp16>
8K that leaves like 56 partitions? has anybody tested parted and gdisk to see what they overwrite?
<lvrp16>
ignoring spec and all
* hrw
back from call
<lvrp16>
for each partition entry, you get 16b, enough to jump?
<lvrp16>
you can create a partition thats just jump code
<lvrp16>
so that GPT doesn't wipe it
* lvrp16
has no idea what he is talking about
<lvrp16>
so technically in spec, except not
* lvrp16
is just throwing stuff out there
<lvrp16>
sorry 32b of space
<lvrp16>
not 16, the uuid can be used too
<apritzel>
lvrp16: yeah, hiding some jump code in a partition entry was my idea
<hrw>
lvrp16: spec says: GPT takes 16KB after MBR. tools can wipe it freely then.
* hrw
-> another meeting
<apritzel>
hrw: the question was whether existing tools actually do that
<lvrp16>
apritzel: no, it was my idea, all mine mine mine
<lvrp16>
;)
<apritzel>
;-)
<apritzel>
lvrp16: but it turns out that you don't need that, as you can just end the GPT earlier
<apritzel>
hrw: the point is: we are pretty clear that the game is lost if we stick 100% to the spec
<lvrp16>
did you say that was out of spec :B?
<apritzel>
hrw: but maybe it works anyway ;-)
<lvrp16>
i don't see how the partition entry is out of spec though, it is creative repurposing
<lvrp16>
as long as it is still a valid partition entry
<lvrp16>
you do have to spam your partition count but does that even matter?
<apritzel>
lvrp16: sure having a partition entry with some code maybe within the spec, but still any repartitioning tools can legally wipe the whole area and thus your boot code
prasannatsm has joined #linux-sunxi
al1o has joined #linux-sunxi
akaizen_ has quit [Read error: Connection reset by peer]
orly_owl has quit [Ping timeout: 260 seconds]
akaizen has joined #linux-sunxi
<longsleep>
the fbdev-fixes patch is hilarious - or rather the original code is
hrw has quit [Read error: Connection reset by peer]
hrw has joined #linux-sunxi
prasannatsm has left #linux-sunxi ["Part"]
<montjoie>
on pine64 which MMC driver is necessary ? I enable only ALLWINNER one but no mmc at all
<apritzel>
montjoie: which kernel? which tree?
<montjoie>
your a64-wip
<montjoie>
no mmc log at all
<apritzel>
montjoie: do you use the DT from that tree as well? (or the ones from the image, they should be the same)
<apritzel>
the *new* image, of course
jernej has joined #linux-sunxi
<KotCzarny>
gpt needs new spec then, with info in the mbr how big it can be ;)
<KotCzarny>
also, 16kB for a partition table? wtf
<KotCzarny>
even plaintext is smaller
zuikis has joined #linux-sunxi
<wens>
unlimited entries! :p
<KotCzarny>
but seriously, for those boards reinstalling os usually means dd :P
<lvrp16>
libre-gpt?
<apritzel>
KotCzarny: gpt has an entry (after the (optional) MBR) stating it's size, which can be smaller than 8KB
<longsleep>
looking into the other patches of that folder from jernej
<lennyraposo>
noticed a lot of additions
<lennyraposo>
especially your sane alsa rule set ;)
<jernej>
longsleep: basically we share patches with Armbian
<lennyraposo>
which was close to what I came up with
<tkaiser>
longsleep: That's nice. And should work with H3 too when jernej's OpenELEC patches are applied :)
<lennyraposo>
except had it using softvols for various items
cosm_ has joined #linux-sunxi
<longsleep>
i am looking into the HDMI-enable-edid patch now, what does it actually do?
IgorPec has joined #linux-sunxi
<NiteHawk>
for those using A64: the sunxi-tool now has experimental support for it in the https://github.com/linux-sunxi/sunxi-tools/tree/A64-support branch - any feedback is appreciated. i'm particular keen to know if the new "sunxi-fel -v sid" command works, and returns something meaningful for this SoC
<jernej>
longsleep: Not sure about that one, it was ported from loboris kernel source.
<longsleep>
jernej: well, the patch could be applied to the A64 tree, files are pretty much the same
<longsleep>
jernej: if it does something there it should do the same here
<lennyraposo>
looking now NightHawk
<jernej>
longsleep: I'm aware of that. Basically only difference is device tree support
abruanese has quit [Remote host closed the connection]
<longsleep>
btw, all the work from today is done in a beergarden and paid for by everyone who sent me beer money on the Pine64 forum :P
<lennyraposo>
nice
<jernej>
cheers :)
<lennyraposo>
das is vunderbar
<longsleep>
close one :)
<lennyraposo>
married to a swiss girl
<lennyraposo>
lol
reinforce has joined #linux-sunxi
<lennyraposo>
sorry wunderbar
<KotCzarny>
wunderbra
<longsleep>
yes - you wife told you ;)
<lennyraposo>
actually
<lennyraposo>
she isn't around
<lennyraposo>
and it's her brother and father that speak it fluently
<lennyraposo>
she was raised her ein Canada
<lennyraposo>
lol
<KotCzarny>
ein canada bitte schnell!
<lennyraposo>
but if you need french or portuguese or spanish
<lennyraposo>
I am all ears
<lennyraposo>
;)
<longsleep>
NiteHawk: not sure what is supposed to happen but : root@pine64-2gb:~/sunxi-tools# ./sunxi-fel -v sid
<longsleep>
ERROR: Allwinner USB FEL device not found!
vagrantc has joined #linux-sunxi
<NiteHawk>
longsleep: well, your A64 has to bei in FEL mode for that - sorry if that wasn't obvious
<longsleep>
NiteHawk: i have avoided to learn about FEL mode so far :)
<NiteHawk>
and connected to the host via USB cable
<longsleep>
NiteHawk: this reminds me, didnt find my OTG adapter the other day :/
<NiteHawk>
longsleep: no problem. in that case you got an expected result :)
<lennyraposo>
isn't USB port 1 used for FEL on the pine?
<NiteHawk>
yes, the upper one i think - so unfortunately it needs a special (non-standard) A-A cable
<lennyraposo>
I got that ;)
<NiteHawk>
it's documented in our wiki
<longsleep>
yeah, thats why i searched for the adapter
<lennyraposo>
for all those MXQ s805 boxes
massi_ has quit [Remote host closed the connection]
<lennyraposo>
lol
<longsleep>
jernej: i applied the EDID patch as well, does not seem to do any harm so maybe it helps someone :)
<lennyraposo>
what else are you looking into
<jernej>
That is my guess also :)
<lennyraposo>
as I stil have trouble navigating what's where
<apritzel>
NiteHawk: thx for pushing the sunxi-tools A64 support, will give it a try later
<lennyraposo>
I look at sunxi and cross check with yours longsleep
<NiteHawk>
apritzel: great. might still need a bit of testing before we merge it into master. btw: i've been looking at your boot0img, it looks reasonably clean/sane, but i think i have some comments/suggestions. hope i will get to that later...
<apritzel>
NiteHawk: sure, thanks for having a look! Any comments welcome! I am used to kernel ML reviews, so just hit me ;-)
<NiteHawk>
lol :D
* NiteHawk
goes looking for the cluebat
<lennyraposo>
the 64bit uboot one?
<lennyraposo>
longlseep: any noticeable differnce using the fbturbo you have going for your xenial image?
<lennyraposo>
my debian images have done without
<longsleep>
lennyraposo: it is usable - i have no clue how it is without
<lennyraposo>
never installed on my images
<lennyraposo>
;)
<longsleep>
well - thats bad :)
<lennyraposo>
the one thing I neer got to experiment with
<lennyraposo>
was watching youtube vids in mate 480p ;)
<lennyraposo>
seemed ok
akaizen has quit [Remote host closed the connection]
<lennyraposo>
been taking my time with the next debian release
<lennyraposo>
dropped lxde for good
tkaiser has quit [Ping timeout: 276 seconds]
<lennyraposo>
and thinking of dropping GUI and just having the user run tasksel if they want it
<lennyraposo>
brb cigarette and coffee break
akaizen has joined #linux-sunxi
Netlynx has quit [Ping timeout: 260 seconds]
al1o has joined #linux-sunxi
IgorPec has quit [Ping timeout: 246 seconds]
IgorPec has joined #linux-sunxi
Netlynx has joined #linux-sunxi
<lennyraposo>
noticed 25 fps and 30fps addition for 4k resolution
<lennyraposo>
see if I can test it at the neighbours place
<lennyraposo>
as they got a 4k tv
IgorPec has quit [Ping timeout: 260 seconds]
ricardocrudo has joined #linux-sunxi
<longsleep>
lennyraposo: 4k will not work as the CMA reserved memory is too low
<longsleep>
what do you mean you noticed 4k resolution?
<lennyraposo>
the entry for 4k in hdmi_core.c
<longsleep>
was there before - did do nothing to it
<lennyraposo>
thought was an addition as per history
<longsleep>
i added some edid line to that file
<lennyraposo>
nm
<lennyraposo>
noticed it was just the edid funcitonality
<lennyraposo>
and +#define HDMI_EDID 511
<lennyraposo>
sorry still getting use to it
<lennyraposo>
;)
<lennyraposo>
changes to wlan
<lennyraposo>
got rid of the power saving
<lennyraposo>
which I agree was annoying
ganbold has quit [Ping timeout: 252 seconds]
reinforce has quit [Remote host closed the connection]
reinforce has joined #linux-sunxi
jernej_ has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
Netlynx has quit [Quit: Leaving]
jernej has quit [Ping timeout: 244 seconds]
jstein_ has quit [Remote host closed the connection]
jernej_ is now known as jernej
pulser has quit [Remote host closed the connection]
pulser has joined #linux-sunxi
Nyuutwo has quit [Ping timeout: 240 seconds]
<montjoie>
openssl compiled in 25minutes over NFS, 20 on tmpfs, not so bad for NFS:)
<KotCzarny>
oh, fun, ~500kB/s of AES-256-CBC eats ~40% of 720mhz of the a20's core1
pulser has quit [Remote host closed the connection]
pulser has joined #linux-sunxi
jernej_ has joined #linux-sunxi
jernej has quit [Ping timeout: 240 seconds]
Nyuutwo has joined #linux-sunxi
jernej_ is now known as jernej
zuikis has left #linux-sunxi [#linux-sunxi]
mnr has joined #linux-sunxi
reinforce has quit [Remote host closed the connection]
<lennyraposo>
hey
leio has joined #linux-sunxi
<lennyraposo>
just a general question
<lennyraposo>
about the group at sunxi-linux
<lennyraposo>
do you guys ever get funding for your work?
<lennyraposo>
like donations equipment
<lennyraposo>
resources in general?
<lvrp16>
KotCzarny, that slow?
<mnr>
lennyraposo: There is no financial funding that I know of. Sometimes hardware producers provide sample boards to developers.
* lvrp16
will provide sample boards to anyone who wants to work on stuff
<lvrp16>
how much funding do you guys need? i can gather some
<lennyraposo>
I am very good at marketing and funding drives
<lennyraposo>
;)
<lennyraposo>
it would be beneficial to the cause
<lennyraposo>
seeing as most of these sbc makers are at times too cheap to do the real work
<lvrp16>
they're not too cheap to do real work, they just have no idea how
<lennyraposo>
they should be funding outlets such as sunxi
<lennyraposo>
linux
<nove>
there isn't any "sunxi-linux", the name is "linux-sunxi" if what was been referred
IgorPec has joined #linux-sunxi
<jelle>
lennyraposo: I did most of my things as a hobby and mostly to get into Linux / U-boot development
<jelle>
and since I have a job, buying a $15 ARM device didn't hurt that much :-)
<nove>
two years ago, there was talk about linux-sunxi.org making the necessary legal steps to be able to take donations
<nove>
but then the "license issues" happened
<lennyraposo>
hmm
<lennyraposo>
I can have my lawyer look at things
<lennyraposo>
any history abotu it posted somewhere?
cosm has quit [Quit: Leaving]
cosm_ has quit [Quit: Leaving]
<simosx>
allwinner delivered boards to developers. A80 and A83 boards.
<lvrp16>
licensing issues with the code base
<lvrp16>
?
<nove>
maybe libv, Turl or mnemoc have a word to say ^^^^^
<lvrp16>
yes, but i don't see how that would preclude from 503c
<jelly>
lennyraposo: these boards are cheap. You want to fund, pay devs who do it in their free time good hours, so they can focus on sunxi instead of their day jobs?
pulser has quit [Remote host closed the connection]
<nove>
lvrp16: the unwillingnesses of the soc vendor to resolve the "license issues" in the software that they are using, creates uncertainty about the future, making some people reluctant about continuing to spend time
<Turl>
nove: about what?
<rellla>
the interesting thing on that wiki page is the revision history btw
reinforce has joined #linux-sunxi
pulser has joined #linux-sunxi
<nove>
Turl: about making linux-sunxi.org an entity capable of accept donation
<Turl>
nove: formally? dunno :)
akaizen has quit [Remote host closed the connection]
* Turl
not a fan of bureaucracy
<lvrp16>
doling out funds is a huge pita
<Turl>
informally, you could talk with some of us if you want to help foot eg. server/domain bills or somesuch
apritzel has joined #linux-sunxi
<lennyraposo>
jelly: not looking for people to to leave their jobs or anything just wondered if you guys ever get funded and need reswources is all ;)
<mripard>
mnr: NextThing Co has been funding a lot of development for a while now.
<lennyraposo>
that's nice to hear
<simosx>
The team behind Micropython ran a campaign on Kickstarter in order to get funds to write better support for the ESP8266.
reinforce has quit [Remote host closed the connection]
<simosx>
They got x2 times the funds requested, about £25K. Not a dime from Espressif.
<lvrp16>
simosx: how far did that get the project?
<apritzel>
montjoie: Salut, what .config did you use for the Pine64 kernel? defconfig?
<simosx>
lvrp16, their goal was for £6Κ but got £28,534. They had to add video tutorials to their stretch goals because anything else they could think they could do was already covered.
<agraf>
hrw: that looks like it's in Linux
<agraf>
hrw: ah, I never implemented the command line arguments for efi
<agraf>
hrw: but grub2 converts them to dt properties, so you should be good, hmm
<agraf>
hrw: also you definitely do *not* want to use grub's "devicetree" command
<jelle>
simosx: to be fair everyone can make that esp8266 chip ;-)
<agraf>
hrw: as you need cooperation from firmware (u-boot) to actually patch the device tree
<agraf>
hrw: so you need to run bootefi with the device tree as argument
<agraf>
hrw: bootefi <grub addr> <fdt addr>
<simosx>
jelle, anyone can make H3 boards as well. ;-)
<jelle>
simosx: hehe yeah..
<jelle>
it's awesome micropython is funded though!
akaizen has joined #linux-sunxi
jelly is now known as MooServ`
<simosx>
the micropython campaign plan was to deliver the new "ESP8266 Micropython" to the backers only, for the first six months. Then, make public. But since they got so much funds, they put a stretch goal to make it available on day 1 (first version is available).
MooServ` is now known as jelly
vagrantc has quit [Quit: leaving]
<simosx>
there were mistakes with dealing with Allwinner. I do not see any change in that. So, a crowdfunding campaign would be an easier option.
<hrw>
agraf: thanks about DT - boots without it ;D
<agraf>
hrw: great :)
<agraf>
hrw: you can also "bootefi" the kernel itself btw
<hrw>
agraf: I use initrd.
<agraf>
hrw: then it's harder
<hrw>
yep
<agraf>
hrw: you basically need to load the initrd manually and use "fdt addr" and "fdt chosen"
<hrw>
agraf: one kernel rule them all
<agraf>
hrw: sure, i always boot with initrd too ;)
simosx has quit [Quit: Yakkety Bye!]
<apritzel>
agraf: is there some documentation about the EFI support in U-Boot
<apritzel>
?
<agraf>
apritzel: what documentation would you want?
<apritzel>
that doc/README.efi is about the other way round, right?
<agraf>
yeah
<agraf>
well
<agraf>
i added some efi_loader bits too iirc
<agraf>
or did i create a new file?
<apritzel>
so you have bootefi which load an EFI application and that's it?
<agraf>
apritzel: ah, i added a new sction to README.efi
<agraf>
apritzel: pretty much, everything else should be reasonably seamless
<hrw>
apritzel: and then load grub and do how you do on sbsa/sbbr machines
<apritzel>
ah, TL;DR
<agraf>
apritzel: there are a few tweaks here and there - the "load" command for example remembers the last location a binary got loaded from
<agraf>
apritzel: and passes that to the booted efi binary
<agraf>
apritzel: grub2 uses that path to find its config by default
mozzwald has joined #linux-sunxi
<agraf>
apritzel: but in general it's really just "load device tree", "load efi binary", "run efi binary"
<agraf>
apritzel: the distro script does it all for you though
<agraf>
apritzel: so if you use the distro headers (which sunxi systems do use), you can just throw any normal efi compliant image at it and it should at least say hello
* apritzel
tries just that atm
<apritzel>
mmh, DT. wasn't there some patch where bootefi would take the U-Boot internal tree if there is nothing else?
<apritzel>
Amit_T: if you are still awake: any chance you could put your H3 EMAC U-Boot driver somewhere?
<agraf>
apritzel: yup, it does
<apritzel>
ah, but you need to set it first with "fdt addr"
<agraf>
apritzel: depends on the code version you have
<agraf>
apritzel: current get receives it as parameter
<apritzel>
I always wonder why U-Boot has the full DT embedded when this is not exposed
<agraf>
apritzel: until rc2 or rc3 you had to load it with "fdt addr"
<apritzel>
agraf: I have latest HEAD
<hrw>
bye
<agraf>
apritzel: then it's an argument to bootefi
<mripard>
apritzel: because they have some bindings that linux doesn't agree on, and they don't care about ABI stability either
<apritzel>
agraf: indeed that works
<apritzel>
mripard: does sunxi U-Boot actually use _anything_ from the DT?
<apritzel>
I found that most stuff is hardcoded in the source anyway
akaWolf has quit [Ping timeout: 240 seconds]
* apritzel
counts down till devicetree.org goes fully public and sets that straight ;-)
jinzo has joined #linux-sunxi
akaWolf has joined #linux-sunxi
<lvrp16>
nice
<lvrp16>
are dts ever gonna get moved out?
<lvrp16>
they seem completely tangential to kernels
<mripard>
apritzel: yes, they do have a device model now and probes driver out of the DT
<mripard>
it's still in limbo though
<mripard>
so they don't make full use of it yet, depending on the frameworks and boards
<apritzel>
mripard: good to know
<apritzel>
lvrp16: unfortunately this is still under discussion, but I am very much in favour of it ...
<apritzel>
some vendors (especially on arm64) just don't bother to update their DTs, instead provide proper versions with the board/server
<apritzel>
which sounds dodgy, but is on the other hand a first step to get rid of the kernel integration
<lennyraposo>
not until september
<lennyraposo>
for devicetree.org
<lennyraposo>
I mena
<lennyraposo>
mean*
hrw has quit [Quit: Lost terminal]
<apritzel>
lennyraposo: well, phase 1 should start anytime soon
<apritzel>
longsleep: U around?
<apritzel>
thinking about booting BSP kernels with upstream U-Boot ...
<lennyraposo>
really?
<apritzel>
though I dislike the idea to support that crap...
<apritzel>
the more pain BSP kernels induce, the better ;-)
<lennyraposo>
apritzel
<apritzel>
but I think without Allwinner code we don't have HDMI initialization?
<apritzel>
or does the BSP kernel do that itself?
<longsleep>
apritzel: yep
<lennyraposo>
I am assuming we still need usb/ethernet functionality before dumping the blobs
<longsleep>
apritzel: it would be nice to get rid of BSP U-Boot - even if still on BSP Kernel
<apritzel>
longsleep: yep to: the kernel does HDMI initialization?
<apritzel>
longsleep: I agree on that point: the less Allwinner based code, the better
<longsleep>
apritzel: well the U-Boot does it for sure, i do not know what happens if the disp2 driver gets loaded without U-Boot having initalized it before
<longsleep>
maybe its just done in u-boot to show early boot logo
<apritzel>
also I think Allwinner's U-Boot does a lot of PMIC setup
<jernej>
longsleep: This works on H3, but don't know for A64
<longsleep>
apritzel: you think it is worth to explore or probably waste of time?
hrw has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<longsleep>
apritzel: i also have plans to provide a transition from BSP Kernel to mainline if that is possible - booting mainline with BSP U-Boot has worked in the past right?
<apritzel>
I think so, but haven't tried it lately
<lennyraposo>
bugging tllim again abotu Allwinner and the Mali situation
<lennyraposo>
they promised it a week ago
<lennyraposo>
in a message forwarded to me
<apritzel>
longsleep: I don't think you will get very far without the PMIC setup in U-Boot
<apritzel>
longsleep: and porting that over to U-Boot is a dead end, since it relies on that dodgy arisc mailbox protocol
jinzo has quit [Quit: Leaving]
<longsleep>
apritzel: so maybe i should explore mainline kernel with BSP U-Boot first, once mainline has all features BSP u-boot goes away as well
<apritzel>
also I'd like ATF to do that in the long run (initial PMIC setup, maybe smc calls for later adjustments)
<apritzel>
why do you want to use BSP U-Boot?
<apritzel>
to have a common image for BSP and mainline kernels?
<longsleep>
apritzel: yes
<longsleep>
apritzel: have a update-kernel --mainline - you are on mainline
<longsleep>
update-kernel --bsp - you are on bsp
<longsleep>
something like this
<longsleep>
apritzel: also i would like to see a upgrade path for all the people having my images now - they should not be stuck on BSP Kernel forever
<apritzel>
frankly I'd rather see more effort spend into mainline kernel support
<lennyraposo>
well what can I do
<longsleep>
yes i know - i am scared of the time it would take me to do anything useful
<apritzel>
also the effort customers put into your images are mostly resulting in rootfs changes, I guess
<lennyraposo>
thing slike testing out USB
<longsleep>
apritzel: well, i really only care about my minimal Xenial image and leave the rest to others
<lennyraposo>
hey longsleep
<apritzel>
so if people upgrade to mainline, I'd hope this would upgrade the firmware bits as well
<lennyraposo>
if you like I can help you out there
<apritzel>
lennyraposo: longsleep: my a64-wip tree has code for Ethernet and USB
<lennyraposo>
from the H3?
<apritzel>
it just doesn't work atm :-(
<lennyraposo>
:(
<apritzel>
lennyraposo: yes, with appropriate DT changes as well
<lennyraposo>
been reading all the allwinner docs thus far
<lennyraposo>
manual datasheet
<lennyraposo>
I can distinguish between certain elements thus far
<longsleep>
other question, did anyone here ever try the 3D display modes of any disp2 SoC?
<lennyraposo>
not me
<lennyraposo>
apritzel which brings me to my next question
<lennyraposo>
how do you start figuring out things/testing the hardware?
<lennyraposo>
is there some sort of method
<lennyraposo>
for probing the devices say in android/bsp?
<lennyraposo>
or 3rd party tools involved?
Gerwin_J has joined #linux-sunxi
<apritzel>
lennyraposo: well, you just try to use it, I guess
<apritzel>
and see where it fails
<apritzel>
then in the first run: guess why and trying to fix this
<apritzel>
reading dmesg definitely helps
<apritzel>
next step usually is inserting printk in the driver
<lennyraposo>
same as x86 hardware in other words
<apritzel>
or enabling existing debugging
<apritzel>
lennyraposo: why not? there is no secret ARM sauce ;-)
<lennyraposo>
lol
<lennyraposo>
I dunno
<lennyraposo>
a company that holds on to the belief of providing binaries instead of sources seems to be hiding some sort of secret suace in their builds ;)
<apritzel>
lennyraposo: the Mali situation is quite complex ...