<junari>
Jookia: I can check when the device is ready
<Jookia>
this was tested on a t113/d1 but should be the same controller as others
<junari>
As a last resort, I will be able emulate the work of usb_id
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<junari>
Do I understand correctly that the H616 cpu can boot only from SPI0 interface (not SPI1), which is also multiplexed for emmc?
bauen1 has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
apritzel_ has left #linux-sunxi [#linux-sunxi]
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<apritzel>
junari: the BROM indeed only boots from SPI0
<apritzel>
junari: but the pin collision is only about the DS (data strobe) pin, which is only needed for HS400 eMMC modes
<apritzel>
junari: is that about designing a new board, or to get SPI boot on an existing board?
<apritzel>
if you got an eMMC, you can also use the eMMC boot partitions to get a boot media separate from the rest of the normal storage
<apritzel>
if you are about to design a new board, you could either just not wire up PC0 to the eMMC, but just to the SPI flash instead
<apritzel>
mainline doesn't support HS400 anyway at the moment, and many cheap eMMCs are limited by their flash transfer speed rather than the interface speed anyway
warpme has joined #linux-sunxi
<junari>
apritzel: it's about designing a new board, but with existing SoM. Very useful information about SPI and eMMC, I will look at the documentation if the necessary pins are available. Thank you
<apritzel>
junari: if you need to decide between the twp, eMMC is more useful, and you basically get the boot partitions for free. In Linux there is just a /dev/mmcblk0
<apritzel>
/dev/mmcblk0boot0, I meant to say
<junari>
apritzel: what is twp?
<apritzel>
sorry, typo, "decide between the two, ..."
<junari>
I prefer raw NAND or NOR, because it is more resistant to power cuts
<apritzel>
really? raw NAND is a REAL pain from the software side, as in: actually unsupported in mainline
<junari>
But the SoM already has emmc and will be used anyway
<apritzel>
yeah, so in this case you wouldn't need to bother with SPI, really, at least not for just booting
<junari>
Before that I work with NXP
<junari>
It supports raw nand in mainline
<apritzel>
yeah, I am sorry that are dealing with AW now, that must be an especially hard landing when coming from NXP ;-)
<junari>
Yes, if you need a driver, then write it yourself :)
<junari>
About SPI I think that I can always remove it from BOM if all goes well
<junari>
But it's good to have a plan B
bauen1 has joined #linux-sunxi
<mansr>
is MLC nand supported at all yet?
apritzel_ has joined #linux-sunxi
<junari>
We have always used SLC. Don't know about others
<buZz>
on MLC vs SLC, the CHIP shipped with 8GB flash chips of one kind, but used the driver of other kind
<buZz>
so only had 4GB space available
<buZz>
until ~someone implemented a raw driver for it in kernel? then all the old hw with 8GB flash could use the whole 8GB
<buZz>
all the newer ones they shipped had 4GB chips of the other kind
apritzel_ has quit [Ping timeout: 480 seconds]
<mansr>
so I have an A20 based system that uses an external rtc oscillator
<mansr>
this means the OSC32K_SRC_SEL bit in the LOSC_CTRL register needs to be set
<mansr>
I've been using a trivial kernel hack to set it, but I'd like to do it properly
<mansr>
a simple way would be to use a DT property in the rtc node to select it
<mansr>
I'm wondering if that would be acceptable, or if someone will insist on it being done through the clk framework or something
<mansr>
I guess the only way to get an answer is to make a patch and wait to be told off
<apritzel>
mansr: I am afraid this would need to be a proper solution, through the sunxi clock driver, I guess
<mansr>
but the control bit is in the rtc block, nowhere near the clock driver
<mansr>
I suppose the rtc driver could export a clock mux with two inputs
<apritzel>
I need to have a closer look, but my hunch is that this bit is just a mux, and we have rtc clocks now, at least for the newer SoCs
<mansr>
that doesn't help me
<apritzel>
mansr: if you have something already, you could just propose it on the list
<apritzel>
and then let people propose an alternative
<mansr>
I have a three-line patch that checks a dt property and sets the bit
<mansr>
the clk route would require a lot more work
<mansr>
and it would add a dependency on the rtc in the ccu driver
<mansr>
and anything else that uses the 32k clock
<mansr>
I'm not sure what the consequences of that would be
<apritzel>
it's all a bit hard to judge on just two lines in IRC and within two minutes, that's why I think posting that on the list would be better
<apritzel>
that would us show the code and give people more time to look at it
<mansr>
as I said...
<apritzel>
for H6 the RTC driver also provides clocks
<apritzel>
one reason was to support external oscillators, but also using the internal RC osc if that is missing
<apritzel>
it could well be that for the A20 this is acceptable, since we cannot really change the RTC binding now anymore
<apritzel>
mansr: so for the newer RTC driver we flip that bit if we have a clock property, referring to the fixed external osc
<apritzel>
that sounds nicer than having an explicit property (this is what you have, IIUC?)
<mansr>
for A20, the 32k oscillator is simply declared as a fixed clock regardless of source
<mansr>
changing that now seems difficult
<mripard>
apritzel: NAND itself is supported. The FS don't support MLC NANDs, but it doesn't affect the driver, and SLC works fine
<apritzel>
mansr: yeah, but if you add just a reference to that fixed osc from the RTC node, and take that as a hint to flip that bit, that should be both easy and compatible
<apritzel>
mripard: for the H616? The actual NAND controller is probably close, but I haven't seen any NAND driver compatible beyond the older v7 SoCs
<apritzel>
I am not even sure the H3 would work out of the box
<mansr>
apritzel: ok, that would work
<apritzel>
mripard: and SLC is cute, but in reality most people chose raw NAND for the price, and then it's surely MLC
<mripard>
we haven't had any board with a NAND chip since the A64, so it's hard to tell
<mripard>
given allwinner habits, it's likely it works
<mripard>
most people choose raw NANDs for multiple reasons. it's far more resilient to power cuts for example like junari said
junari_ has joined #linux-sunxi
<apritzel>
mripard: no NAND boards beyond A64: yes, I was hoping so as well, but I have an H6 and a H3 TV box with MLC NAND, and I think others reported of cheap devices with NAND as well lately
<mripard>
I'm not sure I get the hostility toward NAND?
<mansr>
it's a PITA to use
<apritzel>
mripard: but didn't you say yourself that MLC is not supported? And all those software layers and code just to access block storage
<apritzel>
eMMC just works out of the box, and some hardware takes care of those wear leveling and read disturbance and what not
<mripard>
inline encryption for the eMMC, or the PCIe, are not supported, it doesn't mean I wish them to go away?
<mripard>
and yeah, some
<mripard>
with an eMMC, you have 0 idea what kind of resiliency you can expect towards power cuts, wear leveling, bit flips, etc.
<mripard>
it just works as long as you hope for the best
<mansr>
by all means use raw nand if you love it that much
junari has quit [Ping timeout: 480 seconds]
<apritzel>
mripard: but raw NAND on Allwinner mainline only works for the C.H.I.P. with SLC, right? Not even the Cubietruck works, IIUC
<apritzel>
so I appreciate the theoretical aspects of resilience and closer control for NAND, but that comes at quite a high price in practice, I'd say
<mripard>
plus a couple of other boards, but yeah
<mripard>
also, Allwinner isn't the entire embedded ecosystem?
<apritzel>
no, but this is the sunxi channel ;-)
<mripard>
mansr: so arguing that NAND isn't the root of all evil is equal to I want to use it everytime, everywhere now?
<apritzel>
mripard: surely those are solvable problems, but I don't see anyone lately willing to contribute mainline patches
<mansr>
raw nand has its uses, so does emmc
<mripard>
that's what I was saying, so yeah, I agree
<buZz>
apritzel: they later released a new driver for raw NAND
<buZz>
iirc somethingelectron
<buZz>
> Additional raw NAND components may work, but will most likely require changes to the Buildroot configuration. Additionally, there are two different branches of the Next Thing Co. Linux kernel depending on what type of NAND you have: SLC or MLC.
<buZz>
hehe lol
<buZz>
not sure, but i own multiple CHIPs that i bought with '4GB flash' that -later kernels- made 8GB
<apritzel>
I understand that there are a lot of promising bits and pieces out there, mostly for some old boards, but in reality raw NAND is just a pain to *use* for anything halfway decent, and is just plainly not supported in mainline atm
<apritzel>
in the context of this channel ;-)
<buZz>
apritzel: oh, totally
<buZz>
plus speed isnt that impressive, vs a SD card or something
<mansr>
back to the rtc... an "undocumented feature" at least on this board is that if the A20 temperature reaches ~55 °C, the external rtc oscillator stops working
<mansr>
it then switches to the internal oscillator
<mansr>
which makes the brcm bluetooth stop working
<apritzel>
mansr: who switches to the internal oscillator? Some hardware on the SoC itself? Or some hacky code in the BSP kernel?
<mansr>
the hardware
<mansr>
this is running mainline kernel
<mansr>
when this happens, the bluetooth driver gets really unhappy and never recovers
<mansr>
and this is where I have indeed added some weird hacks
<mansr>
when the oscillator fails, bit 13 in the control register gets set (determined by observation)
<mansr>
so I check for this and unbind the bluetooth driver
<mansr>
and rebind when it comes back
<mansr>
that resets the bt hardware and all works
<mansr>
ugly, but it's the best we could come up with
<apritzel>
can you do this from the userland side, somehow? unbind/bind, I mean? A hacky script is easier to maintain and justify than (mainline) kernel changes
<mansr>
I made a sysfs file showing the state of that bit, the rest is userland
<apritzel>
mansr: that whole problem is of course nasty, but if all it takes in the kernel is that sysfs entry, this might even be upstreamable?
<apritzel>
mansr: though this whole thing is odd? Why would it switch *away* from the external OSC if it gets too hot?
<apritzel>
The other way would make more sense: turning the internal RC osc off, because it is only calibrated for a certain temperature
<mansr>
it seems like the (internal) xtal driver stops working when it gets hot
<mansr>
or maybe the xtal itself goes weird, hard to tell
<mansr>
either way, the external clock stops "clocking"
<mansr>
which triggers the fallback to the rc oscillator
<mansr>
same thing happens if you stick a finger on the external parts
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
junari_ has quit [Ping timeout: 480 seconds]
<apritzel>
mansr: while looking at the LOSC register, I see that there is bit 14: CLK32K_AUTO_SWT_EN (auto switch enable). Maybe that controls the behaviour you described?
<mansr>
you might think so, but that bit is cleared
vagrantc has joined #linux-sunxi
jason123onirc has joined #linux-sunxi
jason123santaonirc has quit [Ping timeout: 480 seconds]
<mansr>
I'd much rather be using an SoC with actual documentation, but some people want to save money
<gamiee>
mansr: the problem is that there aren't any good SoCs which are more pricy and actually having better documentation or software support.
<mansr>
anything from TI, NXP, or ST has better docs
<gamiee>
Well, depends, but yeah, some from those vendors have better docs, but we can't say the same about software support, availability etc.
<mansr>
there are generally fewer surprises
<gamiee>
Personally, I will be rather working with Allwinners than with NXPs.
<mansr>
like the bluetooth failing in hot weather thing
<gamiee>
reliability is another thing
<mansr>
of nxp socs can be really annoying
<mansr>
like the ones that originally had a big endian ppc core that got swapped out for a little endian arm
<mansr>
and the peripherals are big endian still
<mansr>
well, half of them
<mansr>
imx6/7/8 are not so bad
<gamiee>
can be. Still, Allwinners can serve quite well. I use Allwinner H3 in my product, and it does amazing job. And thanks for having Crust and many other components made by sunxi and other kernel devs, it have features which any other SoC doesn't offer (and if it does, it is definitely not that modular and not in mainline).
<gamiee>
Only thing which worries me is bad thermals of CPU and that they will stop manufacturing the SoC itself, as it is having it's age
<mansr>
sure, they work reasonably well once you figure out the quirks
<mansr>
we've sold some 100k of them and people seem happy
<gamiee>
devices with allwinner SoCs? That's pretty cool!
<mansr>
mostly A20, some H3
<mansr>
running mainline linux
<gamiee>
amazing!
warpme has quit []
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
hentai has quit [Remote host closed the connection]
apritzel_ has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
apritzel_ has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
Jookia has quit [Remote host closed the connection]
Jookia has joined #linux-sunxi
warpme has quit []
qwestion has joined #linux-sunxi
JohnDoe_71Rus has quit []
apritzel_ has joined #linux-sunxi
apritzel_ has quit [Ping timeout: 480 seconds]
hentai has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit []
ftg has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
apritzel_ has joined #linux-sunxi
bauen1 has joined #linux-sunxi
vagrantc has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
vagrantc has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]