<MoeIcenowy>
for H5, it seems that the boot0 is dumb...
leviathanch has joined #linux-sunxi
IgorPec has joined #linux-sunxi
lkcl has quit [Ping timeout: 250 seconds]
<ssvb>
wens: it would be funny if somebody starts harassing Nintendo about GPL compliance
jernej has joined #linux-sunxi
reinforce has joined #linux-sunxi
<wens>
ssvb: oops :p
<ssvb>
apritzel: looks like my Orange Pi PC 2 board is arriving today in the evening, and DHL was nice enough to ask for a convenient delivery time interval via SMS
<MoeIcenowy>
apritzel: but we still have no U-Boot...
<apritzel>
MoeIcenowy: true, but I left this as an exercise to the reader ;-)
<apritzel>
(low hanging fruits first)
<MoeIcenowy>
OK I got a "How to port to newer Allwinner chips" book from Apritzel Press :-)
gianMOD has quit [Remote host closed the connection]
<apritzel>
MoeIcenowy: I guess it's a bit nasty, because we have to mix MACH_SUN50I and MACH_H3 now
<MoeIcenowy>
we need a MACH_SUN50I_A64 and a MACH_SUN50I_H3
<NiteHawk>
tkaiser: I'd still like to compare them (simply from a scientific/"fexc"-oriented point of view). can you provide the .fex and the .bin from the boot partition somewhere?
<apritzel>
or rather sort out the ARMv8 stuff from the peripheral defines and use different symbols
<MoeIcenowy>
we should have thought that if allwinner used sun50iw1, then will come w2 and so on
<MoeIcenowy>
s/50I_H3/50I_H5/g
<apritzel>
MoeIcenowy: I guess it would be smarter to some kind of SUNXI_64 define to cover all things that relate to armv8 and 64-bit stuff
<wens>
hmm... who was doing the sunxi-boards merges before?
<MoeIcenowy>
apritzel: it can be MACH_SUN50I
<apritzel>
now this weird naming scheme bites us, I think
gianMOD has joined #linux-sunxi
<apritzel>
relating to AW's scheme you are right
<apritzel>
because 50I means A53 cores
<apritzel>
but there is also the A64 clocks and pins, which are somewhat SUN50I (shared between A64/H64 and what's still there to come)
<KotCzarny>
tkaiser: what was the cause of previous transfer corruption?
<tkaiser>
NiteHawk: Please be aware that script.bin obviously has been generated from a differing sys_config.fex file (pmu_level1 is wrong)
<apritzel>
MoeIcenowy: also should AW ever take different 64-bit cores (A57, A72, A35, ...) we start #ifdef mayhem again
<tkaiser>
KotCzarny: I don
<tkaiser>
't care since the contents is crap anyway
<MoeIcenowy>
good question...
<MoeIcenowy>
but they seems to care only 8i and 50i now
<wens>
apritzel: not sure how you can use #ifdef in the kernel if the kernel is supposed to be generic?
<MoeIcenowy>
wens: in kernel, of course, no
<MoeIcenowy>
but in u-boot, yes
<wens>
oh ok
<NiteHawk>
KotCzarny: presumably UART issues and/or character encoding troubles when dumping the .fex over serial
<MoeIcenowy>
but I seems to found some problems on the boot0 in h5 lichee
<MoeIcenowy>
will try to pheonix a card to test
<tkaiser>
NiteHawk: The 'value' of these vendor generated fex files is questionable. It seems Xunlong pays one or two guys now doing software stuff but obviously they have no idea how dvfs with Xunlong hardware works.
fkluknav has joined #linux-sunxi
<NiteHawk>
tkaiser: I'm just curious whether my experimental .fex test (tools) work/s with those files, especially the 'unify-fex' normalization. In theory you coud then diff the actual .bin contents against the .fex and fix any differences to get a sane(r) .fex
<apritzel>
wens: hell yes, I was talking about U-ifdef-boot, not the kernel
<wens>
:)
<tkaiser>
NiteHawk: ok then. But from time to time discussions here indicate that these original fex settings would be manufacturer's will. In this case it's obvious that somebody fiddled around who has no idea how voltage regulation on this board works. And that makes the whole file contents questionable.
<MoeIcenowy>
U-ifdef-boot ;-) hahahahahahahaha
enrico__ has joined #linux-sunxi
<NiteHawk>
tkaiser: what's the more correct setting in this specific case then? the one from the .fex, the .bin or neither of them?
<KotCzarny>
neither
<KotCzarny>
;)
<NiteHawk>
great. :D
<KotCzarny>
value of data: linux-sunxi > allwinner > vendors
<tkaiser>
NiteHawk: It's really neither, the person fiddling around with the settings doesn't understand how two state switching between 1.1V and 1.3V works. With their settings it's all the time 1.3V. And since they obiously realized that the board with these settings gets quite hot, they then limit max cpufreq to 1008 MHz. With sane settings you can allow 1200 MHz and get ~25¡C less idle temperatures.
<apritzel>
wens: MoeIcenowy: I was thinking about merging at least H5 and A64 in U-Boot, but that sounds like a bigger effort
<apritzel>
maybe it's worth investigate it just for the SPL
<apritzel>
because we can choose a different U-Boot proper with FIT support (I think)
<apritzel>
and the SPL seems to cut corner for pinmux setup and stuff anyway
<apritzel>
*corners
<MoeIcenowy>
apritzel: you mean kill #ifdef's?
<apritzel>
MoeIcenowy: I guess yes
<apritzel>
replace it with SoCID based detection
<apritzel>
but I expect some opposition
<MoeIcenowy>
but the SPL is size-limited by BROM...
<tkaiser>
NiteHawk: BTW: Since we deal with H3 devices with just 2 DVFS operating points none of the hardware manufacturers provided correct settings for this setup. No OS image from Xunlong ever worked correctly on Orange Pi One, Lite or now Zero and it would be the same with all FriendlyARM boards too (but since they allow to open issues on Github we were able to teach them: https://github.com/friendlyarm/h3_lichee/issues/2 )
<MoeIcenowy>
make it general is not a good idea
<apritzel>
MoeIcenowy: true, but I hope that it's not much that we loose (unless we have completely different DRAM init routines)
<wens>
naobsd: u-boot and boot0 blobs have a header section, where some parameters get written too
<MoeIcenowy>
naobsd: nope it's not enough.
<MoeIcenowy>
on A33
<naobsd>
oops
<naobsd>
what's required for A33?
<MoeIcenowy>
naobsd: a Pheonix image or a interactive shell under BSP
<naobsd>
shell under BSP? root shell on console?
<MoeIcenowy>
yes.
<naobsd>
I guess shell is not running on console... I have to solder TX/RX pad (not yet for now)
<MoeIcenowy>
I think we have now a proper driver to support NAND in A33 mainline kernel
<MoeIcenowy>
but mainline kernel NAND drivers is different to BSPs'
<MoeIcenowy>
so it's no use
<naobsd>
there is no network/external storage on NES classic. if update image will be available in future, it will be flashable image via OTG (just my guessing)
Putti has quit [Ping timeout: 256 seconds]
solarnetone has quit [Remote host closed the connection]
<naobsd>
is there any way to run or flash costomized _Allwinner_ kernel via fel mode?
gianMOD has quit [Remote host closed the connection]
<MoeIcenowy>
you can try to execute the "FES" file
<MoeIcenowy>
which can be found in A33 lichee
gianMOD has joined #linux-sunxi
<MoeIcenowy>
then you need a different protocol
<KotCzarny>
in a way, blocking any way of fiddling lower the number of 'broken' returns ;)
<beeble>
.gitignore file but .BAK files in the zip
<rellla>
KotCzarny: yeah, but i'm not very up-to-date on mali kernel driver and blobs ...
<MoeIcenowy>
rellla: I think it should be marked as "WIP"
<MoeIcenowy>
as the necessary patches has not entered 4.9-rc
<rellla>
and G2D is only available in A10/13/20 iirc. and no work has started, so it remains a dead column most likely
fkluknav has quit [Ping timeout: 260 seconds]
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
<rellla>
MoeIcenowy: mali? and on which SoCs?
<MoeIcenowy>
it's mostly about sun4i-drm
<MoeIcenowy>
A13, A33 can now work, and both tested by mripard
<KotCzarny>
rellla: you might leave it 'unknown'
<MoeIcenowy>
I also tested A33 GPU
<MoeIcenowy>
"work" means after merging necessary patches
DullTube has joined #linux-sunxi
<MoeIcenowy>
and mali dt work will never enter mainline
<MoeIcenowy>
but the it can be provided as dt overlay, come with mali kernel driver
<miasma>
i wonder how the original designers of mali feel about the status and lack of drivers. iirc a friend of a friend in norway was one of the designers
fkluknav has joined #linux-sunxi
<naobsd>
hehe. Nintendo Classic Mini was released today @JP, I bought it on the way of home -> work
<naobsd>
I had to play "find FEL!" game at work place :)
<naobsd>
then I disassembled it for "find UART!" game. but I had no time to reassemble it, I couldn't bright it to home ;)
<tkaiser>
naobsd: Is OTG exposed externally or do you have to open the box?
<naobsd>
OTG is exposed. near to HDMI. JP model and US?WW? model is different form, but USB/HDMI interface should be same
<naobsd>
please check official info
<naobsd>
btw I don't know any other game except "find FEL/UART!" yet :)
<naobsd>
it seems controller interface is i2c. I don't know detail but someone said it should be same as Wii classic controller
<naobsd>
so available interface should be: OTG HDMI(via bridge) UART and I2C
<beeble>
the controller interface is i2c. at least from the sourcedrop
<beeble>
MODULE_DESCRIPTION("Nintendo Clover/Wii Classic/Wii Pro controllers on I2C");
<naobsd>
ah yes clovercon
<naobsd>
is mainline u-boot can be flashed on NAND?
<rellla>
MoeIcenowy, KotCzarny: so we don't add mali to the matrix, as it won't be able to be mainlined?
<naobsd>
well, if otg host mode is supported on u-boot, "support NAND _on u-boot_" might not be needed
<naobsd>
what I though is "using fel mode _everytime_" is not so handy...
<naobsd>
thought
<naobsd>
(reading wiki again...)
* deskwizard
bows down
<deskwizard>
Just wanted to say thanks for all the work you guys put in, greatly appreciated
<tkaiser>
naobsd: It should work since NextThing is doing exactly this on their CHIP
<tkaiser>
naobsd: Also the Link to Olimex' github repo before was there for a reason, they have an A33 board with NAND and combine mainline u-boot with smelly 3.4 kernel
gianMOD has quit [Remote host closed the connection]
* MoeIcenowy
will try to measure the size of H2+ and compare with H3
gianMOD has joined #linux-sunxi
<wens>
MoeIcenowy: actually the number of pins is what matters
<wens>
if they don't match, you almost certainly need a new driver
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
<MoeIcenowy>
I think they may be pin compatible, as they do not have any external difference
<MoeIcenowy>
only difference on VPU and EMAC
f2zubac has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 264 seconds]
<MoeIcenowy>
As I know, we cannot differ H3 with H2+ with SoC ID
<MoeIcenowy>
but can with SID
<tkaiser>
wens: MoeIcenowy: just as info, the 'legacy' Armbian image I'm currently testing with is based on an older lichee drop (found in FriendlyARM github repo back in May). So we don't use the 'H2 SDK' at all but H3 BSP sources and everything works (3.4.113)
<MoeIcenowy>
wens: I think we can at first create a sun8i-h2-plus.dtsi, which contains only #include "sun8i-h3.dtsi"
<MoeIcenowy>
and whenever we find anything different
<tkaiser>
NiteHawk: sunxi-fel sid --> 'Warning: no 'soc_sram_info' data for your SoC (id=1718)\nSID registers for your SoC (id=0000) are unknown or inaccessible.'
<MoeIcenowy>
tkaiser: I added some basical support of H5
<mripard>
wens: yep, looks good
<MoeIcenowy>
but SID seems to be not same as A64
<MoeIcenowy>
my sram info can make uart0-helloworld boot via fel
<MoeIcenowy>
tkaiser: if you want I can push to my github
<tkaiser>
MoeIcenowy: Thanks, I'll put OPi PC 2 back into drawer now. Too much other stuff :)
<MoeIcenowy>
tkaiser: on github.com/Icenowy/sunxi-tools branch h5
* NiteHawk
leaves lurking in the shadows mode and takes a look
<wens>
mripard: will test and send it out tomorrow
mhlavink has quit [Ping timeout: 260 seconds]
<NiteHawk>
MoeIcenowy: were you able to transfer/run boot0 over FEL, or did your experiments stop at uart0_helloworld?
IgorPec has joined #linux-sunxi
<MoeIcenowy>
NiteHawk: the Boot0 seems to be a dumb guy
<MoeIcenowy>
I cannot get it to speak anything
lkcl has quit [Ping timeout: 256 seconds]
<kido>
wens: yep I'm still around, just busy with other projects and stuff :)
mhlavink has joined #linux-sunxi
lamer14787928329 has joined #linux-sunxi
<apritzel>
MoeIcenowy: NiteHawk: given the close relationship to the H3, can anyone try to run just a H3 SPL on it (via FEL)
tkaiser has quit [Ping timeout: 250 seconds]
<MoeIcenowy>
apritzel: I failed.
<NiteHawk>
i have probably missed it if posted before - is there an H5 datasheet around yet?
* f2zubac
anybody has an idea ?
<mripard>
kido: traitor ! :)
<apritzel>
NiteHawk: yes, on the Opi PC 2 wiki page
<NiteHawk>
ah, cool. thx
<apritzel>
NiteHawk: it's just a datasheet, though
<apritzel>
(few dozen pages compared to the multiple hundred on a "user manual")
<apritzel>
NiteHawk: I compared the pins yesterday - one by one
<NiteHawk>
does it show memory mapping?
<apritzel>
no
<NiteHawk>
:P
<apritzel>
but as the H5 is pin compatible to the H3, I guess it's just the H3 memory map
<apritzel>
only difference is the A64 MMC controller
<apritzel>
and VCC_PC on the H5, which is VCC_PA on the H3
<apritzel>
to allow driving SDMMC2 with 1.8V for eMMC 5.x
<NiteHawk>
MoeIcenowy: might be worth giving it a try with a10_a13_a20_sram_swap_buffers then?
reinforce has joined #linux-sunxi
<apritzel>
MoeIcenowy: NiteHawk: just wanted to say the same
<apritzel>
forget A64, make it look like a H3 everywhere
<MoeIcenowy>
wens, tkaiser: tested a mainline kernel image on H2+
<MoeIcenowy>
(orange pi one's
<MoeIcenowy>
even EMAC is drivern at first
Nacho has quit [Ping timeout: 256 seconds]
<kido>
:)
Nacho has joined #linux-sunxi
<apritzel>
MoeIcenowy: the SRAM location is different between H3 and A64, so you cannot reuse that code in sunxi-fel
<MoeIcenowy>
jernej: your H3 HDMI driver cannot work at all here
<jernej>
tkaiser: if you consider it useful, I could also produce appropriate dt patch
<MoeIcenowy>
after enable CONFIG_VIDEO, the U-Boot stucks
<MoeIcenowy>
either without a screen or with my 1024x600 special screen
<plm>
I would like to do a single board with a top allwinner, justo for server, with large menmory and cache L1/L2. With just a 1GB ethernet, not other interface - to ue on servers, cheap servers
<plm>
ssvb: ^
<plm>
ssvb: like as a A73
<MoeIcenowy>
"top allwinner" is a joke.
<jernej>
MoeIcenowy: Ok, good to know. jemk reminded me yesterday that clocks are not set properly
<MoeIcenowy>
AW is A{7,52}W
<jemk>
jernej: nice finding, looks like the bing-magic really unscrambles the addresses
<MoeIcenowy>
s/52/53/g
<jemk>
that means its much easier now to reuse existing mainline driver
<jernej>
MoeIcenowy: I have possible solution in the work
<MoeIcenowy>
jernej: could you please tell me? ;-)
<jernej>
jemk: Really? I tried on 3 random registers and it didn't work... Where did you put it?
<tkaiser>
jernej: I think would both be useful.
<MoeIcenowy>
and I wanna test it on my A64
<jernej>
MoeIcenowy: About clocks? Better read yesterday irc log.
<MoeIcenowy>
after success on H3
<MoeIcenowy>
"yesterday" in which TZ?
my123_ is now known as my123
<jernej>
oh, sorry, UTC +1
<jemk>
jernej: i just tried manually in u-boot and dumped the registers, they were in correct order
<MoeIcenowy>
jernej: thanks
<tkaiser>
jernej: But on the other hand it's not urgent at all since we use the green led in early boot and here all H3/H2+ devices still use identical pin mapping
<jernej>
tkaiser: Well, dt needs to be added sooner or later
<plm>
MoeIcenowy: why joke?
<MoeIcenowy>
plm: allwinner now do not focus on high-performance
<MoeIcenowy>
they failed on A80
<jernej>
I wonder why LED is not lit by U-Boot by default
<jernej>
jemk: Are we allowed to use magic numbers from binary blobs in mainline? Did you try all registers?
<plm>
MoeIcenowy: why alleinner not focus in high-performance? And, What mean? "they failed on A80"?
<MoeIcenowy>
High-performance means high-price
<MoeIcenowy>
they're trying to save every yuan
<jernej>
MoeIcenowy: Long story short, datasheet sometimes tells only half of the story, in this case, for HDMI clock settings
<MoeIcenowy>
jernej: do you have fixed code?
<jemk>
jernej: ianal, but i don't think they can have a copyright on magic numbers. and no, i only did a quick comparision, it should be verified again
mripard has quit [Quit: leaving]
<jernej>
MoeIcenowy: Not yet, probably today. But it will be just a guess, what might work. And it will probably work, but we can't be really sure until docs are out.
<miasma>
plm: well it looks like the allwinner chips are primarily designed for set top boxes and tablets. it doesn't make sense to do number crunching there atm
<jernej>
MoeIcenowy: I'm waiting for 1360x768 screen, on which I will test different theories, as it should represent something not supported by original HDMI driver
<Wizzup>
miasma: they work fine as general servers and computers
<jernej>
MoeIcenowy: so probably more next week
<MoeIcenowy>
jernej: you can give me the code to test
<MoeIcenowy>
1024x600 screen is a more weird thing :-)(
<jernej>
ok, I will let you know once I commit the code
<miasma>
Wizzup: yes, but it depends. sometimes you want more power
<plm>
miasma: what mean "crunching there atm"?
<plm>
*menas
<plm>
*means
<miasma>
Wizzup: i use opi pc as a server at home :) but i have another server for a ~15 TB zfs array :)
<miasma>
plm: you probably know intel xeons or ibm power series?
<jernej>
MoeIcenowy: in the mean time, can you test it on something more standard, like 720p or 1080p?
<plm>
miasma: yes
<apritzel>
plm: long story short: AW SoCs are not overly reliable, lack DRAM throughput, have abysmal I/O performance and limited memory support
<MoeIcenowy>
no... I have no such a monitor
<apritzel>
plm: this reads like a no-go list for servers to me
<miasma>
plm: a 1.2 Ghz ARM isn't exactly the same as a 10 core 4 Ghz machine with 128 GB of ram
<apritzel>
plm: even if you can live with limited performance, you still have reliability issues and the I/O problem
<apritzel>
plm: keep in mind that a server is more than some "random computer without a monitor" ;-)
<Wizzup>
isn't the reliability issue only when clocking on the wrong speed?
<plm>
miasma: But many use cases are just to rum simple tasks, like as tthp pages, email, samba, webservers, etc where a quad core 2GHZ with 4GB is very good
<Wizzup>
I have allwinners running for 2 years+, stable
<plm>
apritzel: ^
<apritzel>
Oh right, so that qualifies as a server, then
<apritzel>
one report
<plm>
apritzel: understand me? So, this space of the market are there so many needs
<apritzel>
still AW chips are not the right choice
<plm>
apritzel: and the processor dont need GPU, just CPU, so will be cheaper. Are there a ARM without GPU?
<miasma>
plm: i couldn't figure out what kind of requirements you have and what kind of answers you're seeking. for me, it's easier to imagine some task, do the math and pick a good hardware for that. i can find lots of uses for allwinner boards and I'm not even interested if they have the best specs or support for all possible tasks
<apritzel>
a server is something you want to rely on
<apritzel>
who gives you this guarantee for an AW chip?
<plm>
apritzel: of couse. I have a pi2 running has server ~2 years.
<apritzel>
plm: sure there are, there are ARM chips for everything you want
pzw has joined #linux-sunxi
fl_0 has quit [Quit: STRG + Q]
<MoeIcenowy>
Allwinner is for someone lack of money
mripard has joined #linux-sunxi
<plm>
apritzel: Are you talking about that AW is not stable SoC?
<apritzel>
plm: but they are not sold as servers, you just use them as such
<MoeIcenowy>
such as me ;-)
mzki has quit [Quit: leaving]
<apritzel>
plm: ask tkaiser, who is exposes to a large installation base of AW boards
<apritzel>
it works for _most_ of them, but many report of issues here and there
<apritzel>
crashes under higher ambient temperatures
<apritzel>
or with suboptimal power supply
<plm>
are there any ARM SoC dedicated for servers?
<plm>
MoeIcenowy: an, k1 and x1 is not for servers as CPU
<plm>
that has CPU and a BIG GPU cores
<plm>
I mean just CPU
<miasma>
plm: i guess if you only consider < $120 boards, allwinner boards from xunlong might have the best perf/dollar. but i haven't benchmarked the GPUs
<MoeIcenowy>
If you pay the price of Allwinner boards, you can get only allwinner boards or equal choices
<plm>
MoeIcenowy: yes, cheaper, but withour performance.
<MoeIcenowy>
compared to the price the perf is acceptable
<plm>
but, are there a difference between "cheap and poor performance" and "cheap and poor performance and unstable"
<plm>
what they ^ is the AW?
<MoeIcenowy>
without us linux-sunxi it's the latter
<MoeIcenowy>
with us it's the former
<plm>
apritzel: watching about that kickstarter like - very good
<apritzel>
marvell is known for doing I/O well, because they focus on such applications (mostly NAS)
<plm>
MoeIcenowy: sorry, who us the "us"?
<plm>
MoeIcenowy: sorry, who is the "us"?
<MoeIcenowy>
linux-sunxi
<plm>
ahh ok
<plm>
So, the hardware is stable
<MoeIcenowy>
but you get sh*tty vendors
<plm>
MoeIcenowy: vendors sells always the same AW SoC.
<plm>
MoeIcenowy: are you talking about "fake" AW SoC?
<MoeIcenowy>
I mean board vendors
<plm>
ahh ok
<MoeIcenowy>
such as Xunlong
<plm>
but Xunlong is the same of ORANGE PI
<plm>
so, Xunlong is a good vendors, right?
<Wizzup>
19:58 < apritzel> or with dodgy SD cards
<Wizzup>
That is not AW fault
<MoeIcenowy>
not good
<MoeIcenowy>
only cheap
<apritzel>
Wizzup: didn't say, but that's the storage to go with, unfortunately
<Wizzup>
apritzel: we're moving away from sd cards
<Wizzup>
because they are indeed, unstable
<longsleep>
apritzel: hey, does your a64 kernel branch boot on h5?
<Wizzup>
we're going to play with u-boot on NOR flash and storage on ssd/hdd on sata
<apritzel>
longsleep: haven't tried yet, but I pushed some preliminary DT and config bits yesterday
<plm>
MoeIcenowy: why Xunlong is not a goof verdors? Do you think the orange pi boards are not good hardware?
<MoeIcenowy>
longsleep: I cannot even make the board say "HELLO! Boot0 is running!"...
<longsleep>
MoeIcenowy: oh
<apritzel>
MoeIcenowy: boot0 is soo yesterday ;-)
<longsleep>
MoeIcenowy: does it light some led for you when you add power?
<longsleep>
apritzel: great, i want to play around with this a bit on the weekend
<MoeIcenowy>
longsleep: no
<MoeIcenowy>
but I'm sure the power is on as I can enter fel
<apritzel>
longsleep: ssvb is on it as we speak, apparently there is some output with FEL
<apritzel>
longsleep: problem is there is no manual yet, just a datasheet
<MoeIcenowy>
I have a modified UART0 helloworld in sunxi-tool that can say something
<MoeIcenowy>
which makes me believe I didn't get a brick
<NiteHawk>
datasheet ...which is lacking/incomplete
<longsleep>
right, i am wondering how far this board is away from doing something useful
<apritzel>
longsleep: and it turns out to be a weird chimera between the H3 and the A64
<apritzel>
longsleep: it seems to be closer to the H3 than the A64
<longsleep>
apritzel: yeah, i just went through this channel backlog
chomwitt has joined #linux-sunxi
<apritzel>
I am pretty confident we get something running quite quickly
<beeble>
i would have hoped that someone would say that there some vendors out there that are a little bit less crappy :)
<apritzel>
plm: there is some Austrian company, though ....
<apritzel>
beeble: like this?
<beeble>
thanks! :)
<plm>
beeble: ?
<apritzel>
beeble: also found some competition today in that other Alps country ...
<beeble>
as a board level designer i appreciate that
<longsleep>
apritzel: i want to look into making ubuntu snappy now that its been officially released, so either the h5 based one or the h2 one, preferably both
<beeble>
apritzel: sounds interesting, i like competition
<tkaiser>
plm: In my opinion Xunlong does a pretty good job at designing hardware but totally sucks when it's about software. So without this community they would sell simply paperweights. But their target audience are people who get excited to buy whole computers for less than $5 (that was the first reaction on OPi Zero -- too expensive)
<apritzel>
beeble: like actually quite similar: SoM, A64, eMMC ...
enrico__ has quit [Quit: Bye]
<apritzel>
*looks
<beeble>
plm: i'm working for one. so i hope don't suck too much
<longsleep>
tkaiser: i like the design of the OPi Zero pretty much
<beeble>
apritzel: standard formfactor or proprietary?
<plm>
beeble: what's the name?
<tkaiser>
plm: Theobroma
<tkaiser>
longsleep: Me too, especially the PoE option is great. I hope Xunlong will start to solder the SPI flash by default if we poke 'them' a bit
<longsleep>
tkaiser: yes that would be awesome, do they still ship this stuff with kernel 3.4?
<plm>
beeble: wow, are you using A80 AW
<plm>
octa-core
<plm>
well, I see that AllWinner are in many vendors
<tkaiser>
longsleep: Sure, ignoring everything that has happened the last years. They even provide OS images with shitty 3.4.39 kernel featuring the annoying kswapd0 bug. So with Xunlong's Lubuntu image my OPi Zero ran with up to 73¡C starting to kill CPU cores
<longsleep>
tkaiser: yes, just saw your post in armbian forum
<tkaiser>
longsleep: The sun8i BSP kernel is regarding ths setting the same crap as 3.10.65 was
<longsleep>
tkaiser: the OPi Zero armbian image uses Kernel 3.4?
<ssvb>
beeble: are a80 chips still being manufactured? I thought that it was EoL since a long time ago
<longsleep>
Does the H5 OPi PC2 have a RTC?
<tkaiser>
longsleep: 3.4.113 currently. But I tested also megi's H3 THS branch (4.7) which works also flawlessly except of WiFi
<MoeIcenowy>
several days ago I have heard that A80 has EoL very fastly from some BPi guy
<tkaiser>
longsleep: Just look in the H5 user manual ;)
<longsleep>
tkaiser: oh nice, 3.4 is too old for everything but 4.7 sounds good
<MoeIcenowy>
tkaiser: no such thing
<beeble>
ssvb: there is some stock, it is NRND and as always allwinner tells you sometimes you can get it with a very high MOQ
<tkaiser>
longsleep: 4.9 also works but I'm too dumb to get megi's ths patches to work with more recent versions. And since OPi Zero overheats a little more than the larger Oranges better save than sorry
<longsleep>
tkaiser: there is none yet i understand, but also i do not see a battery or battery connector on the board
<beeble>
so yes, pretty much EOL
<apritzel>
MoeIcenowy: the datasheet lists RTC pins on the SoC, the board is just lacking a separate battery connector
<tkaiser>
longsleep: Yes, I was kidding. Also H5 has no PMIC support so no battery connector. But I2C RTC add-ons with own battery connector will work for sure
<beeble>
ssvb: it was the fasted move from release to we don't want to sell any more i have seen
<longsleep>
apritzel: what u-boot should be used to try to boot the H5 with your Kernel tree?
<apritzel>
longsleep: the one that needs still to be hacked
<jernej>
MoeIcenowy: I pushed new experimental code to github. Please also report U-Boot output (it is mirrored to UART)
<apritzel>
longsleep: by combining some bits from the A64 with other bits from the H3
<longsleep>
apritzel: ok, but the base is mainline u-boot?
<MoeIcenowy>
jernej: will try it several hrs later
<MoeIcenowy>
time for bed
<apritzel>
longsleep: just to make sure: those commits are purely theoretical, based on the assumption that the H5 is very close to the H3
<MoeIcenowy>
too sleepy now.
<longsleep>
apritzel: yes understood
<jernej>
MoeIcenowy: no problem. I read IRC log
<apritzel>
longsleep: but yes, mainline U-Boot should be pretty easy
<apritzel>
longsleep: AFAIK there are no images for the H5/OPi PC 2 (yet?)
<tkaiser>
apritzel: One Android image exists
<longsleep>
apritzel: mhm i just downloaded some android image sun8iw7p1_android_dolphin-p1_uart0._PCPlus.rar
* apritzel
doesn't care anyway ;-)
massi has quit [Remote host closed the connection]
<longsleep>
apritzel: going to give this a shot now to confirm that the thing actually can boot
<tkaiser>
longsleep: The name sounds wrong
<longsleep>
tkaiser: yes, but its what is linked at Android For Orange Pi Pc 2
<jernej>
tkaiser: longsleep: IIRC someone said that googledrive image is wrong and correct is on baidu
<longsleep>
ah
<longsleep>
makes sense
<miasma>
beeble: can i order boards with a discount here :)
<tkaiser>
longsleep: And most probably you need a real pile of crap to burn the Android image: PhoenixSuit
<miasma>
beeble: i'm not sure if i need/can afford. i'm more into rpi style hacker boards
<longsleep>
tkaiser: yeah sure, but i got that
<miasma>
beeble: do you do stuff for automotive?
<longsleep>
tkaiser: the SDK is pretty much useless though as its Kernel 3.4, but for u-boot it might be interesting
<longsleep>
tkaiser: oh the H5 sdk contains Kernel 3.10?
<beeble>
miasma: i understand, we focus on a other market. but having something for developers with most interfaces exposed is something that we try to achieve
<tkaiser>
longsleep: H5-SDK/lichee/linux-3.10
<longsleep>
tkaiser: well thats enough to make something useful out of it if it should turn out to be a long shot to get mainline running properly
<beeble>
miasma: mostly industrial stuff, some "consumer" like stuff with a industrial background, like home automation
<tkaiser>
longsleep: Sure, I already applied all those patches up to 3.10.104 (?) as with A64 BSP kernel. Looked good.
f0xx has quit [Ping timeout: 244 seconds]
<beeble>
and networking stuff. CPE as a buzzword
<longsleep>
tkaiser: but not the apparmor3 stuff i got for pine64 i assume?
<apritzel>
beeble: how is the eMMC going for you? on a mainline kernel?
<miasma>
beeble: 64-bit CPUs for home automation :S
<tkaiser>
longsleep: I used Mikhail's original set of patches and just looked whether they more or less apply or fail. Just a few warnings IIRC
<beeble>
miasma: that is done mostly on bespoke designs not with allwinner stuff
<beeble>
old designs with arm9 and cortex-a8
<beeble>
apritzel: on a64 not sure atm, on a31 and a80 fine
<longsleep>
tkaiser: do you know which u-boot they use of the two in the sdk?
<longsleep>
tkaiser: ah if the readme is correct then the 2014.07
<tkaiser>
longsleep: I would assume the 2014 one as with Pine64. The 2011.09 thingie is combined with 3.4.x all the time
<miasma>
beeble: ok :) my friend just built a house and the interface for heating and lightning in the wall looks really crappy. i guess even underclocked rpi 1 could run it :)
<beeble>
apritzel: busy with new designs, so i have been not in touch with the software guys lately
pzw has quit [Quit: pzw]
<beeble>
miasma: you don't need a lot to do it anyway if you are not crazy and doing it with osgi
<apritzel>
beeble: thanks, I got a bit closer and have some more clues (thanks to mripard)
<beeble>
apritzel: but i will check to see how the guys are doing. not even sure what ip they are using this time
<miasma>
beeble: i can imagine that, but i don't know about the software stack
<beeble>
apritzel: only thing i was looking into was to enable higher speeds in the next revision. currently i#m stuck to 3.3v i/o because of compatiblity reasons
<beeble>
would have to add some level translators because of the low pin count of the a64
<beeble>
but i think thats a cost adder i'm willing to take for faster io
<apritzel>
beeble: but the SoC provides everything for driving PortC separately (with 1.8V, for instance), doesn't it?
<beeble>
yes, but portc has also the only spi controller i can use
<beeble>
and this has to be 3.3v for q7
<apritzel>
beeble: for the boot SPI?
<beeble>
apritzel: yes
<beeble>
but i can work around that
<apritzel>
there doesn't seem to be many 1.8V capable SPI flash chips around, right?
<apritzel>
at least not on eBay :-D
<beeble>
they are available
<beeble>
but my problem is the external spi on the header
<beeble>
or better edge connector
<beeble>
so revision 2 will solve that
<apritzel>
can't you use the other SPI for that?
<apritzel>
that's what Xunlong did for the new board, SPI0 to the NOR flash, SPI1 on the headers
<beeble>
no, had to use that io for something else
<apritzel>
oh, OK
<beeble>
uart3 and uart4 are shared with spi1
<beeble>
we used pretty much all the pins available
<apritzel>
beeble: yeah, ssvb found that earlier: just two SPIs can be an issue, especially with the multiplexing
<apritzel>
exactly
<beeble>
pin count is a lot lower then on the a31 and a80
<beeble>
even the pin multiplexing is quite tight
<beeble>
you have to choose between parallel lcd and ethernet for example
<beeble>
or even worse lvds and ethernet
* apritzel
would know what to choose :-D
<beeble>
make sense from allwinners perspective
<apritzel>
sure, they can't make everyone happy
<beeble>
you build a tablet or a video box
<apritzel>
unless you do _really_ complex multiplexing
<beeble>
and not something multipurpose like we do
<ssvb>
apritzel: SPI boot works fine on Orange Pi PC 2 (so far with just booting uart0-helloworld), and the SD card has higher boot priority
<beeble>
it gets even worse with high speed ios on the high speed arm chips
<ssvb>
I'll try to hack U-Boot now
<apritzel>
ssvb: dammit, what's left for me then ;-)
<beeble>
there is always a lot less serdes pins then serdes ip available on the soc
<beeble>
apritzel: fixing FIT for spl? :)
<ssvb>
apritzel: has your board arrived?
<beeble>
(if thats still an issue)
<longsleep>
ssvb: let me know then you got something which one can test (u-boot or other anything other similar boot related)
<apritzel>
ssvb: yeah, today at lunch time, but couldn't try it yet
<KotCzarny>
apritzel: bpi-r1 is churning in the corner of my room for months already, doing nas/http/shell work
<KotCzarny>
so 2 reports ;)
<apritzel>
I also got this "only-half-the-bits" board ;-)
<KotCzarny>
and another bpi-m1 doing always-on audio box
<apritzel>
KotCzarny: OK, I am sold, send it into space then
<KotCzarny>
crash-boom-bang
<KotCzarny>
done
<apritzel>
or base the machines in the hospital on it
<KotCzarny>
but i agree, its too quirky to be treated seriously
<miasma>
i blame sinovoip. my banana pro clone started rebooting after few months of use. i had uptime of like 90 days. then reboot every hour
<apritzel>
I agree it works if you can live with it breaking occasionally
<KotCzarny>
though a20 is nice in the regard you can just slap on 18659 and it works
<tkaiser>
apritzel: KotCzarny: I rebooted an BPi R1 just recently with an uptime of 199 days (surveillance camera server busy with 5 streams saving/transcoding)
<KotCzarny>
apritzel: the only cause of reboots is me upgrading the kernel
<miasma>
do you use some embedded distos ? yocto / resin.io?
pzw has joined #linux-sunxi
<KotCzarny>
armbian
<KotCzarny>
;)
<apritzel>
tkaiser: KotCzarny: so how many nines are that?
<beeble>
tkaiser: i'm looking at the armbian buildtool right now. seems easy enough to add a new board. but one thing i can't seem to figure out right now is, do you support different kernel versions for a board or would this just be solved by two different board config files?
<tkaiser>
beeble: Pine64 only using default and dev. But with older SoCs like A20 default is 3.4.113, next the current stable kernel and dev points to something fancy
<tkaiser>
apritzel: Nines?
<beeble>
ah i see. ok, not happy with the names because having 3.x as default sucks somehow in my brain. but that would work
<plm>
beeble: hmm.. what is the advantage to have a SoC with a own armv8 implementation?
nove has quit [Quit: nove]
jernej_ has joined #linux-sunxi
<beeble>
plm: different reasons. apm for example has a own implementation because they wanted to be the first on the market and there was no hard ip avaiable, second one is because you think you can do it better then arm and phytium probably wants to be independet and have all the ip in house/country
<beeble>
they are funded by the goverment and they want to have their own silicon without any dependecies to outside parties
jernej has quit [Ping timeout: 268 seconds]
<beeble>
in the past they have done that with mips cores. but arm is having a lot more momentum at the moment so thats why i think they switched
<plm>
beeble: all right. And linux mainline will works on there?
<beeble>
plm: there are patches out there for mainline but i haven't seen them merged yes
<beeble>
plm: you will see the same power consumption if you use a a72 or similar
<beeble>
if you want high performance you will need more power :)
<plm>
beeble: I would like to use A72/A73 to use hardware acceleration on the integrated GPU, becouse the new ARM processors has GPU with OpenCL 1.1/2.0 full profile support.
<plm>
beeble: so, some tasks is better to do in a gpu of a 73 and faster than 64 cores of phytium
<beeble>
using the gpu takes some effort. it's a lot easier on x86. but thats something nove can better talk about
<plm>
beeble: if are using GPU, not matter if is x86 or ARM
<beeble>
also having a dedicated gpu with dedicated memory gives you lot of benefits
<beeble>
plm: driver support does matter
<beeble>
and having opencl on x86 with easy available drivers does make life a bit easier
<beeble>
but i'm not saying it's impossible
<plm>
beeble: yes, but it easier and cheaper to do a board with arm than a x86
<beeble>
depends on a lot of things so i would not say thats a statement thats always true. but i don't know your application so i can't say anything confident
<plm>
beeble: just a server board
<plm>
beeble: with sata ports and ethernet 1GB
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Read error: Connection reset by peer]
iamfrankenstein1 is now known as iamfrankenstein
mripard has quit [Quit: leaving]
mripard has joined #linux-sunxi
<beeble>
hard for me to think about a soultion that will be competitive against a x86 solutions with standard gpus attached via pcie
<plm>
beeble: news x86 (intel) has a very good GPU integrated, and GPU integrated will be a plus, not the main feature.
BigFellow has quit [Quit: BigFellow]
afaerber has quit [Quit: Ex-Chat]
<KotCzarny>
beeble, marvel boards feature minipcie ports, i wonder if pcie card would work in arm env
<beeble>
drivers are an issue (for graphic cards) otherwise its ok
<KotCzarny>
endiannes of the bootroms etc
<beeble>
i can put some nvidia cards in my xgene boards
<beeble>
but i don't own a tesla and won't in the near future :)
<KotCzarny>
i remember mac radeons having different bios and being non interchangeable
yann-kaelig has quit [Quit: Leaving]
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
gianMOD has joined #linux-sunxi
afaerber has joined #linux-sunxi
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 248 seconds]
petr has quit [Ping timeout: 265 seconds]
petr has joined #linux-sunxi
Nyuutwo has quit [Ping timeout: 268 seconds]
Andy-D__ has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
<apritzel>
ssvb: so, ready to rumble
<apritzel>
ssvb: anything you can share so far?
Nyuutwo has joined #linux-sunxi
<apritzel>
ssvb: (happy to fix things or debug it)
<KotCzarny>
apritzel, again, tell me, why are linux-sunxi is mainlining allwinner socs if not to use them? ;)
<apritzel>
like the MCP said: "He is a user!"
premoboss has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<apritzel>
KotCzarny: and it's not about not using them: I am just a bit allergic when someone says "server" in the same sentence as "Allwinner SoC"
<KotCzarny>
nah, it should be more like home-server or hobby-server
<KotCzarny>
but i can relate
<apritzel>
also I connect server with terms like manageability, bandwidth, I/O, lots of memory, reliability and so on
<apritzel>
and I have a hard time to find those terms in those SoCs
<apritzel>
which is not really surprising
<apritzel>
not even bad
<apritzel>
just not a fit
<KotCzarny>
how do you call a computer running apache server ?
<apritzel>
sure they can do a decent job for providing network services or small scale server applications
<apritzel>
"a box running Apache"
gianMOD has quit [Remote host closed the connection]
BigFellow has joined #linux-sunxi
<apritzel>
KotCzarny: running server applications on some box doesn't make it a server (at least not in the hardware term)
<apritzel>
this is especially true if someone tries to _sell_ it as a server