specing has quit [Read error: Connection reset by peer]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Ntemis has quit [Remote host closed the connection]
<willmore>
lurchi_, no, they're mostly STB or tablet chipsets.
<willmore>
I would really expect the STB designed to use cheap unregulated 12V inputs. The tablet ones would accept Li-ion voltages, so they'd be a bit more cripled.
ninolein has quit [Ping timeout: 258 seconds]
ninolein has joined #linux-sunxi
<willmore>
lvrp16, don't forget USB2.0 over C completely ignoring the high speed lanes. Now devices can be 'type-C' and no better than USB-2.0
<lurchi_>
willmore: even low-speed ...
<RichardG867>
what I do think is missing is a SBC that can be natively battery powered like the old A10/A20 ones
<RichardG867>
because lithium -> 5V USB -> 3.3V/1.8V/whatever else SBC is a waste really
<lurchi_>
RichardG867: Pine64 can be battery powered
<lurchi_>
it accepts anything between 6 and 3.7 V, and only boosts USB to 5V
<RichardG867>
that's...ideal.
<willmore>
RichardG867, the issue is that it's cheaper to do li-ion up to 5V and then down to all the other voltages they need. If they didn't do that, then the 3.3V supply would need to be buck/boost and those have some issues.
<RichardG867>
can't you just use a 3.3V buck and have the thing die once the cell goes below 3.3V
<RichardG867>
since 3.3V is pretty far in the li-ion discharge curve
uwe_ has quit [Ping timeout: 255 seconds]
pg12 has quit [Ping timeout: 246 seconds]
uwe_ has joined #linux-sunxi
<willmore>
RichardG867, Li-poly goes to 3.0V
pg12 has joined #linux-sunxi
<willmore>
So, if you do that, you leave 20-25 percent of the battery capacity unused.
<willmore>
Also, only the 3.3V loses regulation. The 1.8V and others will be fine. Unless you have a good voltage monitor, you're going to have all kinds of fun. ;)
<RichardG867>
interesting points.
<RichardG867>
still, running a SBC that only needs 5V for USB devices (which I can have none plugged in) off a 5V power bank is a bit of a waste. maybe not much of a waste, I'm new to this.
uwe__ has joined #linux-sunxi
<RichardG867>
had this as a showerthought when running my pi 3 (my first OPi is in the mail) with a RTL-SDR off a power bank, since it appears both the RTL and its tuner can run at 3.3V.
uwe_ has quit [Ping timeout: 240 seconds]
<RichardG867>
so you have the PAM on the pi and what-have-it on the RTL-SDR, both producing 3.3V from the same source
<willmore>
There are a lot of efficiencies that could be gained from custom designs.
<RichardG867>
and vaguely speaking of efficiency...
<RichardG867>
is the OPi zero still having overheating issues?
<RichardG867>
got a lite thinking of those issues.
<willmore>
RichardG867, mine never did. One of the Neo boards did until they did a hardware fix, but, IIRC, they're all better now.
cnxsoft has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 246 seconds]
cnxsoft1 is now known as cnxsoft
lurchi_ is now known as lurchi__
lemonzest has quit [Quit: Quitting]
uwe_ has joined #linux-sunxi
uwe__ has quit [Ping timeout: 240 seconds]
uwe_ has quit [Ping timeout: 240 seconds]
uwe_ has joined #linux-sunxi
<wens>
true, but USB is always 5V, unless you take it apart and hardwire the bits together
cnxsoft has quit [Ping timeout: 246 seconds]
cnxsoft has joined #linux-sunxi
[7] has quit [Ping timeout: 246 seconds]
TheSeven has joined #linux-sunxi
lkcl has quit [Ping timeout: 248 seconds]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
Hao has joined #linux-sunxi
<Hao>
MoeIcenowy: Are you looking for the r40 document?
<Hao>
i have register document about t3 v40 r40
<Hao>
they share the same sdk
<Hao>
reference to the processor block diagram , just a little different bettwen them
<Hao>
V40 has CAN controller, the other hasnt..
<Hao>
i will share the document about them..
<MoeIcenowy>
Hao: I think they all have CAN
<MoeIcenowy>
wens: have you seen my R40 ccu patchset?
<MoeIcenowy>
and Tina folks released R40 user manual
Andy-D__ has quit [Ping timeout: 248 seconds]
<Hao>
MoeIcenowy: may be just has some different on the product market, actually they are the same
<MoeIcenowy>
I also think so ;-)
perr has joined #linux-sunxi
perr has joined #linux-sunxi
perr has quit [Changing host]
perr has quit [Client Quit]
a|3x has quit [Ping timeout: 276 seconds]
fl_0 has quit [Quit: STRG + Q]
IgorPec has joined #linux-sunxi
fl_0 has joined #linux-sunxi
<wens>
MoeIcenowy: haven't reviewed them
<wens>
MoeIcenowy: is there a new revision for the manual?
reinforce has joined #linux-sunxi
indy has quit [Ping timeout: 276 seconds]
massi has joined #linux-sunxi
lkcl has joined #linux-sunxi
kaspter has joined #linux-sunxi
fugitive has joined #linux-sunxi
specing has joined #linux-sunxi
<montjoie>
wens: it seems that rockship integrated PHY is merged, so I will resend my series without the doc patch and with property on board DT
<MoeIcenowy>
wens: I think no
<MoeIcenowy>
P.S. how to solve the R40 GMAC register problem?
matthias_bgg has joined #linux-sunxi
BenG83_ has quit [Ping timeout: 246 seconds]
<wens>
MoeIcenowy: my idea is for the ccu driver to register a custom regmap, then the gmac driver would do dev_get_regmap
<MoeIcenowy>
how custom? only allow the access to 0x164?
<wens>
MoeIcenowy: yeah, something like that
<wens>
we really don't want other user poking clock registers
<MoeIcenowy>
or make it only 4 bytes wide and contains only the GMAC register?
<wens>
montjoie: you should probably pick the doc patch from net-next, and include it in your series for netdev
<wens>
and note it in the cover letter, or in a comment in that patch
<wens>
davem can decide whether to apply it or not
<wens>
you can't really depend on something for the next release, if you're sending fixes for the current release :)
<MoeIcenowy>
I think use 0x164 can really export the structure of CCU, but use 0x0 can make code more simpler
<MoeIcenowy>
can a regmap forbid access to certain registers?
<wens>
yes
<wens>
or rather, you can specify which registers can be read, and which ones can be written to
<MoeIcenowy>
should we allow all read but only write to 0x164, or should we only allow r/w to 0x164?
yann|work has joined #linux-sunxi
hp197 has quit [Ping timeout: 276 seconds]
<oliv3r>
hi, has any of you ever used the gpio-hog on our sunxi's? There is very limited info/google data available, and i can't seem to get it to tie into our dtb. or rather, I'm not sure under which node it should live
Boris80 has joined #linux-sunxi
chlorine has joined #linux-sunxi
hp197 has joined #linux-sunxi
gnarface has joined #linux-sunxi
nOOb__ has joined #linux-sunxi
yann|work has quit [Ping timeout: 240 seconds]
LargePrime has quit [Ping timeout: 276 seconds]
<wens>
montjoie: still, Rob hasn't answered what to do about the internal phy node
<montjoie>
wens: yes, I try to wait...
<montjoie>
but on this thread, long delay seems a goal
netlynx has joined #linux-sunxi
<KotCzarny>
sent patches with your preferred solution and ask him that way? ;)
<KotCzarny>
*send
<wens>
yeah, that's one way :)
<wens>
he'll nack it if he doesn't like it
<wens>
but generating warnings is likely going to cause other people to revert it
<montjoie>
the correct way is probably to create two MDIO node but it requires some(lot) of hack of stmmac
<montjoie>
property on dt node is simple
<Hao>
MoeIcenowy:i has pushed the r40-t3-v40 manual to github
<wens>
there has been effort to reduce the number of warnings from device trees
<MoeIcenowy>
at least some people here can read Chinese ;-)
<KotCzarny>
and the rest can try google translate
<wens>
KotCzarny: good luck with that, the grammar gets seriously fxxked up, if not the rest of the words
<KotCzarny>
well, since i'm not native english speaker, my mind is already adjusted to weird grammars ;)
<KotCzarny>
and when i was reading some chinese A13 docs it was working out quite well
<wens>
O.o
indy_ has joined #linux-sunxi
yann|work has joined #linux-sunxi
fugitive has joined #linux-sunxi
indy_ has quit [Read error: Connection timed out]
_hp197 has joined #linux-sunxi
_hp197 has quit [Client Quit]
<MoeIcenowy>
In fact I think currently the worst design of the Allwinner SDK is that the sys_config.fex is still used ;-)
montjoie has quit [Ping timeout: 276 seconds]
chrisf_ has quit [Ping timeout: 248 seconds]
BenG83 has joined #linux-sunxi
BenG83 has quit [Remote host closed the connection]
BenG83 has joined #linux-sunxi
indy_ has joined #linux-sunxi
<oliv3r>
wens: you pointed me towards gpio-hog; but I think the generic pinctrl has also things for to simplify this, such as 'input-disable' and 'output-high' for example. These are part of the pinconf_generic_parse_dt_config; but I belive pinctrl-sunxi does not use this,correct?
indy_ has quit [Ping timeout: 248 seconds]
montjoie has joined #linux-sunxi
<wens>
not all generic pinconf options are implemented in pinctrl-sunxi
<gnarface>
so, i'm reading https://linux-sunxi.org/Mainline_U-Boot and wondering if the "1.2GHz 64-Bit Quad-Core ARM Cortex A53" in the pinebook will work with the stable u-boot or if i should try experimental?
hp197 has quit [Read error: Connection reset by peer]
<MoeIcenowy>
in fact it needs my fork if you want LCD ;-)
<oliv3r>
wens: i understand, but does the pinctrl helpers state that you can only use the helpers if you support all of them?
<gnarface>
was that to me, MoeIcenowy?
<oliv3r>
i can imagine that we'd first call pinconf_generic_parse_dt_config; and then override the old allwinner ones and only apply the ones we support, or am I missing something here?
<wens>
oliv3r: nope
<wens>
oliv3r: we use pinconf_generic_parse_dt_config, and only handle the options we support
<MoeIcenowy>
gnarface: y
<oliv3r>
really? let me double check
<wens>
oliv3r: if pinconf_generic_parse_dt_config fails, we fall back to the old allwinner,* properties
<oliv3r>
currently i'm looking into the stable 4.9; but let me check master
<gnarface>
MoeIcenowy: mentioned on the wiki?
<MoeIcenowy>
not mentioned
my123 has quit [Read error: Connection reset by peer]
<oliv3r>
i'll see how much effort it is to add support for some of the other features
<lurchi_>
wens: have you seen the patch for SPI on A64?
Guest12454 is now known as hp197
hp197 has quit [Changing host]
hp197 has joined #linux-sunxi
hp197 has quit [Quit: Lost terminal]
hp197 has joined #linux-sunxi
<wens>
lurchi_: thanks for the reminder
hp197 has quit [Changing host]
hp197 has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
foxx_ has joined #linux-sunxi
vagrantc has joined #linux-sunxi
SP7RT has joined #linux-sunxi
<FergusL>
Does anyone know how to use the onboard reset and power buttons on Nano Pi M1 ?
<oliv3r>
ok i get input-enable; but what would be input-disable? E.g. config a pin as input, but ignore it's incoming data?
Hao has quit [Ping timeout: 248 seconds]
JohnDoe_71Rus has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
<wens>
look at the dt bindings
<wens>
oliv3r: you have to think outside the context of sunxi
<wens>
on some chips, it may be possible to have input always available
<MoeIcenowy>
P.S. for SPI there's another problem
<MoeIcenowy>
the Data Strobe pin of eMMC is muxed with MISO of SPI
<wens>
i.e. pinctrl and gpio are orthogonal
<MoeIcenowy>
it doesn't matter on Pine64
<MoeIcenowy>
however, it's a problem on SoPine or Pine64-LTE
<MoeIcenowy>
s/LTE/LTS/
<MoeIcenowy>
they have SPI flash soldered and eMMC available
<MoeIcenowy>
Data Strobe is only used in eMMC HS400 mode
afaerber has quit [Quit: Leaving]
<wens>
split out the data strobe pin?
<oliv3r>
wens: i understand it also applies to outside the sunxi context, i'm just trying to image what it is intended, so i can bring it into the sunxi context :)
jstein_ has joined #linux-sunxi
<oliv3r>
wens: the pinctrl-bindings.txt document only lists the properties, and has a very limited explanation, hence me asking :)
jstein_ is now known as jstein
<oliv3r>
i can imagine you want to be able to set the default of a pin to 'input', and not configuring it would leave it in 'some' other state, i can imagine there's enabled and disabled inputs, but what would it mean
jstein has quit [Remote host closed the connection]
<oliv3r>
e.g. as I mentioned above, an enable input, well that's as expected, but nothing is done with the input data, anda disabled input, the port is configured as an input, but the data register always reads 0 for example?
<oliv3r>
configuring the port as input (or output) has electrical consequences, hence I understand you do want it to be configured
<oliv3r>
it's just the disabled bit that throws me off
<oliv3r>
obviously, the disabled bit does not apply to sunxi as far as I can tell ...
rpirea has joined #linux-sunxi
<rpirea>
hi.
<rpirea>
what differences are between sunxi-next and sunxi-devel branches?
afaerber has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
tlwoerner has quit [Changing host]
tlwoerner has joined #linux-sunxi
<wens>
oliv3r: what I can think of is input and output are branches off the pin, and enable / disable are explicit requests to connect or disconnect the branch
SP7RT has quit [Ping timeout: 258 seconds]
indy_ is now known as indy
afaerber has quit [Ping timeout: 240 seconds]
SP7RT has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
chlorine_ has quit [Remote host closed the connection]
chlorine_ has joined #linux-sunxi
chlorin__ has joined #linux-sunxi
<oliv3r>
i suppose it depends on at which point it gets disconnected
<oliv3r>
when I think of input, i think of either input, output or high-z
<oliv3r>
but this is electrically looking at the pin (on the package I suppose)
<oliv3r>
wens: i can however find no reference in master that we are using the generic dt parsing, so far we only parse the drive strength and the bias (for both old and new styles) and that's it
chlorine has quit [Ping timeout: 246 seconds]
<wens>
correct
<oliv3r>
ah i thought you mentioned we do use the generic pinctrl framework to parse the dt
<wens>
oliv3r: as mentioned, some chips have input/output as branches between the external pin and the internal pinmux
<oliv3r>
wens: confusing :p
<wens>
oliv3r: we use the parsing function, but we only handle the results for properties we support
chlorine_ has quit [Ping timeout: 240 seconds]
<wens>
oliv3r: blame the hardware designers :p
<oliv3r>
wens: so if I want to add suppose for input-enable; output-low, output-high
<oliv3r>
do I parse the dt in sunxi-pinctr.c?
<oliv3r>
or can I somehow make use of pinconf_generic_arse_dt_config?
<wens>
a good example is actually the i2c controllers in the hdmi block, which have extra pin controls to force it high or low
<oliv3r>
ohh
The_Loko has quit [Quit: Leaving]
<oliv3r>
hmm, but then i'd expect it to be 'input-high' and input-low :p
<wens>
ah, ok I remembered wrong, we do our own parsing, not using the pinctrl core's helpers
<wens>
oliv3r: forcing it high or low is output, not input
<wens>
oliv3r: there is also an input function, which can be used to sense the pin's level
<wens>
said function can be enabled or disabled
<oliv3r>
wens: depends on where you look, 'electrically configure as input, but report it as "high"' for example
kaspter has joined #linux-sunxi
fkluknav has joined #linux-sunxi
afaerber has joined #linux-sunxi
<oliv3r>
wens: see, wrong remembering leads to confusing me :p anyhow, to add these properties, we'd have to parse it ourselves as well, right?
<oliv3r>
as we can't use the helper AND parse it ourslves for allwinner, bits
<wens>
correct
popolon has joined #linux-sunxi
chlorine has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
<oliv3r>
ok, thanks :) i'll do the parsing then
chlorin__ has quit [Ping timeout: 240 seconds]
<fugitive>
hey guys. Can grsec patches be applied to the kernel and used with H3 allwiner devices?
<montjoie>
fugitive: grsec supports arm ?
<fugitive>
idk.. i've built alpine on orange pi, and was looking to implement grsec
<fugitive>
i believe it does
<montjoie>
I think it should works, depend on what grsec patch you have (against which kernel)
xpete has quit [Quit: Leaving]
chlorine has quit [Remote host closed the connection]
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
chlorine has joined #linux-sunxi
TEKrantz has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
massi has quit [Remote host closed the connection]
nOOb__ has quit [Remote host closed the connection]
TEKrantz has quit [Quit: If you're not living on the edge, you're taking up too much space]
TEKrantz has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
foxx_ has quit [Ping timeout: 260 seconds]
chlorine_ has joined #linux-sunxi
chlorine has quit [Ping timeout: 240 seconds]
BenG83 has quit [Ping timeout: 240 seconds]
<MoeIcenowy>
but I think latest publicly available grsec is still 4.9
<MoeIcenowy>
and 4.9 doesn't work so well on H3
<MoeIcenowy>
I2C/SPI/Ethernet/audio supports are in 4.13 but missing in 4.9
<montjoie>
:) I didnt wanted to start the troll about grsec availlability:)
<igraltist>
i have the 4.9 on my opipc and basic works, for ethernet i use usb-to-lan adapter
SP7RT_ has joined #linux-sunxi
<igraltist>
and in general a security framework does not influence the kernel driver
<montjoie>
grsec is beyond framework with PAX.
SP7RT has quit [Ping timeout: 260 seconds]
<montjoie>
and since PAX have some part in assembly... ARM support is not evident
<MoeIcenowy>
maybe the orange-pi-4.9 branch of github.com/megous/linux can be usable
<montjoie>
I want to do some secureboot optee, which SoC is the best for that ? I ask that because I saw some task about H3 thaa cannot be boot in secure mode
<montjoie>
In fact I wish to have a column for that in the support matrix or other wiki way
<igraltist>
i can remember i had pax in kernel 3.18 but for rpi1 and it was working
matthias_bgg has quit [Quit: Leaving]
IgorPec has quit [Ping timeout: 240 seconds]
reinforce has joined #linux-sunxi
Andy-D has joined #linux-sunxi
mik__ has joined #linux-sunxi
<mik__>
Hello. I am in listen mode. :-)
mik__ has quit [Quit: Page closed]
chlorine_ has quit []
<wens>
reviewing one CCU driver takes around 1 hour :(
Hao has joined #linux-sunxi
SP7RT_ has quit [Ping timeout: 240 seconds]
SP7RT has joined #linux-sunxi
fugitive has quit [Ping timeout: 240 seconds]
IgorPec has joined #linux-sunxi
Boris80 has quit [Ping timeout: 258 seconds]
ykchavan has joined #linux-sunxi
|Jeroen| has joined #linux-sunxi
fugitive has joined #linux-sunxi
BenG83 has joined #linux-sunxi
fugitive has quit [Ping timeout: 258 seconds]
yann-kaelig has joined #linux-sunxi
<MoeIcenowy>
wens: thanks ;-) don't get too tired
BenG83 has quit [Ping timeout: 255 seconds]
yann-kaelig has quit [Remote host closed the connection]
rpirea has quit [Quit: rpirea]
leviathan has joined #linux-sunxi
SP7RT has quit [Ping timeout: 260 seconds]
phipli has joined #linux-sunxi
SP7RT has joined #linux-sunxi
Hao has quit [Ping timeout: 240 seconds]
specing has quit [Ping timeout: 240 seconds]
Andy-D has quit [Ping timeout: 248 seconds]
specing has joined #linux-sunxi
MikeyG has joined #linux-sunxi
<MikeyG>
anyone who preordered rock64 actually get anything yet?
fugitive has joined #linux-sunxi
a|3x has joined #linux-sunxi
Andy-D has joined #linux-sunxi
|Jeroen| has quit [Quit: dada]
gumblex has quit [Ping timeout: 240 seconds]
gumblex has joined #linux-sunxi
ykchavan has quit [Read error: Connection reset by peer]
ykchavan has joined #linux-sunxi
fugitive has quit [Ping timeout: 240 seconds]
lemonzest has joined #linux-sunxi
SP7RT has quit [Ping timeout: 260 seconds]
fugitive has joined #linux-sunxi
SP7RT has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 248 seconds]
fire219 has quit [Read error: Connection reset by peer]
<MikeyG>
before production?
MikeyG has left #linux-sunxi [#linux-sunxi]
Gerwin_J has quit [Quit: Gerwin_J]
fire219 has joined #linux-sunxi
shaggy013 has joined #linux-sunxi
<shaggy013>
how many h5 v1.1 sdk versions are there ?