<karlp>
I've nto seen hsic actually on any of the allwinner parts?
Mangy_Dog has quit [Ping timeout: 268 seconds]
<karlp>
you're right though, there's an rtl8723bs (sdio) driver in staging, but it's not mentioned whether the rtl8723bu (usb) is supported by any of the existing rtl usb drivers.
* karlp
decides to buy a couple anyway, the price is right...
gaston1980 has joined #linux-sunxi
<apritzel>
karlp: yeah, I think this was one of the examples :-(
<apritzel>
and IIRC the A64 has HSIC signals on PHY0? I am not sure we support that in the PHY driver, though
<apritzel>
(rather PHY1, the one connected to the pure EHCI/OHCI controller)
cnxsoft has quit [Read error: Connection reset by peer]
<karlp>
ah, a64 is too modern for me :) Im jus tlooking at H3, plain old boirng arm32
cnxsoft has joined #linux-sunxi
<apritzel>
arm<connection lost>
<apritzel>
A64: too modern? ;-)
<karlp>
http://linux-sunxi.org/A64 says it only has one usb, compard to h3 having 3, and ... I really do want to hav ethem :)
<karlp>
basically, h3 is already a massive step up in cpu fo rme, and a64 gives me nothing by aarch64 and ATF headaches vs h3.
<apritzel>
H5 is your friend then ;-
<apritzel>
and it looks like the H3 mentions HSIC on HCI1 as well
<apritzel>
yeah, the number of USB ports is a major downside of the A64, but at the end of the day it's a tablet chip, so that's fair enough
<anarsoul>
karlp: what's wrong with aarch64 and ATF? :)
<apritzel>
karlp: compare the official support status in the kernel :-D
<karlp>
nothing per se, but I don't need any of it, so it' sjust mor ehoops for no gain.
<karlp>
and as far as I can tell, h3 is ~equivalently supported.
<karlp>
it certainly has no gaps of interest (to me)
<apritzel>
karlp: yeah, it's probably alright from a pragmatic point of view, just don't push the transition out for too long
<apritzel>
karlp: arm32 is a dying breed
<karlp>
hah
<karlp>
we're still seeing newly launched arm9, I'm not really convinced arm32 is "dead" :)
<karlp>
but hey, I'm transitioning form mips24kc, so I'm already moving ot the future :)
<apritzel>
Linux kernel's MAINTAINER: ARM PORT: S: Odd Fixes
<karlp>
that just means it's perfect and finished, not that it's irrelevant ;)
<karlp>
so "uninteresting" to kernel devs == "extremely attractive" to me who doesn't want to kernel hack for fun
lkcl has quit [Ping timeout: 256 seconds]
<karlp>
for me arm64 is all about trustzone,
<karlp>
and it' snot a huge selling point.
<apritzel>
what does that have to do with each other?
<apritzel>
Trustzone predates Armv8 by years (if not a decade?)
<karlp>
yeah, but ~everything on armv8 has trustzone, and ~nothing on armv7 has, even if the spec was available for years and years
<apritzel>
????
<apritzel>
You have the same Trustzone in your H3, and use it for U-Boot's very minimal PSCI implementation
<karlp>
so why all the ATF hoops on aarch64, but not on arm32?
<karlp>
isn't that all from trustzone changes?
<apritzel>
TF-A is the reference implementation for doing the secure enablement and runtime support *properly*
<apritzel>
you have similar code in U-Boot, just in the usual shoddy U-Boot way
<apritzel>
karlp: ask smaeul, he is working on a TF-A port for the H3
<karlp>
I may have mixed thi sup with armv7-m vs armv8-m where, and the _appearance_ on armv8-a, on -m profile, trustzone isnew in v8.
<karlp>
thakns for the extra information
<smaeul>
the nice thing about the shoddy u-boot way is that it fits in the available SRAM :)
<smaeul>
but yes, TF-A does all of the things the ARM says to do, while u-boot is basically "here's a table of function pointers for you to fill in, good luck!"
<smaeul>
apritzel: speaking of trustzone, when you put TF-A in DRAM, do you protect it with the TZASC?
<apritzel>
I understand that many people are not happy with this extra firmware component, but it's not Kansas anymore, and at the end it's not rocket science to compile and add that
<apritzel>
smaeul: I plan to, and played around with the controller a while ago, to prove it works
<apritzel>
smaeul: but I don't have that code yet
lkcl has joined #linux-sunxi
<apritzel>
btw: the FIT image support in my sunxi-fel is working now (both "old" and "new" style FIT images), so I can use "sunxi-fel uboot u-boot-sunxi-with-spl.bin" on the 64-bit parts as well
<smaeul>
old and new style?
<apritzel>
smaeul: before and after your change ;-)
<apritzel>
we probably don't need the old way (U-Boot is "firmware", TF-A is in loadables), but it's more flexible and isn't much code to support both
<bauen1>
that makes such devices a lot more "desirable"
<KotCzarny>
On fresh installs, the content of /bin, /sbin and /lib will be installed into their /usr counterpart by default. /bin, /sbin and /lib will be soft-links pointing at their directory counterpart under /usr/.
<bauen1>
KotCzarny: i don't think the FHS actually specifies that /usr/{bin,lib,sbin,...} and their / counterpart have to be directories and have to be seperate
<KotCzarny>
have you seen the link/
<bauen1>
KotCzarny: yes
lurchi__ is now known as lurchi_
victhor has joined #linux-sunxi
tuxd3v has quit [Quit: Leaving]
victhor has quit [Client Quit]
lurchi_ is now known as lurchi__
<karlp>
MoeIcenowy: excellent, I just read the kconfig help and wasn't entirely clear, much better in the source :)