premoboss has quit [Remote host closed the connection]
Ueno_Otoko has quit [Ping timeout: 240 seconds]
Ueno_Otoko has joined #linux-sunxi
orly_owl has quit [Ping timeout: 272 seconds]
<wens>
:)
<apritzel>
Ubuntu Core just booted from a partition on the SD card ...
<apritzel>
lack of network is annoying, though
<apritzel>
will look at enabling USB next, so I can use USB Ethernet or WiFi until the GMAC driver is ready
<wens>
that was fast
<apritzel>
wens: actually there wasn't sooo much to do
<apritzel>
thanks to all of the linux-sunx people's work on the other Allwinner chips
<apritzel>
the A64 is basically an H3 with Cortex-A53 cores
<apritzel>
will send my patches later this week (including a DT)
<apritzel>
time for some sleep now ...
cnxsoft has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
orly_owl has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 265 seconds]
p1u3sch1 has joined #linux-sunxi
apritzel has quit [Ping timeout: 248 seconds]
vishnup has quit [Quit: Connection closed for inactivity]
vagrantc has quit [Quit: leaving]
naobsd has joined #linux-sunxi
ninolein has quit [Ping timeout: 250 seconds]
ninolein has joined #linux-sunxi
naobsd has quit [Remote host closed the connection]
a|3x has joined #linux-sunxi
Andy-D has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
naobsd has joined #linux-sunxi
orly_owl has quit [Ping timeout: 265 seconds]
TheSeven has quit [Ping timeout: 260 seconds]
TheSeven has joined #linux-sunxi
Ueno_Otoko has quit [Remote host closed the connection]
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1 has joined #linux-sunxi
vishnup has joined #linux-sunxi
Deskwizard has joined #linux-sunxi
Deskwizard has quit [Client Quit]
Deskwizard has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
Ueno_Otoko has joined #linux-sunxi
solarnetone has quit [Remote host closed the connection]
solarnetone has joined #linux-sunxi
_stephan has joined #linux-sunxi
yann|work has joined #linux-sunxi
pekka30 has joined #linux-sunxi
<topi`>
apritzel1: so, you have a concrete Pine64 in your hands?
<topi`>
how do you plan to network it, since it lacks basic networking like ethernet?
<topi`>
I should get one myself as well, but would like to have 2 GB of ram
cajg has joined #linux-sunxi
tucker has quit [Remote host closed the connection]
<wens>
topi`: he got it last week, the pre-prod boards
lemonzest has joined #linux-sunxi
<wens>
network is getting there. it's the same emac as a83/h3, which montjoie is working on
<montjoie>
for the ethernet status: I booted up a83t yesterday and this week i will try to test my driver on it
<montjoie>
since PHY clock are different between H3 and A83T I expect that it will help me to find the problem I got on H3
<wens>
looking at a83 usb clocks... it has controls for usb host 2, which is non-existent...
<wens>
hmm
<wens>
maybe they just forgot to delete the section when they copied the a80 :/
domidumont has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
A20_nand_boot has joined #linux-sunxi
gzamboni has quit [Ping timeout: 256 seconds]
SadSmile has joined #linux-sunxi
<vishnup>
Which branch mripard use to push next patches?
gzamboni has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 265 seconds]
cnxsoft1 is now known as cnxsoft
_massi has joined #linux-sunxi
pietrushnic has quit [Ping timeout: 260 seconds]
<wens>
his repo over on git.kernel.org
pietrushnic has joined #linux-sunxi
<wens>
but stuff for 4.6, like a83, hasn't been published yet, so you have to keep track yourself for now, until 4.5-rc1 is out
yann|work has quit [Ping timeout: 240 seconds]
<vishnup>
Okie
matthias_bgg has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
orly_owl has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 265 seconds]
p1u3sch1 has joined #linux-sunxi
A20_nand_boot has quit [Quit: Page closed]
maz_ has quit [Remote host closed the connection]
premoboss has joined #linux-sunxi
pietrushnic has quit [Ping timeout: 272 seconds]
pietrushnic`away has joined #linux-sunxi
pietrushnic`away is now known as pietrushnic
<apritzel1>
topi`: Yes, I got a preproduction board sent by the Pine64 guys
<apritzel1>
topi`: networking: for debugging and testing the real GMAC driver I plan to use a USB Ethernet dongle
<apritzel1>
montjoie: do you have your H3 MAC driver somewhere already?
apritzel1 is now known as apritzel
maz_ has joined #linux-sunxi
diego_r has joined #linux-sunxi
<montjoie>
apritzel: no but I could made it availlable
<montjoie>
just a bit of work for removing crapiness
<apritzel>
montjoie: that would be great, can send it privately if you prefer that
caog has joined #linux-sunxi
domidumont has quit [Read error: Connection reset by peer]
domidumont has joined #linux-sunxi
domidumont has quit [Read error: Connection reset by peer]
Ueno_Otoko has quit [Ping timeout: 260 seconds]
<apritzel>
montjoie: just sent a reply to your mail, don't be scared by the length of it: I agree with you at the end ;-)
enrico_ has joined #linux-sunxi
<wens>
apritzel: i assume you're somewhere in europe?
<apritzel>
wens: yes, UK
yann|work has joined #linux-sunxi
Nacho_ has joined #linux-sunxi
speakman has quit [Ping timeout: 276 seconds]
p1u3sch1 has quit [Ping timeout: 255 seconds]
p1u3sch1 has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<tkaiser>
Anyone here with insight's into A64's USB implementation? Can the OTG port used as true host controller or apply the limitations for older Allwinner SoCs?
apritzel1 has joined #linux-sunxi
<apritzel>
tkaiser: good question, was wondering about that yesterday too
<apritzel>
apparently the SoC has 1 host and one OTG controller, right?
<apritzel>
the board has 2 USB Type A sockets (with no further differentiation), so I was assuming that the OTG port can be used as a host as well
<tkaiser>
Yes, but the OTG spec sounds different compared to older SoCs where OTG can not be used as a full replacement fpr a
<tkaiser>
for a host controller
engideavr has joined #linux-sunxi
<apritzel>
actually let me give this a try with their kernel ...
<tkaiser>
Regarding the Type-A port there was some discussion in the Pine64 forum (useable for FEL mode, ID pin)
<mripard>
tkaiser: really? why?
<apritzel>
tkaiser: how would I check if it's a "full replacement"?
<tkaiser>
mripard: What? OTG as a full host port?
<apritzel>
tkaiser: would attaching a USB drive and verify it works be sufficient?
<tkaiser>
That was my understanding based on statements from wens and Hans
<tkaiser>
No idea. I'm not familiar with 'low level' USB stuff at all. I just ask myself whether 1 'real' host port would be enough
<mripard>
hans has been using it to attach usb keyboards to his tablets without issue afaik
<tkaiser>
Yes, but my understanding was that some peripherals won't work and that OTG and host ports are different hardware in older sunxi SoCs.
speakman has joined #linux-sunxi
<tkaiser>
Now I wonder whether that also applies to A64
domidumont has joined #linux-sunxi
<wens>
the diagram from the manual shows a complete ehci/ohci pair behind a switch for OTG
Ueno_Otoko has joined #linux-sunxi
<wens>
in older SoCs, OTG was mentor graphics musb hardware, which sucked according to many
<wens>
the A64 seems to have a proper usb host switched with a usb gadget controller
<wens>
question is whether the usb gadget controller is a commonly found one, and whether we can reuse mainline drivers for it
ricardocrudo has joined #linux-sunxi
<apritzel>
tkaiser: wens: just checked it with their (Android) kernel: I can attach and use USB devices on both the A64 USB sockets (also at the same time)
<apritzel>
since I don't see a HUB chip on the board, I guess it's two different controllers
avph has quit [Ping timeout: 255 seconds]
<apritzel>
can do more investigations tonight
<apritzel>
(wanted to try USB on the upstream kernel anyway)
<wens>
the code for the otg controller seems the same as earlier SoCs
<wens>
they probably just put an SIE switch in front of it for a proper host
<tkaiser>
wens: Thx for the clarification. Now I'm thinking about that 'ID pin' thing a bit ;)
<wens>
let me check the schematics
<wens>
right... they haven't released it
<wens>
checking olimex's version then
avph has joined #linux-sunxi
Ueno_Otoko has quit [Ping timeout: 245 seconds]
<wens>
tkaiser: the id pin is just a gpio
<wens>
there's no dedicated id pin
<tkaiser>
Quoting TL Lim: "Currently the schematic lets the ID pin float with a pull high resister. In current Pine64 Android OS, we manually set the lower USB port to host mode instead of determine by ID pin. We welcome any suggestion and implementation." regarding Pine64
<tkaiser>
Disclaimer: I understand nothing, just a quotation
<tkaiser>
At least it should be possible to switch between the modes :)
<apritzel>
tkaiser: well, since it's a Type A socket, there is no ID pin which you could connect to, right?
<tkaiser>
Yes
<apritzel>
so to use OTG you would need a "hacked" cable _and_ to manually switch the port in Linux
<tkaiser>
And would then not be able to use FEL mode?
<apritzel>
I guess that depends on their firmware (BROM?) and how they initialise the OTG controller
<apritzel>
can send a BROM dump if you want to walk through it ;-)
<tkaiser>
Nope!
<tkaiser>
I lack the skills. All I understand now is that I'll have to wait to get answers regarding USB :)
<plaes>
apritzel: could you upload that brom dump somewhere?
<plaes>
or at least send it to list
<apritzel>
isn't that copyrighted?
<apritzel>
(working for a big company with a big legal department I need to pay attention to those things, unfortunately)
<plaes>
ahh.. indeed
<plaes>
although, that company doesn't really have problem shipping another blob around :P
pietrushnic has quit [Ping timeout: 250 seconds]
vishnu_ has joined #linux-sunxi
<apritzel>
plaes: shipping blobs is not the problem (if you have permission to do so)
<apritzel>
but dumping data (or code) from some device and publishing it is another story
<plaes>
yeah.. it was a stupid analogy
<apritzel>
plaes: and don't give up the hope on Mali ;-)
<libv>
apritzel: why, will Jem retire soon?
apritzel1 has quit [Ping timeout: 248 seconds]
<libv>
or is it now under consideration, now that the prince of darkness has all but completely given up on it?
domidumont has quit [Remote host closed the connection]
<ssvb>
in theory they could implement a vbus voltage detection pin for this port for deciding whether to switch into the gadget mode
_stephan has quit [Quit: Ex-Chat]
<ssvb>
but as wens noticed, if they have a proper usb host controller for this receptacle which is just multiplexed with musb, then we can just pretend that musb does not exist :-)
<apritzel>
ssvb, thanks for the pointer, looks like it
<apritzel>
... will become an USB evening for me tonight ;-)
<ssvb>
looks like all the mainlining work will be finished even before I receive my board...
<ssvb>
not that I have any reasons to complain :-)
<wens>
my board is stuck in mail somewhere
<wens>
one would assume cross-straight mail would be faster than to other parts of the world
JohnDoe_71Rus has joined #linux-sunxi
matthias_bgg has quit [Remote host closed the connection]
<ssvb>
my pine64 has supposedly left China a week ago, but has not resurfaced in Europe yet
<apritzel>
wens: ssvb: becomes even more strange if you would know how it is packaged ;-)
<apritzel>
basically an air-cushioned envelope with an anti-static bag around the naked board in it
<apritzel>
so nothing really fancy or big, most advertisements I get are better wrapped ;-)
vishnu_ has quit [Ping timeout: 240 seconds]
vishnu_ has joined #linux-sunxi
apritzel1 has quit [Ping timeout: 248 seconds]
reinforce has joined #linux-sunxi
Ntemis has quit [Remote host closed the connection]
whitesn has quit [Ping timeout: 265 seconds]
whitesn has joined #linux-sunxi
whitesn has quit [Changing host]
whitesn has joined #linux-sunxi
viccuad has joined #linux-sunxi
<tkaiser>
apritzel: Does your Pine64 have Fast or GBit Ethernet?
<apritzel>
GBit apparently
<apritzel>
it's an Realtek 8211E PHY
<tkaiser>
Yes, then it's GbE
<apritzel>
so it's the Pine64+ with 1 GB
Nacho_ has quit [Read error: Connection reset by peer]
<tkaiser>
BTW: TL Lim wrote that DRAM frequency should be 1333 MHz but they would use 1600 MHz on the dev samples
Nacho_ has joined #linux-sunxi
<apritzel>
though it doesn't work atm with their kernel due to a bug (I wonder if this is about the wrong second DT reg property ;-)
<tkaiser>
Ethernet?
<ssvb>
tkaiser: to be pedantic, that's likely 1333 MT/s and not MHz :-) sounds great, but we will see if it is stable at the 1600 MT/s (800 MHz) speed
<apritzel>
Gigabit, specifically, Fast Ethernet seems to work reportedly
<apritzel>
at the DRAM clock is at the famous 672 MHz
<tkaiser>
ssvb: lima-memtester again? :)
<apritzel>
tkaiser: can you work out the chips max freq from the print on it?
<tkaiser>
Nope, no board here. Still stuck somewhere
<ssvb>
tkaiser: yes, it should probably work (assuming that the old mali r3p0/r3p2 kernel driver is 64-bit safe)
<apritzel>
tkaiser: I meant would it help if I write it here ;-)
<tkaiser>
Ah, well specs are one thing and memory controller, routing another.
<tkaiser>
apritzel: Same is written for H3 but in reality we had some users of H3 boards that were able to exceed that and some others where reliability was affected below 672 MHz
<tkaiser>
IIRC we now use 624 MHz in u-boot
<apritzel>
yeah, I read about that mess in the wiki
<apritzel>
tbh I prefer stability over performance
<apritzel>
If I want something fast, I use my PC ;-)
<wens>
vishnu_: ignore the unknown CIS stuff
<apritzel>
those few MHz don't really matter for the greater picture anyway
<wens>
vishnu_: only thing that matters is does it work? :)
<catphish>
apritzel: i figured it would be quite important, but i know very little of the underlying operation :(
<apritzel>
NiteHawk: nice one!
<catphish>
i assume i need to enable l1 and l2 caches somehow, and potentially also configure instruction caching / pipeline?
<apritzel>
that is trivial (just set the Icache and Dcache enable bits)
<apritzel>
but you need to enable the MMU to be able to do this, which is not trivial
<maz_>
apritzel: and a linear mapping, or you'll be surprised...
<catphish>
apritzel: so i need to set up a 1:1 memory map, enable the MMU, then enable the cache?
<apritzel>
catphish: yes, it's not rocket science, but devil's in the detail
<catphish>
apritzel: thanks, do i need to fine the ARM cortex manuals to figure it out?
<apritzel>
but if you are concerned about performance, it's probably the way to go
<apritzel>
catphish: more the ARM ARM (ARM architecture reference manual)
<catphish>
thanks
diego_r has quit [Ping timeout: 265 seconds]
<catphish>
there's the performance of my own code too, which i feel i haven't quite got right
<catphish>
but best to combine both approaches
<maz_>
catphish: talking about performances without caches is similar to trying to get a tan in the UK during the winter.
<maz_>
catphish: trust me, I've tried both.
<catphish>
maz_: makes sense! i live in dorset and I'm white as a sheet
<maz_>
catphish: first hand experience, then! ;-)
<catphish>
indeed!
<catphish>
i'm trying to find a computationally cheap way to rearrange the bits of 32 separate words into 32 new words where each word in the new string represents a particular bit from each of the original 32 words
<catphish>
in order to bitbang 32 streams simultaneously
<apritzel>
catphish: sound like a task for NEON to me
<catphish>
oh wow, yes
<apritzel>
(assuming with "word" you mean u32)
<catphish>
correct
nove has joined #linux-sunxi
<catphish>
i have 32 strings of bits (word length not important), i want to take one bit from each stream at a time, and push the resulting bitmap to a port
<catphish>
right now, the loop i'm using to do this is woefully inefficient
<catphish>
anyway thanks for the suggestions once again :)
vishnu_ has quit [Ping timeout: 260 seconds]
apritzel1 has quit [Ping timeout: 248 seconds]
vagrantc has joined #linux-sunxi
lemonzest has joined #linux-sunxi
caog has quit [Quit: Ex-Chat]
Deskwizard has quit [Remote host closed the connection]
soderstrom has joined #linux-sunxi
<ssvb>
apritzel: there is a wip kms driver for h3, maybe it will work on a64 too
ricardocrudo has quit [Remote host closed the connection]
mosterta has quit [Ping timeout: 272 seconds]
bmeneg has joined #linux-sunxi
interrobangd has joined #linux-sunxi
fire855 has quit [Ping timeout: 252 seconds]
orly_owl has quit [Ping timeout: 240 seconds]
afaerber has joined #linux-sunxi
nove has quit [Quit: nove]
FDCX has quit [Ping timeout: 250 seconds]
<catphish>
wow, enabling MMU is far more involved than i imagined!
orly_owl has joined #linux-sunxi
apritzel has quit [Ping timeout: 248 seconds]
FDCX has joined #linux-sunxi
interrobangd has quit [Quit: Leaving]
naobsd has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
apritzel has joined #linux-sunxi
yann|work has quit [Ping timeout: 272 seconds]
<apritzel>
catphish: ;-)
<apritzel>
for an ident mapping you don't need all levels, though
<catphish>
i found an example of how to do a single level identity mapping, which is ideal
<apritzel>
yeah, that's what I meant
<apritzel>
how much DRAM memory do you actually use?
<apritzel>
in the end you could just map the memory that you need, so DRAM or SRAM and the peripherals
<catphish>
i only use about 64k of DRAM
<catphish>
and even less SRAM
<catphish>
i want to map it so i can disable caching on peripherals and DRAM (since i only use it for DMA reads), and enable for SRAM, and also enable the icache (which i dont believe needs the MMU)
<catphish>
right now however, i've taken a few steps back because i realised i don't actually understand how my program is loaded and booted, i dont understand entry point at all
<apritzel>
you _have_ to map the device memory as non-cached
<catphish>
apritzel: makes sense
<apritzel>
see the memory attribute field in the (section) table format
<apritzel>
catphish: the tables in the Wikipedia article on ELF might give you a quick introduction
<catphish>
just trying to decide where to put the 16k table
<catphish>
oh yeah, was just on the wikipedia ELF page
lemonzest has quit [Quit: Leaving]
<catphish>
it appears the code starts at 0x8000, seems like a waste of space
<apritzel>
16K table?
<apritzel>
32KB a waste of space?
<apritzel>
and you can always use that memory before the entry point (or adjust the offset while linking)
<catphish>
16k was the size i read a first level page table would be
<catphish>
ie 4096 page descriptors
<catphish>
and yes, 32k seems like a huge amount of sram to waste, i dont yet understand why the code starts to far into the ELF
<apritzel>
ah, you mean the size of the page _table_ (I was wondering about a 16K page size)
<catphish>
correct :)
<apritzel>
and OK, in SRAM terms 32K is admittedly big ;-)
<apritzel>
the 32K offset is defined by the ARM EABI, AFAIK
<apritzel>
you can change it if you like
<apritzel>
try -Ttext= on the ld command line
<catphish>
i suppose it doesn't matter, i can clobber than 32k after it's loaded
<apritzel>
right, for instance you can put the page table there ;-)
<catphish>
indeed
<catphish>
and the stack
<catphish>
16k each
<apritzel>
remember, ELF is meant for virtual memory, so there is no real memory wasted by this
<catphish>
i see
<catphish>
for now i feel comfortable in real memory, knowing where everything actually is
<apritzel>
for a single task environment: sure ;-)
<catphish>
indeed :)
<catphish>
well i'm happy then, i know where to put my pagetable, my stack and my code, the only thing that wont fit in sram is my ethernet dma, but thats fine in dram
<catphish>
i'll go code a pagetable
<apritzel>
how big are our DMA buffers? they may happen to fit in the cache ...
<catphish>
well right now, 256k, but i could shrink them to half that
<catphish>
will writes from the MAC get cached? i assumed they wouldnt and i'd have to bypass the cache to get the right data
vishnup has joined #linux-sunxi
nashpa has quit [Ping timeout: 272 seconds]
<apritzel>
the bus should be coherent and take care of this
<apritzel>
so the write from the MAC to DRAM is not cached, but accesses from the CPU go through the cache
<catphish>
isn't that bad? since a cache hit wont contain the data that was just written?
<apritzel>
AFAIK the cache snoops on the bus, sees that data is written (from MAC to DRAM) and invalidates the cache entry
<catphish>
cool
<catphish>
i guess i'll find out, but in that case i might as well disable it
tomboy64 has quit [Quit: Uhh ... gotta go.]
<catphish>
since im never interested in reading the same DRAM twice