<libv>
now for a final (endless) mesa build, and testing ssvbs latest fbturbo
<WarheadsSE>
lol mnemoc
<mnemoc>
go libv go
<WarheadsSE>
I can try, but I'm not packaging that for distribution
<mnemoc>
WarheadsSE: just for testing obviusly
<WarheadsSE>
yeah
<WarheadsSE>
just looking at when I can move it to a "more" mainline channel from that tree
<WarheadsSE>
sata performance has been reasonable so far
<mnemoc>
3.10 is more mainline
<mnemoc>
but also stable-ish, and capable of adopting crap-drivers, and so.... been able to replace 3.4 sooner
<mnemoc>
sunxi-next is the mainline + accepted patches, maintained by mripard. and sunxi-devel is sunxi-next + experimental mainline drivers, maintained by Turl
<WarheadsSE>
feature comparable to the 3.3 tree I mentioned
<mnemoc>
only 3.4 then
<mnemoc>
yet
<mnemoc>
sunxi-3.10 "coming soon"
<WarheadsSE>
heh
<WarheadsSE>
Iam sure my users will like that
<WarheadsSE>
I know there are some systemd-nspawn issues with 3.3
<WarheadsSE>
annoying trying to use the CB2 as a builder
<popolon>
3.4 works fine
<mnemoc>
sunxi-v3.4.61-r1 pushed
<WarheadsSE>
it's a combination of systemd+cgroups+kernel
<WarheadsSE>
popolon: for the CB2?
<popolon>
at least the 3.4 from 1 or 2 month ago ~about october 5
<popolon>
WarheadsSE, yes
<popolon>
at least that's stable
<WarheadsSE>
for sun4i&sun5i I know
<popolon>
I tried 3.3 version, was never stable for me
<WarheadsSE>
stable for me, at the moment
<popolon>
I only have a cb2
<WarheadsSE>
but then I am using it as a headless node
<Tsvetan>
mnemoc maybe FEX entry CPU = A10/A10S/A13/A20... will be easier to implement
<Tsvetan>
instead to detect CPU
<Tsvetan>
as A10S and A13 have same ID
<mnemoc>
detecting CPU is merely reading a register
<mnemoc>
problem is to load the script.bin
<mnemoc>
there is no enough memory
<mnemoc>
but due to the internal structure of the .bin it is possible to load only the part where the properties of the section you want live
<mnemoc>
which may allow doing the reading and parsing in the mere 2k of memory we have left :<
hipboi has quit [Quit: Leaving]
Gerwin_J has joined #linux-sunxi
Black_Horseman has quit [Quit: Αποχώρησε]
<libv>
ssvb: works fine on precise
<hno>
mnemoc, you also need to account for the data, not only parsing.
<hno>
loading script.bin separately is not an option as you need those parameters to set up DRAM so we have anywhere to load stuff.
<hno>
Beleive me, using a header on the SPL is the most reasonable path forward.
<libv>
will be uploading the new fbturbo version later, after the mesa build is finished, so i can, at the same time, repackage for the other 2 ubuntu versions
<mnemoc>
hno: i was wondering about the rigidity of an struct header
<mnemoc>
hno: while on the .fex/.bin you have a dictionary which can be read by blocks
<mnemoc>
or a dedicated .fex/.bin 100% u-boot oriented, generated out of the other
<mnemoc>
making fexc generate a .bin to dd including only what u-boot-spl needs
<hno>
there is version fields to make sure the tool updating the header matches the code.
<mnemoc>
ok
<mnemoc>
have you decided the struct already? to teach fexc to dump it
<hno>
not 100%. Would also like it to feed info to main u-boot, but there is no such interface between SPL and main u-boot on ARM.
Soru has joined #linux-sunxi
<hno>
SPL as such needs very little info. Only what we have in boards.cfg + DRAM file.
<mnemoc>
u-boot can read the .dtb/.bin completely
<hno>
except some of the boards.cfg parameters is for main u-boot and not spl.
<hno>
true.
<mnemoc>
so it's only about DRAM info
<hno>
DRAM info and storage info.
<mnemoc>
but AXP and battery is out of scope for SPL?
<hno>
Right, AXP too.
<hno>
we haven't touched battery data at all yet.
<mnemoc>
so we have an binary struct with 3 parts...
<mnemoc>
that's why I thought a dictionary like fex/bin might scale better
<mnemoc>
you can add fields in future
<hno>
adding fields is not a problem even for a versioned struct.
<mnemoc>
ok
tinti has joined #linux-sunxi
tinti has quit [Max SendQ exceeded]
tinti has joined #linux-sunxi
ganbold_ has quit [Remote host closed the connection]
<mnemoc>
oliv3r: is 3.10 ready for a tag yet? to make an updated reference branch, and do a version jump....
<oliv3r>
er
<oliv3r>
i don't remember; and i'm kinda busy with $work these next few days
<oliv3r>
it worked for me iirc; but nobody has tested it yet
<mnemoc>
ok
<oliv3r>
actually i lie, someone in here recently tried it; but i don't know if he managed to get it to work
<mnemoc>
:)
<mnemoc>
arm-linux-gnueabi-ld: BFD (GNU Binutils for Ubuntu) 2.22 internal error, aborting at ../../bfd/reloc.c line 6298 in bfd_generic_get_relocated_section_contents
<mnemoc>
arm-linux-gnueabi-ld: Please report this bug.
<mnemoc>
aaaaarg.... hate those
<hramrach>
reproducible?
<mnemoc>
no
<hramrach>
then bad ram most likely
<mnemoc>
and they screw my "CI"
<hramrach>
does 3.10 support sun7i?
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
<mnemoc>
hramrach: it's supposed to support everythig mainline supports
<hramrach>
so should be bootable
<hramrach>
will give it a try
<hramrach>
what branch is useful for sunxi on mainline atm?
rodolfobc has joined #linux-sunxi
HeHoPMaJIeH has quit [Remote host closed the connection]
_massi_ has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
akaizen has quit [Read error: Connection reset by peer]
akaizen has joined #linux-sunxi
eebrah_ has joined #linux-sunxi
<mnemoc>
hramrach: sunxi-next or sunxi-devel are mainline
<mnemoc>
hramrach: the first with accepted patches, the second also including experimental ones
<mnemoc>
both upon 3.12
<mnemoc>
but including the sunxi stuff that will come in 3.13
<FR^2>
cubieboard2, linaro ubuntu desktop booted from sata drive (accessible via /dev/sda...), I'm trying to access the microSD card. What modules should I load in order to succeed? ushc seems to be one of them, but not enough. Any hints?
<hramrach>
it should be built-in
<hramrach>
othjerwise somethng like sunxi-mmc or mmc-sunxi
<FR^2>
I'll have a look, thanks.
<FR^2>
Hmm. kernel "3.4.61+", but no such thing. Well, then I'll install a new kernel from the pc.
<hramrach>
the driver is in drivers/mmc/sunxi-host and would be built into most kernels
<FR^2>
Ah! It's there, I overlooked it. it's been accessible via /dev/mmcblk0 (...p1) all the time! \o/
<libv>
FR^2: check /dev/mmcblk*
<libv>
right
<FR^2>
thanks
<hramrach>
why does mainline have no support for USB?
<hramrach>
the host port are EHCI which is a standard, rihgt?
<rodolfobc>
hi, i'm trying to use module g_ether, but i got a error message: no such device. The module was built from 3.4.61+. some clues?
<hramrach>
rodolfobc: build 3.4.43
<hramrach>
it does not work for me either
<hramrach>
but for me it loads, it just does nothing
<mnemoc>
libv: so our apt repo for ubuntu is actually usable now?
<hramrach>
any other error besides no such device?
<wens>
hramrach: USB support is in arokux's tree, afaik
<hramrach>
perhaps you forgot the controller?
<hramrach>
wens: I have sunxi tree
<hramrach>
where would I get USB support?
<rodolfobc>
hramrach: nops, dmesg shows nothing, module dont load
<mnemoc>
arokux2: fine, i only mean keep one branch for the hourlies in linux-sunxi
pirea has joined #linux-sunxi
<arokux2>
mnemoc: yep, I have only one.
<leviathanch>
mripard: uhm, when you allocate DMA memory and pass the virtual address to the MMC controller by writing it into the register it requires DMA support to get it back
<mnemoc>
arokux2: perfect. push it and give me the name
<leviathanch>
mripard: otherwise the MMC controller will write into digital nirvana
<mnemoc>
sunxi-devel-arokux? :p
<arokux2>
mnemoc: no! sunxi-next-usb
<arokux2>
but wait a sec, I'm pushing
<ccube>
that is what I am looking for!
<ccube>
libv, thanx :))
<mnemoc>
arokux2: ok
<libv>
can someone replace the "a1x" on the sunxi logo with "sunxi"?
<mnemoc>
where do I have that svg....
<libv>
:)
<oliv3r>
i wonder which pinmux is used for SPI-nor boot; the NAND ones or the Port-I ones ...
FunkyPenguin has quit [Read error: Connection reset by peer]
<popolon>
added the working config.gz, of my working version
<popolon>
of 5 october
<popolon>
I was really lucky, that was my first try with stage :)
<popolon>
the stable work for me too, but screen is not good (assuming I use hdmi->dvi converter)
<Turl>
arokux2: sunxi-next only contains merged patches, not everything sent
<Turl>
(that's kind of the point why sunxi-devel exists)
<arokux2>
Turl: I know, but what happened to that patches, will they lend in 3.13?
<Turl>
arokux2: which ones?
<arokux2>
Turl: PLL6 related
<Turl>
arokux2: maxime sends a lot of them for stuff he himself is the maintainer, so he then just says he picked his own patch and sends a pull req at the end of the cycle
<arokux2>
Turl: ah, right, forgot to check there.
<Turl>
arokux2: I haven't heard anything from mike yet...
<arokux2>
Turl: nobody is interested in sunxi except of us :)
n01 has quit [Ping timeout: 256 seconds]
<Turl>
arokux2: it's not that, but he hasn't practically merged any clk patches since last cycle
<Turl>
arokux2: why don't you start sending the USB driver itself if it's ready though?
<arokux2>
Turl: I'm still working on it.
<Turl>
the driver itself is independent and won't fail to build or anything if you don't have the needed clocks, and the dt nodes can be added later when everything is in place
<Turl>
ok :)
<arokux2>
Turl: I've decided postpone my other hacking and just finish USB, now that I know everything that is needed.
<Turl>
I should really send a v2 of the pll stuff, I think I already addressed all of mripard's comments on my local tree
Black_Horseman has quit [Quit: Αποχώρησε]
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
mcbrick has quit [Ping timeout: 272 seconds]
pirea has joined #linux-sunxi
mcbrick has joined #linux-sunxi
torindel has quit [Ping timeout: 260 seconds]
torindel has joined #linux-sunxi
jinzo has quit [Quit: Leaving]
tinti has quit [Remote host closed the connection]