<oliv3r>
mrnuke: you mean you init it properly, it runs, until you read from it?
<oliv3r>
mrnuke: not really, as one of the first things after init we do, is load u-boot into it
<mrnuke>
oliv3r: dramc_init() returns fine, I can write to the SDRAM, but when I try to read from it, it hangs
cajg has joined #linux-sunxi
<oliv3r>
that's odd, but since you can't verify what you wrote, it may not work at all :p
<mnemoc>
uhm... so mainline is ioremap()ing each resource independently
<mnemoc>
oliv3r: thanks for the point, gladly it's a completely different approach :)
<mnemoc>
s/point/pointer/
<oliv3r>
mnemoc: yeah mainline does it quite differently
<oliv3r>
but more sensibly
<oliv3r>
clocks are handled by the clock framework; you request one from the clock framework; and don't just do everything in your own little driver
<mrnuke>
oliv3r: if I don't run dramc_init(), then it hangs when attempting to write to the RAM. Run it, and I can write fine, just can't read it
<oliv3r>
did you copy our entire dram.c and use it 'as is'?
<mrnuke>
yeah, pretty much as is
<oliv3r>
:(
<mnemoc>
oliv3r: one used to be very conservative regarding the number of ioremap'ed blocks.... now they ioremap each register separatedly
<oliv3r>
well the dramc code is very very fidgidy
<oliv3r>
curse the lack of documentation :::(
<oliv3r>
mnemoc: who maps each register seperatedly?
<mrnuke>
well, to be honest, i delayed asking this for a few days until I got the AXP109 up and running, to make sure it's not a power issue
<oliv3r>
mnemoc: the way it SHOULD be done, is you define your whole block in the DT, and map the whole thing
<mnemoc>
oliv3r: of_iomap()
<mnemoc>
taking the reboot code as reference
<mnemoc>
but it might be an old implementation.... after all it's 3.10
<oliv3r>
mrnuke: assuming your dramc_init() is doing exactly the same thing, you might be missing a clock somewhere, as those are setup outside of dramc (well they might, not 100% sure)
<oliv3r>
mnemoc: ah, reboot code is ugly, it uses the watchdog timer to do a reset
<mnemoc>
sure, and accessing the watchdog registry, which is mostly the same thing I want to do with soc-detect
<oliv3r>
mnemoc: but the watchdog is implemented in the wdt framework; however it doesn't have its own set of registers, it is part of the timer block
<mrnuke>
oliv3r: AXI SDRAM clock.. Is that relevant? (although ungating it does not help)
<oliv3r>
mrnuke: i do not recall; but it does sound like it yes
<oliv3r>
mrnuke: i recall some other bootloader also working on sunxi stuff
<mrnuke>
there's an SDRAM clock on AHB, and one on AXI. dramc_init ungates the one on AHB, but I haven't seen the AXI one touched anywhere
<oliv3r>
also there's MBUS
paulk-collins has quit [Remote host closed the connection]
<mrnuke>
yeah, that seems to be the actual, physical memory bus
<oliv3r>
we can tune it on a13 and a20
<oliv3r>
a10 the registers are ignored
n01 has quit [Ping timeout: 272 seconds]
<oliv3r>
mrnuke: bed time now though :(
<mrnuke>
oliv3r: gn8
<mrnuke>
thanks for the info
<oliv3r>
mrnuke: sorry i can't help you more yet :(
<oliv3r>
mrnuke: if i have more time next week; i'll diginto it a little more
<mrnuke>
sounds good. Just get your share of alcohol, tobacco, and firecrackers tommorow
<andhe>
where can I get the cubietruck wifi firmware?
ZetaNeta has quit [Ping timeout: 272 seconds]
<keebler>
Did some math, to get 3Mhs in Litecoin Mining from an Allwinner A20 ARM CPU, you'd need to buy 2500 cards, at $50 a piece, that's $125,000
<spv>
I was under the impression that Litecoin mining was already unprofitable at the GPU level. Is that true?
hero100 has joined #linux-sunxi
<keebler>
Yes. Unless you have $10K to drop on hardware.... however, it's quite profitable mining Dogecoin atm and converting it to btc
<keebler>
mined .15btc ($90) in 4 days.
<keebler>
Dropped quite a bit though.
bamvor_ has quit [Quit: Leaving]
bamvor has joined #linux-sunxi
<keebler>
only doing 9K dogecoin a day now, and the price of dogecoin has dropped since I started. (although still higher than some swings), anyway, only mentioned it since this is a sunxi channel and I was trying to see (as an exercise in mental curiosity), what it would take to get the EOMA or Olimex cards mining altcoins.
<mnemoc>
3.4? I thought they were using 3.8 for those new chips
<wens>
I only looked at the front of the SDK... not enough disk space left on my VM :p
hero100 has quit [Read error: Connection timed out]
<wens>
let me look at the file list
passat has quit [Remote host closed the connection]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
<wens>
nope, only 3.4
hero100 has joined #linux-sunxi
NightShade has quit [Ping timeout: 252 seconds]
NightShade has joined #linux-sunxi
hero100 has quit [Quit: Leaving]
codyps has quit [Ping timeout: 260 seconds]
codyps has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
<spv>
This is going to be a stupid question ... but what endianness are the Cortex-A7s in the A20s?
<HdkR>
bi-endian
<HdkR>
Starts out in regular little-endian
<HdkR>
Same as most things
<mrnuke>
hold on. You can set an A7 to big-endian?
<HdkR>
Rest of the SoC probably doesn't support running the entire system as bi-endian
<HdkR>
It's just a feature of ARMv7 to be able to switch endian-ness on the fly
<mrnuke>
on the fly? that sounds handy. Is it a mandatory or optional feature? (I know the Cortex-M has it optional)
<HdkR>
I'd have to read the specs again. I think everything supports it
<spv>
Thanks for the info!
<mrnuke>
it would be interesting to hijack and application and silently change the endianess
<mrnuke>
actually, it's a great way to test cross-platform code
<spv>
Is there an Armv7 handbook somewhere that includes information on how to do inter-processor interrupts or communication or somesuch?
<spv>
Looking for info for making smp handlers.
FDCX has quit [Remote host closed the connection]
<HdkR>
spv: Look at the arm architecture reference manual for ARMv7-a/r
<HdkR>
mrnuke: That would only work for code that supports switching endianness at any time. Which nobody does
FDCX has joined #linux-sunxi
<HdkR>
It's always going to be compile time differences :P
<mrnuke>
HdkR: u32 val32 = mem[0] | mem[1] << 8 | mem [2] <<16 | mem[3] << 24; // Read LE 32-bit value
<mrnuke>
I do that in my programs when reading from streams
<HdkR>
Sure, that's a simple bswap32
FDCX has quit [Remote host closed the connection]
<mrnuke>
I guess if the compiler optimizes that, you're SOL
<HdkR>
but if one just swapped the endianness just prior to reading a u32 it would be broken
<HdkR>
Yea, no compiler would be in their right mind to support something that crazy
<mrnuke>
oliv3r: I don't know if you read backlogs, but I managed to get ram functioning by dialing down the clock. No idea why it works, but it works
tomboy64 has quit [Ping timeout: 252 seconds]
<spv>
getting ram functioning sounds important. How far did you get into boot beforehand?
<spv>
Do Cubie* boards simply choose random MAC addresses?
<spv>
Running the android BSP seems to result in random MAC addresses
<spv>
(or whatever was default-installed)
tomboy64 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 248 seconds]
<mrnuke>
spv: I'm porting coreboot to the cubieboard, so I only had a nice shiny console that told me ram init failed :p
<spv>
I feel like I must misunderstand coreboot. My current understanding is that coreboot is a replacement for BIOS on x86 machines.
<spv>
*must be misunderstanding
<spv>
What is it actually? A really fast bootloader?
<mrnuke>
nope. coreboot is just the core boot code. BIOS, or EFI, or whatever (you can boot straight to linux) comes afterward
<spv>
So is the boot ROM on AW parts actually writeable?
<wens>
nope
<spv>
Then where's coreboot going?
<spv>
Replacement for U-boot?
<mrnuke>
nope. I hijack the BOOT0 stage, and take control of the system at that point
<mrnuke>
chromebooks use coreboot to initialize the hardware, then use uboot as a payload, and uboot loads the OS from that point
<spv>
I thought we already ported hardware initialization to the SPL in U-boot ...
<mrnuke>
well, coreboot is like the SPL
<spv>
kk
<mrnuke>
then you can load SeaBIOS to get a BIOS from the machine, load linux directly, load tianocore to get EFI, etc
<mrnuke>
some people load GRUB2, and use that to further load the kernel. It's pretty fast
<spv>
I see large advantages here if the loaders support SATA.
<spv>
the bios / tianocore / grub2 parts
<mrnuke>
on x86, SATA is pretty standardized via PCI, but on ARM, you most likely need device-specific drivers
<mrnuke>
but hey, on ARM, you got SRAM from the start, so you can start your bootblock with a stack and all the bells and whistles
<mrnuke>
on x86, you have to ask the CPU to switch some of it's cache to behave as RAM (cahse-as-ram), and you need to do all that in assembly
<mrnuke>
and you also need to make sure you use very little of that cache, since the cache eviction mechanisms are still enabled
<spv>
I recently dealt with writing a new loader for a PPC board. Having locked cache entries to act as pretend sram was awesome.
<mrnuke>
it's a pretty neat trick indeed
wingrime has joined #linux-sunxi
<spv>
It also showed how unreliable DDR3 controllers are.
<spv>
you can't turn them off.
<mrnuke>
what did you expect? perfect bug-free silicon?
<spv>
I expected a reset routine
<spv>
that wasn't "remove power for a few seconds"
<mrnuke>
why do you think USB3 controllers need firmware?
hero100 has joined #linux-sunxi
<spv>
yes yes because having firmware means you can dynamically change chips to fix stuff
<spv>
it's software
<spv>
speaking of these firmwares, someday I want to spend some time and find a few of the NSA backdoors in hard drives, BIOSes, etc.
<mrnuke>
have you heard of Intel Mangement Engine?
<spv>
Isn't that the feature that prevents inspection of memory, for use for DRM?
<spv>
best way to hide malware ever.
<mrnuke>
Intel southbridges contain an ARC code. it runs out-of-band with the OS, survives system resets, can emulate virtual PCI devices, has full DMA access to memory, and
<mrnuke>
ready for this?
<mrnuke>
It has access to the network adapter(s) in a way that is completely transparent to the OS, including different MAC and IP
<spv>
And that would be where to look first.
<spv>
But it's not modifiable, is it?
<spv>
(the code)
<mrnuke>
it's cryptographically signed, but the pubkey is in the firmware package
<mrnuke>
it's unclear if one can replace it with their pubkey and run modified firmware
<shineworld>
I don't know but my N4 4.4.2 stock is using 3.4.0
<shineworld>
ah A31....
<oliv3r>
mrnuke: speaking of boot0 and hijacking, when you boot from boot0/boot1, you can send a 2 i thinkt o go into fel mode; you can then upload code with the dram actually allready initialized
<oliv3r>
mrnuke: you can use that to compare what you have or have not set
penghb has quit [Quit: Leaving.]
<eagles0513875>
oliv3r: hey do you know what revision i need for build root where mmc was implemented?
<eagles0513875>
i think i have the wrong revision set in build root
<oliv3r>
wingrime: we don't have it :)
<oliv3r>
eagles0513875: never used buildroot; but isn't hte kernel that uses mmc? so swap out kernel
<eagles0513875>
im not sure if that mmc stuff was sent upstream
<oliv3r>
eagles0513875: 3.0 and 3.4 from our repo's all do mmc without problem
<eagles0513875>
oliv3r: is hans in here or does he just use the mailing list?
<oliv3r>
oh no, you there is no mailnine mmc yet
<oliv3r>
he's here sometimes
<oliv3r>
but mainline doesn't do mmc
<eagles0513875>
oliv3r: where was that mmc stuff on the list pushed to?
<oliv3r>
eagles0513875: i think sunxi-next should have it
<eagles0513875>
oliv3r: ok
<eagles0513875>
you have a link to the repo if you dont mind please
<oliv3r>
now your just being lazy :p
<NightShade>
sunxi-devel in the main sunxi git tree has the most upto date tree
<vector80>
oliv3r: I got that tar.xz file, and it creates a folder with same contents also
<vector80>
So I should copy all these to my SDcard, and overwrite with the ones on the eMMC ?
hero100 has quit [Remote host closed the connection]
_massi_ has joined #linux-sunxi
penghb has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
quintin_ has joined #linux-sunxi
foubarre has joined #linux-sunxi
<foubarre>
Hi. Is someone aware of a (recent or not too recent) release of linux where at least OTG (g_mass_storage/..) and GPIO do work? All releases i tested so far (3.3, 3.4) have CPU usage bug or driver disabled. Enabling driver does not make OTG work.
<foubarre>
oh. this is for a CB2 board...
jemk has joined #linux-sunxi
paulk-collins has quit [Quit: Ex-Chat]
paulk-collins has joined #linux-sunxi
foubarre has quit [Remote host closed the connection]
shineworld has quit [Ping timeout: 252 seconds]
tomboy64 has joined #linux-sunxi
wolfy has joined #linux-sunxi
_massi_ has quit [Quit: Leaving]
earny has joined #linux-sunxi
foubarre has joined #linux-sunxi
shineworld has joined #linux-sunxi
<oliv3r>
vector80: the HWpack basically is a collection of bootloader; kernel, kernel moduels + mali modules even
<oliv3r>
vector80: learn to use it and appreciate it :)
<oliv3r>
vector80: you could, in theory, boot from SD; make partitions, format partitions, extract your OS image
<oliv3r>
vector80: then, extract the HWpack over it (e.g. installing the kernel and the modules and libraries (like opengl libs)
<oliv3r>
vector80: dd the bootloader that resides in the hwpack and you should have a bootable emmc
<oliv3r>
vector80: e.g. this is basically in layman terms what your master SD should be
wolfy has quit [Ping timeout: 252 seconds]
naobsd has quit [Ping timeout: 272 seconds]
Quarx has quit []
<quintin_>
Hello I am trying to compile my own kernel version 3.4.75 with the gmac module for ethernet on a cubieboard2 (a20). I think that I mess up the script.bin configuration which contain only the gmac par (not the emac). if I put only the gmac driver I don't see ethernet interface with eth0. If I put the emac I see the eth0 but I can't use it (https://www.google.fr/search?client=safari&rls=en&q=sunxi_gmac+cannot+register+as+MDIO+bus&ie=UTF-8
<quintin_>
soory for the link it was just sunxi_gmac cannot register as MDIO bus
ZetaNeta has joined #linux-sunxi
jemk has quit [Read error: Operation timed out]
JohnDoe_71Rus has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
foubarre has quit [Remote host closed the connection]
<oliv3r>
quintin_: i think 3.4 gmac's driver is limited to cubietruck; cb needs emac driver, but i could be wrong
<quintin_>
thus I have to change also my script.bin
<quintin_>
I though that was inside the a20 proc
shineworld has left #linux-sunxi ["Leaving"]
<quintin_>
thus the cubieboard2 should get it too
<quintin_>
thank for your answer
Gerwin_J has quit [Quit: Gerwin_J]
ZetaNeta has quit [Ping timeout: 246 seconds]
<quintin_>
ssh 192.168.1.87
<quintin_>
sorry it seems to work with emac
<quintin_>
thanks oliv3r
jemk has joined #linux-sunxi
<mnemoc>
oliv3r: ping
<n01>
anyone with jtag on cb2 here?
<oliv3r>
mnemoc: pong
<oliv3r>
n01: i haven't invested time into jtagging
<oliv3r>
quintin_: in theory, the gmac driver should work with cb2 and even better; but the driver doesn't talk to MII yet afaik
<oliv3r>
quintin_: its hardcoded to rgmii only
<oliv3r>
but don't quote me on that
<wens>
what?
jemk has quit [Ping timeout: 240 seconds]
<wens>
gmac in u-boot has proper support. gmac in sunxi-devel requires u-boot to setup mii/rgmii mode
<quintin_>
thanks for your time oliv3r
<libv>
i just got a "leliktec" A20 tablet
<libv>
"Super duolcore A20"
<libv>
yes, duol
<quintin_>
thus to get gmac working I should change my uboot?
<wens>
quintin_: yes. update to latest u-boot-sunxi
<libv>
k701hc seems to be the modelname
<libv>
will be taking pictures in a bit
<quintin_>
thanks good information I modify my kernel and script.bin but not the uboot
<quintin_>
the last time I have done it I got screw but at least I have now a working version with emac
<quintin_>
thanks to both of you for the information
<quintin_>
have a nice day
<wens>
what? it was 3.4?
<mnemoc>
oliv3r: would you mind look at amery's wip/sunxi-3.10/soc-detect and telling me if it's too ugly?
<wens>
quintin_: what I said refers to mainline kernel
<mnemoc>
oliv3r: it's for the legacy drivers
<quintin_>
wens I am on the 3.4.75 the last stable
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
<mnemoc>
oliv3r: just diff it against experimenta/sunxi-3.10
<oliv3r>
mnemoc: er ok let me pull
<wens>
quintin_: ignore what i said then :(
<oliv3r>
wens: we're talking 3.4 here :)
<oliv3r>
libv: super duol! still no a13?
<oliv3r>
libv: or where you after a20 hardware, i forgot
<libv>
it will take a few more days for the a13 to arrive
<libv>
but i stumbed over an a20 tablet as well
<oliv3r>
why tablets? cubietruck is a20 hardware?
<libv>
because LCDs are not the easiest things to implement properly
parabyte has joined #linux-sunxi
<libv>
hdmi is trivial, vga was tricky due to bad implementations
<oliv3r>
ah okay, very fair enough
<parabyte>
vga is easy
<libv>
LCD... well, that gets pretty nasty pretty quickly
<parabyte>
come on libv RGC analogue signals
<parabyte>
EASY
<libv>
parabyte: oh?
<oliv3r>
libv: yeah def.
<parabyte>
I like vga
<parabyte>
for electronics hacking reasons
<libv>
parabyte: what other signals are there on a vga connector?
<parabyte>
plus its easy to get vga out of anything
<libv>
parabyte: or is it only rgb?
<parabyte>
RGB and some other stuff
<oliv3r>
i2c
<libv>
oh. handwaving.
<oliv3r>
some sync
<libv>
yes, handwave enough and everything is easy
<parabyte>
you can generate an vga signal with any old DAC
<libv>
parabyte: there's h/vsync
<libv>
parabyte: which in our case ties the vga connectors that are implemented fully to the first CRTC
<libv>
parabyte: then there is the fact that all but the cubietruck implement DDC
<libv>
yet all ship with a blue connector, which signifies ddc
<parabyte>
i just like vga sometimes its handy :)
<libv>
parabyte: and then there is the little matter of load detection
<parabyte>
libv, i need to get in this century and ditch these vga displays in my workshop!
<libv>
with hdmi, you eiter have hdmi or you don't. you get hpd and i2c _always_
<parabyte>
new years resolution!
<libv>
parabyte: i have been developing graphics drivers for more than a decade
<libv>
parabyte: and i love CRTs
<parabyte>
me too :(
<libv>
parabyte: they show exactly what is going on
tomboy64 has quit [Ping timeout: 252 seconds]
<parabyte>
there is indeed that, i guess get with the times with hdmi
<libv>
and no, vga is not easy compared to the likes of hdmi
<oliv3r>
Turl: ! where are you when I need you!
<parabyte>
only recently ditched some legacy isa 8bit devices!
<libv>
electronically it is, but driver wise, it isn't
<parabyte>
i think its the olimex a20 board with the vga on board
<parabyte>
good stuff!
<parabyte>
lol
<libv>
parabyte: well, depends
<libv>
although, the cubietruck is the one with the vga wired
<libv>
i didn't think olimex came with vga connectors directly
tomboy64 has joined #linux-sunxi
<parabyte>
I do not think armel boards are strong enough for my needs yet
<parabyte>
!
<libv>
and the provided vga cables implement just the bare necessities
<parabyte>
give em a few more years and im sure they be good
<parabyte>
sorry i have to keep it short and sweet but my boss is on the hoover!
<tmonjalo_>
libv: You mean everybody is using HDMI ?
<libv>
and i was kind of hoping it stayed that way so i wouldn't need to bother implementing it on my kms driver :p
<tmonjalo_>
Oh :/
<libv>
tmonjalo_: let me dig around in disp again to see what can be done to make it more noisy
<tmonjalo_>
libv: ok thanks
<libv>
i have all the necessary hw to go and try this myself, but i have never done so
<libv>
tmonjalo_: can you paste the relevant sections of your .fex into pastebin as well?
pacopad_ has joined #linux-sunxi
<tmonjalo_>
Me too, I've never tried hard but today I am preparing new year's day for the children and was thinking about displaying a cartoon on the TV :)
<libv>
bad plan :)
<libv>
not something you tend to be able to fix in the space of a few minutes :)
pacopad has quit [Ping timeout: 248 seconds]
<libv>
tmonjalo_: first off, are you certain that you are properly connected to the TV's composite input?
<mnemoc>
I wonder what is that AC100 and the silver chip
lgentili has joined #linux-sunxi
<lgentili>
looks like a BT/Wifi chip
fredy has quit [Excess Flood]
<lgentili>
something with RF, that's why the shield
<HdkR>
The A80 has some Mali-T6xx thing in it right?
<mnemoc>
no one knows
fredy has joined #linux-sunxi
<HdkR>
hm
<mnemoc>
hopefully not a PVR
<HdkR>
"A80 packs a cutting-edge OpenGL ES 3.0 compliant, GPU compute optimized graphics processor" So t6xx or PVR6
<mnemoc>
hope for the first
<HdkR>
Guess we'll most likely find out at CES
<HdkR>
In the case that it is PVR6 it'll be interesting just because it is the first thing that actually will be released on the Android front with it. For anything beside that it is the worst thing of course
<lgentili>
memory from the picture is a 2Gbyte ddr3
Black_Horseman has joined #linux-sunxi
<lgentili>
Hope there is a eMMC at the bottom side and not only a uSD slot.
<mnemoc>
somehow it looks like the cubieboard.... hope cubietech managed to get involved
<lgentili>
The AC100 is an audio/amp companion chip I guess, there is a connector near, says HP (headphones??)
<mnemoc>
true
<lgentili>
I like the board... but the important thing here is...... that we want MALI inside!! :)
<mnemoc>
hopefully allwinner learned from the sgx544 mistake as samsung, and return to mali
<lgentili>
That's exactly my bet.
<lgentili>
Mali T6xx = OpenCL full profile with alot of new potential uses.
<lgentili>
Not only the open community support.
Xaros has joined #linux-sunxi
FDCX has joined #linux-sunxi
Black_Horseman has quit [Ping timeout: 245 seconds]
kz1 has quit [Ping timeout: 272 seconds]
Fangorn has quit [Read error: Connection reset by peer]
Fangorn has joined #linux-sunxi
penghb has quit [Ping timeout: 252 seconds]
penghb has joined #linux-sunxi
ZetaNeta has quit [Ping timeout: 252 seconds]
ZetaNeta has joined #linux-sunxi
Wizzup has joined #linux-sunxi
lgentili has quit [Quit: Page closed]
tomboy65 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 265 seconds]
tomboy64 has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 240 seconds]
slapin has quit [Ping timeout: 272 seconds]
slapin has joined #linux-sunxi
popolon has quit [Quit: Quitte]
<n01>
happy new year :)
<mnemoc>
happy 2014
<mrnuke>
why are you guys talking from the future?
<Wizzup>
yay \o/
tomboy64 has quit [Ping timeout: 272 seconds]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]