kaspter has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
TheSeven has joined #linux-sunxi
kaspter has joined #linux-sunxi
naobsd has quit [Quit: naobsd]
<sabresfan03>
heys guys, I would like to do some kernel dev on OrangePi PC (Im a software dev for my day job), do you guys have any suggestions on where to start (ie which git repo to base on, tips on boot like tftp)?
viccuad has quit [Ping timeout: 265 seconds]
Ueno_Otoko has joined #linux-sunxi
apritzel has quit [Ping timeout: 246 seconds]
interrobangd has joined #linux-sunxi
interrobangd has quit [Client Quit]
<yann|work>
tkaiser: got most stuff (notably except w1), testing tomorrow
<tkaiser>
The bunch of problems I listed to yann|work yesterday for H3/3.4.39 also applies to Cubietech's OS image. I though about adding a note in the Wiki
pietrushnic has quit [Ping timeout: 264 seconds]
pietrushnic`away has joined #linux-sunxi
pietrushnic`away is now known as pietrushnic
<montjoie>
I have some good news for H3 EMAC, packet reception and transmission works, BUT packet was never sent by the PHY
<montjoie>
seems that the PHY is unstable always got 100halfduplex
<montjoie>
so if someone have an H3 with a 3.4 kernel for dumping content of 0x01C00030 register
<mripard>
MoeIcenowy: nothing seems to not work, I just haven't tested it that much
<mripard>
and yeah, I'll push it some time today
<wens>
montjoie: is mdio working?
avph has quit [Ping timeout: 260 seconds]
danboid has quit [Remote host closed the connection]
<montjoie>
wens: yes communication with MDIO works
<montjoie>
I try to play with MDC and all MII parameters but nothing change
<montjoie>
ONE time I got full duplex
avph has joined #linux-sunxi
<montjoie>
but just after it lost the link and re 100half
<montjoie>
this is strange since all packet received are good
<montjoie>
only transmission failed
matthias_bgg has joined #linux-sunxi
<wens>
vishnup: i'm playing with gmac on a83t now
<wens>
vishnup: need your clock patches :)
premoboss has joined #linux-sunxi
FlorianH has joined #linux-sunxi
lemonzest has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
avph has quit [Ping timeout: 255 seconds]
_massi has joined #linux-sunxi
avph has joined #linux-sunxi
yann|work has joined #linux-sunxi
<wens>
a83t user manual is wrong :(
captainigloo has quit [Quit: Bye Bye]
sabresfan03 has quit [Read error: Connection reset by peer]
sigjuice has quit [Ping timeout: 264 seconds]
sigjuice has joined #linux-sunxi
<MoeIcenowy>
how to make a simplefb work on allwinner a33 mainline kernel?
<MoeIcenowy>
(lcd display
<wens>
MoeIcenowy: you have to build u-boot with the proper config
<wens>
see http://linux-sunxi.org/LCD on how to convert the settings from your fex file to mainline u-boot config options
gzamboni has quit [Ping timeout: 250 seconds]
<wens>
montjoie: a83 emac is likely the same as h3
_stephan has joined #linux-sunxi
<MoeIcenowy>
wens: now I have saw the uboot console
<MoeIcenowy>
it should be a "proper" config
<montjoie>
wens: so not a stmmac ?
<apritzel>
wens: a83 emac the same as H3?
<apritzel>
are you sure?
<apritzel>
looks like the A20 GMAC to me (looking at the register layout only for a start)
<wens>
register dump does not match the user manual :/
<apritzel>
ah
<apritzel>
oh dear!
<wens>
register dump repeats @ 0x1000, which is more like H3 emac
catphish has joined #linux-sunxi
<wens>
and u-boot designware driver doesn't work
<wens>
so quick guess is it's not dwmac :(
mmwolbrink has joined #linux-sunxi
<montjoie>
wens: if you could share register dump :)
<catphish>
can anyone point me to a resource to get started learning about how to address memory on an a20?
<wens>
catphish: what do you mean by addressing memory?
enrico_ has joined #linux-sunxi
<wens>
the user manuals include a memory map
<montjoie>
so it is the moment to begin to play with my a83t for testing the emac driver...
<apritzel>
so the A83T manual describes the A20 GMAC, which lacks this description? Oh dear ...
<apritzel>
and the H3 manual describes the A83 EMAC
<wens>
montjoie: give me a sec to get my other a83 board
<catphish>
wens: thanks, i'm looking at that, is the SRAM just flat? and does DRAM require a driver?
<montjoie>
wens: no hurry I am at work, so I cannot do any test before this night
<wens>
catphish: dram requires a lot of init code, which can be found in mainline u-boot if supported
libv_ is now known as libv
<apritzel>
catphish: I'd suggest you load yourself from u-boot, disguising as a Linux kernel
<apritzel>
then you have everything setup already
<catphish>
apritzel: i am indeed booting as an ELF from u-boot, and this is perhaps what's leading to my confusion? has u-boot set up some virtual memory?
<apritzel>
or you could code your application directly within u-boot, as a new command for instance
<apritzel>
catphish: depends on the configuration, but the kernel boot protocol requires to be entered with the MMU _off_
<apritzel>
so if U-boot enables the MMU (required for enabling the caches!), it disables it again just before entering the kernel
<catphish>
apritzel: thanks, the reason for my confusion is that i'm creating stack variables, and their addresses (C pointers) aren't always in the SRAM regions i expect from the manual, i don't know if this is because memory is being virtualized, or because i'm overallocating
<catphish>
for example, i tried to create 2 x 32kB arrays on the stack, the ended up at 0xB,000 and 0x13,000, this is actually too much data to fit in the SRAM A, so perhaps i just overflowed the stack
leio has joined #linux-sunxi
<catphish>
i'll go read more about how the DMA works, and where i should be putting my DMA Ethernet buffers
von_fritz_ has joined #linux-sunxi
<wens>
montjoie: furthermore, the reset bit in @0x4 works
<rellla>
von_fritz_: i just wanted to say, that this is the/one way to go imho. because you referenced an irc log in the opi forums :p
<von_fritz_>
yes I know, I can try to propose this to jernej :)
<rellla>
please help to get rid of the blobs and aw media-codec.
focus has quit [Ping timeout: 265 seconds]
Ueno_Otoko has joined #linux-sunxi
<rellla>
the only way to get a mainline driver in the end, is to make people interested in this free driver. otherwise, if nobody cares, nothing will happen.
* catphish
suddenly understands stack overflow
<von_fritz_>
@rellla thats why I have removed the h3 branch on my openelec fork ;)
<rellla>
you may be the connection to oranpi forum, as you seem to be very active there.
<rellla>
von_fritz_: i see, you know, what i want to talk about ;)
<apritzel>
catphish: so if you are running after u-boot, you have all the DRAM available - no further setup needed
<catphish>
apritzel: sorry, i think i misunderstood, does this not require the MMU to be set up, and didn't you say u-boot disabled it?
<wens>
my pine64 pre-prod board should arrive tomorrow or next monday
<apritzel>
wens: have fun with it, but don't expect to run your own sane code to be run easily ...
<apritzel>
their firmware setup is a bit weird
<apritzel>
preventing both upstream u-boot and upstream kernels without hacks
<apritzel>
in fact both boot0 and u-boot seem to run in 32-bit mode
Gerwin_J has joined #linux-sunxi
<apritzel>
I plan to run a simple upstream U-boot first (I couldn't get their BSP u-boot to compile)
<apritzel>
this tree in this tarball is definitely broken
<apritzel>
montjoie: by the way: I got an email from the pine64 guys yesterday: apparently they have issues with gigabit too
<apritzel>
montjoie: "I think you have connected Pine A64 board to Gbe line. As mentioned in forum, we still encounter issue when connected to some Gbe network, this is driver issue and software engineer currently fixing this issue. The 10/100Mbps works fine."
<wens>
gigabit requires tweaking the gmac clk bits
<wens>
also the pins need to be set to maximum drive strength, or the rise and fall edges would be distorted iirc
rds has joined #linux-sunxi
<apritzel>
I could peek at their driver for the magic GMAC clock setup (they set undocumented bits there), but as mentioned above that may not hold the solution either
<rds>
montjoie: dump of 0x01C0_0000 -> 0x12
<montjoie>
exactly I need 0x01c0 0000 + 0x30 the emac clk register
<rds>
sorry: 0x01C0_0030
<montjoie>
apritzel: orangepi pc is not with Gbit, only internal MII with 100M max
<rds>
0x01C0_0030 -> 0x12
<montjoie>
thanks rds, just for info it is not a opipc ?
<rds>
0x01C0_0000 -> 0x128
<rds>
it is an OPI-PC
<apritzel>
montjoie: what does "internal MII" mean here exactly?
<wens>
montjoie: for 10/100 you shouldn't need to tweak emac clk bits, only the internal phy bits?
<montjoie>
strange because 0x12 meens 10: Internal transmit clock source for GMII and RGMII
<wens>
apritzel: H3 includes a 10/100 PHY within the SoC
<apritzel>
wens: really?
<wens>
apritzel: yes, which some claim is one of the reasons it runs hot and uses a lot of power
<montjoie>
wens: the EMAC_CLK_REG is neede for selecting MII like the ETCS. register (00: Transmit clock source for MII)
<wens>
apritzel: and some of the controls for that phy are in the upper bits of emac clk cfg reg (bits 13:31)
<montjoie>
and seems I am sure now the problem is from PHY, I blindly try all options
<wens>
montjoie: yeah, but isn't that the default?
<apritzel>
wens: yeah, I found that and was confused over this ...
<montjoie>
wens: yes but I need to activate bit 16 SHUTDOWN for example
<montjoie>
(desactivate in fact)
<wens>
montjoie: right, i meant you shouldn't need to touch the clk bits, just the phy related bits
<wens>
(confusing indeed)
<montjoie>
what do you thing for bit 18 clk_sel 24 or 25 Mhz, for all my readings, all xMII wroks with 25Mhz
<montjoie>
but only using 24Mhz works
* wens
guesses its clock is taken from 24M osc
focus has joined #linux-sunxi
<wens>
do you have other h3 board, or a83 board?
<montjoie>
I have the A83T homlet
<montjoie>
I need to setup it
<apritzel>
for the records from looking at the BSP driver: bit 15 seems to control the internal PHY power, and bit 16 is just the negation of this
<apritzel>
so they set bit 15 and clear bit 16 for the internal PHY and the other way round for external PHYs
<montjoie>
apritzel: yes it is what I do
<apritzel>
also they set bit 17 and 18 is the internal PHY is selected
hipboi_ has quit [Quit: This computer has gone to sleep]
<apritzel>
but there is no comment or speaking variable name for that, just a plain (1 << 15) ...
<montjoie>
bit 18 is the default but 17 not (I will try it but it is named LED_POL)
<wens>
apritzel: the h3 datasheet has the definitions, under section 4.5.3.2
ricardocrudo has joined #linux-sunxi
<apritzel>
wens: Oh indeed, sorry, I missed that
<apritzel>
I just checked that the actual GMAC register description wasn't different ...
<montjoie>
but it is good to know they do that also:)
<apritzel>
montjoie: do you want to know the clock settings as well?
<montjoie>
apritzel: if you could
<wens>
montjoie: not sure if the homlet board is easier to work with... since the phy is another x-powers chip :|
Ueno_Otoko has quit [Ping timeout: 264 seconds]
<apritzel>
just a sec, have to put on gloves before reaching for BSP code ;-)
mmwolbrink has quit [Quit: Leaving]
Gerwin_J has quit [Quit: Gerwin_J]
<rds>
0x01C0_0030 -> 0x00068000
<montjoie>
rds: better:)
<rds>
I rebooted and connected a cable
<rds>
to a 1Gb router
<montjoie>
0x12 was very puzzling me:)
<montjoie>
so the only missing part to be the same is to activate LED_POL
mmwolbrink has joined #linux-sunxi
<apritzel>
so for RGMII: set EPIT(bit 2), set ETCS to 0b10, ERXDC to 31, ETXDC to 7
<apritzel>
where is the sense in a 24 MHz MII PHY clock?
<montjoie>
:)
<wens>
doesn't compute :p
* wens
bbl
mawe242 has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
<montjoie>
rds: could you also dump 0x01c30000 ? 0 to 0xd0
mmwolbrink has quit [Remote host closed the connection]
avph has quit [Ping timeout: 255 seconds]
avph has joined #linux-sunxi
viccuad has quit [Quit: WeeChat 1.3]
bmeneg has quit [Quit: WeeChat 1.3]
bmeneg has joined #linux-sunxi
bmeneg has quit [Client Quit]
bmeneg has joined #linux-sunxi
bmeneg has quit [Client Quit]
bmeneg has joined #linux-sunxi
<catphish>
apritzel: sorry to bother you, would you mind briefly clarifying what you meant u-boot configuring the DRAM, does it leave this set up when booting an ELF kernel (you mentioned the MMU being disabled), does this mean I am only addressing virtual memory rather than physical memory locations after booting from u-boot? if there's any resources on this i should read, i'd appreciate a link, thanks!
<apritzel>
u-boot (or Allwinner's boot0) sets up the DRAM _controller_, so the configuration of the physical driver side to the DRAM chips
bmeneg has quit [Client Quit]
bmeneg has joined #linux-sunxi
<apritzel>
MMU is completely orthogonal to that
<apritzel>
you can do everything with the MMU off, you are only slower because the caches depend on it
<catphish>
OK, so in this state, i will be addressing raw memory locations, at which point i can either talk to the DRAM controller manually, or enable the MMU
<catphish>
i don't know if I will need DRAM or not, depends somewhat on how the GMAC DMA works
mmwolbrink has joined #linux-sunxi
<catphish>
sorry for the newbie questions, hopefully i'll get my head around it all shortly
<apritzel>
well, since you have _much_ more DRAM than SRAM you might need it
<apritzel>
catphish: after all it's not 1985 anymore, you have a Gigabyte of RAM at your disposal ...
<catphish>
apritzel: i'm primarily interested in Ethernet DMA right now, can this be pointed to SRAM, or DRAM? or either?
<apritzel>
not sure about the memory attributes setup
<apritzel>
but ideally the difference would just be the pointer
<apritzel>
so you could just try it and switch it if needed
<catphish>
i haven't learned how to create a pointer to DRAM yet, with or without the MMU
<apritzel>
how do you "create" a pointer to SRAM?
<catphish>
oh 0x4000 0000---0xBFFF FFFF
<apritzel>
indeed ;-)
<catphish>
sorry, i meant i didn't know where DRAM was, addressed :)
ikmaak has quit [Read error: Connection reset by peer]
<apritzel>
that's the maximum mapping, I guess. so for 1GB of DRAM this region actually ends at 0x7FFF FFFF
Ueno_Otoko has joined #linux-sunxi
ikmaak has joined #linux-sunxi
<catphish>
yes, that makes sense, i have 1GB
<catphish>
and if i enable the MMU, the DRAM will be cached, but accessed in the same way?
ricardocrudo has joined #linux-sunxi
apritzel1 has quit [Ping timeout: 246 seconds]
<apritzel>
basically yes
<apritzel>
(if you actually enable the cache, which you can only do after enabling the MMU)
gianMOD has quit [Remote host closed the connection]
<apritzel>
you could that and setup some huge-page based 1:1 mapping
ikmaak has quit [Read error: Connection reset by peer]
gianMOD has joined #linux-sunxi
ikmaak has joined #linux-sunxi
popolon has quit [Quit: WeeChat 1.3]
<apritzel>
so you run with the MMU, but the addresses aren't actually translated
<catphish>
ok, this is starting to make sense to me, the DRAM is accessible once the DRAM controller is set up, which u-boot does, at a fixed address, i can then choose to configure the MMU which will provide virtual addressing and caching
<catphish>
i don't know why that was so hard to understand :(
<catphish>
i read the GMAC initialization code in u-boot, it was much simpler to understand than the linux driver, so i'm working through that, just got stuck when it came to deciding where to put the DMA buffers
<mripard>
which configuration are you using for the kernel ?
<ssvb>
MoeIcenowy: seems like nobody has extracted a FEX file from this tablet yet (which is a hardware description config, serving a somewhat similar role as DTS)
<MoeIcenowy>
ssvb: I have one
<ssvb>
MoeIcenowy: the wiki page has no link to it
<tkaiser>
catphish: Ah, ok. Sure, there are a couple of good reasons to prefer Lime/Micro over Bananas (sane DC-IN/battery solution, OSHW) but for your development it shouldn't make any difference
apritzel1 has joined #linux-sunxi
<catphish>
tkaiser: i didn't know i'd explained my deployment, but a decent DC input will be essential, i believe one can power the banana over the SATA power port, so that would be ok
<apritzel>
catphish: what's wrong with a 2A microUSB phone charger?
<catphish>
tkaiser: i was worried about the GMAC config for the track lengths on the banana pro, but i think that's a solved problem i can replicate the solution to
<catphish>
apritzel: it requires a USB port
<catphish>
apritzel: not a huge problem admitedly :)
<catphish>
im sure i could easily wire a micro usb plug into a 5v supply easily enough
<apritzel>
catphish: so you don't have mains power, but some other power source providing you 5 V already?
alexxy has joined #linux-sunxi
<apritzel>
you could solder two wires to an USB Type A socket and then use a normal USB-A -> microB cable
<apritzel>
I accidentally plugged in the uUSB cable into the OTG port on my BananaPi the other day
<apritzel>
that worked, except that I got weird I/O errors when accessing an attached SATA SSD
<ssvb>
MoeIcenowy: thanks
<catphish>
apritzel: well i'd assumed both the boards and the LED strips would run from a 5v PSU, but on reflection, running the board from a separate mains 5v USB supply might be a lot more stable
<catphish>
depending how good a power supply i can find
<apritzel>
catphish: so be aware of powering the board by providing power through any other connector (as you mentioned the SATA power port)
<catphish>
interesting
alexxy has quit [Ping timeout: 240 seconds]
<catphish>
the locking mechanism on the micro SD port of my banana broke the first time i put a cad in it, but thats probably a one-off problem :)
<catphish>
i was just thinking that the Olimex would be an all round better product, but i can't explain why i feel that way
<catphish>
anyway, must go do some actual programming now, thanks :)
mozzwald has quit [Quit: leaving]
<tkaiser>
apritzel: Boards using A20/AX209 can be fed through DC-IN, USB OTG and battery. On Banana Pi DC-IN and SATA-power are connected (with a ferrite bead in between). Therefore when powering through USB OTG the disk isn't powered. On the Lime2 it should work (will test than on the weekend together with AXP209 patches for mainline kernel to be able to read-out internal current/voltage values)
alexxy has joined #linux-sunxi
<tkaiser>
And the Olimex board feature a barrel plug with a 'noise-immune' filtering behind. With micro USB you often run in undervoltage situations. And max. current is limited to 1.8A (specs) or approx. 2A (reality)
<tkaiser>
No problem with A20 boards but with A83T (and I would suspect with Pine64 too ;)
<apritzel>
tkaiser: interesting, thanks for that info!
apritzel1 has quit [Ping timeout: 246 seconds]
<catphish>
tkaiser: thanks
catphish has quit [Quit: Leaving]
mozzwald has joined #linux-sunxi
<tkaiser>
catphish: To avoid the micro USB for DC-IN you could either use SATA power (recommended) or even the LiPo battery connector (solder something to it). When input voltage exceeds 4.2V AXP209 disabled the charger
alexxy has quit [Ping timeout: 250 seconds]
Gerwin_J has joined #linux-sunxi
Guest11664 has joined #linux-sunxi
Deskwizard has quit [Ping timeout: 264 seconds]
Guest11664 has quit [Ping timeout: 240 seconds]
focus has quit [Ping timeout: 245 seconds]
domidumont has quit [Read error: Connection reset by peer]
ssvb has quit [Read error: Connection reset by peer]
ssvb has joined #linux-sunxi
engideavr has quit [Quit: Konversation terminated!]
sabresfan03 has joined #linux-sunxi
mawe242 has quit [Ping timeout: 255 seconds]
alexxy[home] has joined #linux-sunxi
speakman has quit [Read error: Connection reset by peer]
speakman has joined #linux-sunxi
speakman has quit [Changing host]
speakman has joined #linux-sunxi
mmwolbrink has quit [Remote host closed the connection]
akaizen has quit [Remote host closed the connection]
libcg has quit [Ping timeout: 260 seconds]
catphish has joined #linux-sunxi
<catphish>
apritzel: just wanted to thank you again for your help, my GMAC driver works now :)
<apritzel>
catphish: really? what can you do? receive / send a frame?
<catphish>
apritzel: so far just receiving, but now i understand how the memory structure and DMA works, i shouldnt have too much trouble expanding it
<catphish>
http://pastebin.com/XfQQ6J3L << this is my *very minimal* implementation of frame receiving, needs a lot of tidying up and error handling, but great proof of concept so far
vishnup has quit [Quit: Connection closed for inactivity]