<apritzel>
boot0 does a 64-bit reset into ARM trusted firmware, which drops back to 32-bit and into U-Boot
<lennyraposo>
pmic)
<lennyraposo>
ok
<lennyraposo>
so my understanding is u-boot acts in place of a bios in otherwords
<apritzel>
and U-Boot shouldn't do the PMIC stuff, I plan to do this from ATF (ARM trusted firmware)
<apritzel>
well, this is a good topic
nemunaire has quit [Quit: quit]
<apritzel>
traditionally U-Boot is often both firmware and bootloader
<lennyraposo>
didn't longsleep backport and include ATF
<apritzel>
for the 32-bit Allwinner chips it really is
<apritzel>
but actually U-Boot should just be the boot loader and shouldn't be bothered with hardware initialization
<apritzel>
and the A64 firmware setup has everything to do it that (the right) way
<lennyraposo>
so oyu are telling me that allwinner is basically doing things half assed and doublin gup when there is no need to
<apritzel>
kind of
<lennyraposo>
so the boot source does away with that once we get it
<apritzel>
they seem to have had some right ideas this time
<lennyraposo>
on the hardware side
<lennyraposo>
but not in the software side
<apritzel>
but then really struggled with properly implementing this
<lennyraposo>
so in an idealistic world
<lennyraposo>
it shouldn't be this tennis match of back and forth with u-boot having to initialize and then boot
<apritzel>
U-Boot shouldn't really initialise stuff expect say the MMC controller
<lennyraposo>
the kernel should be initializing the hardware in other words?
<lennyraposo>
or I should say the ATF
<apritzel>
the ATF, really
<lennyraposo>
I get it now
<lennyraposo>
trusted firmware
<lennyraposo>
get it going
<lennyraposo>
u-boot turn on the mmc
<lennyraposo>
point to the kernel
<apritzel>
it should be more like x86: the BIOS cares about the board specific setup
<lennyraposo>
and done
vishnup has quit [Remote host closed the connection]
<apritzel>
than loads the boot loader, which could be U-Boot or something else
<apritzel>
and if it is something else, the board setup shouldn't be replicated there
<lennyraposo>
from what I have been reading it seems like a hand off from boot0 to u-boot then back to boot0
<lennyraposo>
or am I reading oncorrectly
<lennyraposo>
incorrectly
<apritzel>
normally U-Boot just loads the kernel and jumps to it
<apritzel>
boot0 is done once U-Boot starts
<apritzel>
the only exception is that FEL booting, but that usually does not involve boot0
<lennyraposo>
I can see how the source to boot0 kills alot of the upstart
hulu1522 has joined #linux-sunxi
<lennyraposo>
leave ATF to do it's thing
<lennyraposo>
on call and entering into EL3 properly
<lennyraposo>
boot
<lennyraposo>
done
<lennyraposo>
that means we can further change things up properly with U-boot say pointing to a usb drive for booting
<lennyraposo>
instead of just the MMC
<lennyraposo>
I am assuming
<lennyraposo>
u-boot can do that
<apritzel>
yes, U-Boot supports USB as well
<lennyraposo>
perhaps have a boot order
<lennyraposo>
fallback to this if this is not present
<apritzel>
think of U-Boot being similar to grub
<apritzel>
just loads the kernel from {disk, MMC, USB, network}
<lennyraposo>
so oyu can edit a settings file and alter to your content
<lennyraposo>
your liking I mean
<lennyraposo>
now that is useful
<apritzel>
U-Boot is very versatile and flexible
<apritzel>
you get a real shell
<lennyraposo>
just like grub 2
hulu1522 has quit [Remote host closed the connection]
<apritzel>
yes, similar
mosterta has quit [Ping timeout: 276 seconds]
<lennyraposo>
just reading up on u-boot
<apritzel>
but U-Boot is not really modular, you do all the configuration at compile time and load that single binary
<lennyraposo>
sort of like initrd
<lennyraposo>
exceptt with compiling
<lennyraposo>
a package with everything needed for the sbc
<lennyraposo>
the trusted firmware required aswell
<lennyraposo>
brb gotta bring my daughter to bed
<lennyraposo>
back in black
<apritzel>
on a proper system (ARM server) you have ATF in flash, doing the board initialisation
<apritzel>
it the loads EFI, which could be in flash as well (or on some disk)
<apritzel>
this does further setup, probably launching grub
<apritzel>
the point is that the Pine64 (and many other SBCs) have no flash on board
<apritzel>
so everything comes from the SD card, for instance
<apritzel>
including the firmware
<apritzel>
so traditionally there is no need for a proper firmware stack with clear and separated responsibilities
<apritzel>
instead U-Boot just does all the stuff ;-)
<lennyraposo>
the first parition (fat32 or any supported fs)
<apritzel>
Allwinner SoCs are hardwired to load 32KB from sector 16 of the SD card and execute this
<apritzel>
(if there is no NAND flash, that is)
<lennyraposo>
it's only personal fallback
<lennyraposo>
own* not only
<apritzel>
this is either boot0 or U-Boot's SPL
<lennyraposo>
I see why you want to discard the bsp provided
<lennyraposo>
unlocking this with mainline u-boot/kernel there would be no need for allwinner depndency
<apritzel>
indeed
<lennyraposo>
and if chip has done what it claims it has witht he vid driver
<lennyraposo>
mali that is
<lennyraposo>
wow
<apritzel>
traditionally booting on ARM is very board specific, there are no real standards
<lennyraposo>
dude I have learned a world of things today
<apritzel>
ARM64 tries to fix this
<apritzel>
so I'd rather go with that and do it right
<lennyraposo>
so as I see there are 3 main areas of focus required
<lennyraposo>
the boot0 source
<lennyraposo>
the ethernet
<lennyraposo>
and usb
<lennyraposo>
we have the cedarx stuff in hand
<apritzel>
and getting the firmware story right
<lennyraposo>
the dtb
<lennyraposo>
si that correct?
<lennyraposo>
dts
<lennyraposo>
I pretty much think of it as acpi like
<apritzel>
kind of
<apritzel>
.dts (the source) compiles into .dtb (the binary)
<apritzel>
and describes the hardware that is not plug-and-play
<apritzel>
which is basically everything on most ARM chips ;-)
<lennyraposo>
I can see the settings to everything
<apritzel>
also ARM has no standards, so the .dtb describes where the serial port is for instance
<apritzel>
has no standards => has no standard hardware addresses
<apritzel>
on x86 the first serial port is on 0x3f8 and the keyboard controller is port 0x60/0x61, VGA is at 0xA0000 and so on
<lennyraposo>
so theoretically I can assign whatever
<lennyraposo>
to any hex address?
<apritzel>
on ARM this is different for every board, and this is described in the DT
<apritzel>
the SoC vendor does this
<apritzel>
this is (hopefully) documented in the memory map
<lennyraposo>
so we have to match the soc vendors settings
<apritzel>
exactly
<lennyraposo>
strange how things play ball in android and the very same doesn't in linux
<apritzel>
so basically you take the manual and create a DT out of it
<lennyraposo>
good to have that on hand then
<apritzel>
I think modern Android uses DT as well
<apritzel>
you don't want to know what it did before DT ;-)
<lennyraposo>
longsleep had to play with a bunch of settings
<lennyraposo>
to fine tune it
<lennyraposo>
I htink for the ethernet and the thermal trip points
afaerber has quit [Ping timeout: 250 seconds]
<apritzel>
yes, DT is much more versatile than say ACPI, you can describe basically everything you want (with key=value pairs)
<apritzel>
that's why it is important to agree on the key part at least
<apritzel>
to avoid everyone defining their own
<lennyraposo>
don't tell me about acpi
<lennyraposo>
have had my fair share of battles with fixing cheap bios's that offer poor support outside the windows sphere
<apritzel>
me too ;-)
<apritzel>
go to arch/arm64/boot/dts and check out some examples
<lennyraposo>
I foudn that out the hardway with my toshiba purchase
<lennyraposo>
mainly becasue at the time for 300 bucks I got quad core apu
<lennyraposo>
5 years ago
<lennyraposo>
which repo
<lennyraposo>
main
<apritzel>
yes, mainline Linux
<lennyraposo>
I am browsing via browser atm
<apritzel>
enjoy, time to bring myself to bed here ;-)
<lennyraposo>
nice to see the supported vendors
<lennyraposo>
thanks apritzel
<lennyraposo>
between you and longsleep I should be caught when my boards are here
<lennyraposo>
and you will eb one more stronger in the ranks
<apritzel>
cu later!
<lennyraposo>
ciao
<lennyraposo>
haha
<lennyraposo>
no allwinner listed
<lennyraposo>
wish I knew back then what I know now
<lennyraposo>
then again hindsight is always 20/20
apritzel has quit [Ping timeout: 244 seconds]
afaerber has joined #linux-sunxi
hipboi has joined #linux-sunxi
<lennyraposo>
brb
lennyraposo has quit [Quit: Leaving.]
lennyraposo has joined #linux-sunxi
khuey is now known as khuey|away
hipboi has quit [Ping timeout: 260 seconds]
hipboi has joined #linux-sunxi
<lennyraposo>
just wanted to ask anyone who may know
<lennyraposo>
how many allwniner socs are near mainline ready (if I am using the term correctly)?
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #linux-sunxi
keh has quit [Ping timeout: 244 seconds]
mosterta has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
ninolein has quit [Ping timeout: 248 seconds]
ninolein has joined #linux-sunxi
KotCzarny has quit [Ping timeout: 260 seconds]
mosterta has quit [Ping timeout: 244 seconds]
Nyuutwo has quit [Remote host closed the connection]
Nyuutwo has joined #linux-sunxi
bwarff has quit [Read error: Connection reset by peer]
reev has joined #linux-sunxi
bwarff has joined #linux-sunxi
fredom is now known as poooooofs
KotCzarny has joined #linux-sunxi
reev has quit [Read error: Connection reset by peer]
p1u3sch1 has quit [Ping timeout: 246 seconds]
p1u3sch1 has joined #linux-sunxi
Shirasaka-Hazumi has quit [Ping timeout: 264 seconds]
hipboi_ has joined #linux-sunxi
hipboi has quit [Ping timeout: 250 seconds]
reev has joined #linux-sunxi
Shirasaka-Hazumi has joined #linux-sunxi
HeavyMetal has quit [Ping timeout: 250 seconds]
HeavyMetal has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
hipboi_ has quit [Ping timeout: 248 seconds]
hipboi has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
reinforce has joined #linux-sunxi
clonak has joined #linux-sunxi
<lennyraposo>
answered my own quesiton
<lennyraposo>
any recommendations for a git client under debian
<wens>
git?
<lennyraposo>
lol
<lennyraposo>
got that
<lennyraposo>
was look at some of the clients out there and was wondering if any clients come to mind under linux
<lennyraposo>
gui clients
<lennyraposo>
never used one before was just wondering
<wens>
i only use cli
<lennyraposo>
:)
<montjoie>
it is official the EMAC H3 answer ping now
<montjoie>
ssh comes soon
<lennyraposo>
wow
<lennyraposo>
apritzel and I were talking abotu that today
<wens>
montjoie: yay!
<lennyraposo>
if I am understanding correctly
<lennyraposo>
so you got the ethernet working
<montjoie>
yes
<lennyraposo>
wonder if the a64 can use the same approach
<montjoie>
just ssh wont work and I dont see why
<wens>
lennyraposo: it's the same hardware
<montjoie>
but ping work and ring buffer works
<wens>
try tcpdump?
<lennyraposo>
hence why apritzel mentioned it
<wens>
put it this way, if we can clean it up so it works on a83t, it should also work on a64
<lennyraposo>
figured that :)
<montjoie>
wens for a83t I need ac200
<montjoie>
and I2C
nemunaire has joined #linux-sunxi
<montjoie>
I will publich the last patch today
<wens>
montjoie: i have cubietruck plus, which uses rtl phy :)
<montjoie>
ok
<lennyraposo>
they use that rtl 8211e
<lennyraposo>
interesting
IgorPec has joined #linux-sunxi
<lennyraposo>
need to look into usb as well
<lennyraposo>
maybe datasheet o rmanual somewhere has some insight
iamfrankenstein has joined #linux-sunxi
leviathancn_szu has joined #linux-sunxi
<wens>
lennyraposo: usb for? a64?
<lennyraposo>
yep
<lennyraposo>
did not see any specific info
<lennyraposo>
just generic banter
<lennyraposo>
as I have no boards yet to tryout an dtest
<lennyraposo>
msot of my research is through reading and locating
<wens>
it mostly involes poking undocumented bits in the usb register space
<wens>
looking through the bsp is the only option
<lennyraposo>
so in other words
<lennyraposo>
kernel from bsp
<lennyraposo>
and poke it with a stick to see what happens
<lennyraposo>
get data
<lennyraposo>
adn identify
<wens>
bsp should work, just look through its code
<lennyraposo>
downloaded allwinners 24gb mess for the pine
<lennyraposo>
time to start goign through it all
<lennyraposo>
lol
Gerwin_J has joined #linux-sunxi
<lennyraposo>
I am impressed with you guys work on and fully understadn this ecosphere
<lennyraposo>
does anyoen here communicate with allwinner about anything?
<montjoie>
200 ping and after the void...
<lennyraposo>
it just drops?
<lennyraposo>
no response I mena
<lennyraposo>
mean
<lennyraposo>
man I need sleep
IgorPec has quit [Ping timeout: 268 seconds]
<montjoie>
no idea
<montjoie>
and I got a reply to the first ssh packet but my mainpc doesnt answer
<lennyraposo>
does your mainpc register any activity?
<lennyraposo>
from teh interface?
<lennyraposo>
porbably a stupid question but I had to ask
domidumont has joined #linux-sunxi
<montjoie>
tcpdump see nothing
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
IgorPec has joined #linux-sunxi
jernej has quit [Ping timeout: 252 seconds]
paulk-collins has joined #linux-sunxi
<KotCzarny>
montjoie: try pinging with different packet sizes?
cajg has joined #linux-sunxi
<mripard_>
montjoie: you spent a lot of time on this already, is there really a point in trying to have a driver working from scratch when allwinner's just need a bit of cleanup? ?
<montjoie>
mripard_: more than a bit of cleanup since no DT, etc.. and I wanted to be sure to understand all what I do
<mripard_>
montjoie: no DT is easy
<mripard_>
you've been struggling to get a few packets out of the thing for monthers
<mripard_>
and you'll probably have a lot of other bugs down the road
akaizen has quit [Remote host closed the connection]
paulk-collins has quit [Remote host closed the connection]
<montjoie>
the bugs that make me lose time was undocumented...
<montjoie>
so now we know it
poooooofs has quit [Ping timeout: 276 seconds]
<mripard_>
which is exactly my point.
<mripard_>
all the undocumented bits are already there
<KotCzarny>
in one he is right
<KotCzarny>
once undocumented become documented
mzki has joined #linux-sunxi
clonak has quit [Ping timeout: 240 seconds]
FDCX has quit [Ping timeout: 244 seconds]
<mripard_>
no one ever complained that the A10 EMAC had undocumented bits, however, everyone is very happy that it works
FDCX has joined #linux-sunxi
poffs has joined #linux-sunxi
clonak has joined #linux-sunxi
engideavr has joined #linux-sunxi
hipboi has quit [Ping timeout: 250 seconds]
<montjoie>
mripard_: I understand well your point of view, but I wanted to do something that can I be proud of it
hipboi has joined #linux-sunxi
<maz>
montjoie: doing something you are proud of is definitely commendable. doing something that is useful to others is even better.
enrico_ has joined #linux-sunxi
hipboi has quit [Ping timeout: 268 seconds]
cptG_ has joined #linux-sunxi
cptG has quit [Ping timeout: 248 seconds]
matthias_bgg has joined #linux-sunxi
matthias_bgg has quit [Remote host closed the connection]
matthias_bgg has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 248 seconds]
tomboy65 has joined #linux-sunxi
diego_r has joined #linux-sunxi
hipboi has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 248 seconds]
<KotCzarny>
let him code for fun
<maz>
KotCzarny: I'm not telling him what to do - that'd be stupid. I'm just stating that sometimes, it is better to gradually improve a code base (and get something off the ground quickly) than to start from scratch (and be stuck in the mud for too long).
<KotCzarny>
maz, how about linux-sunxi statement to ignore 3.4 b0rkage and focus on mainline only?
<maz>
KotCzarny: mainline is the only thing that matter. why do you think I'd think otherwise?
<buZz>
no mainline no glory
<KotCzarny>
maz, because that's the same story
<maz>
buZz: it's not about glory. it is about being useful in the long run. if it was about glory, I'd have stopped 20 years ago! ;-)
<maz>
KotCzarny: not quite. we're talking about lifting a random driver, improving it to make it useable with mainline.
<buZz>
maz: no use = no glory
<maz>
buZz: I don't get your drift, but nevermind.
<mripard_>
KotCzarny: discarding everything that Allwinner did just because it's Allwinner that did it and not someone else is a bit stupid
<mripard_>
they did some good stuff too
engideavr has quit [Quit: Konversation terminated!]
<KotCzarny>
is gmac driver by allwinner any good?
engideavr has joined #linux-sunxi
<keesj>
I have a few more "intersting???" questions.
<keesj>
I enabled spi and spidev on mainline kernel (a10 olimex lime board) and the device is functional however I have the kernel not happy about how I modified the device tree
<keesj>
mripard_: yea I looked a that but it is the same kind of device (e.g. a bus driver) while I need to tell spidev that the second port of of the SPI driver
cnxsoft has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has quit [Ping timeout: 260 seconds]
<montjoie>
tkaiser: I will update it soon
<montjoie>
I rebase my commits
mzki has quit [Quit: leaving]
Gerwin_J has quit [Ping timeout: 244 seconds]
Gerwin_J has joined #linux-sunxi
<cptG>
...my touch LCD is going crazy (reports input events even if I disconnect the touch panel completely) - is there a way to change sensitivity values that I might've accidentally changed?
<cptG>
sorry: allwinner A20, module sun4i-ts...
Hahaburger has joined #linux-sunxi
<lennyraposo>
reverse what was done done comes to mind
<lennyraposo>
sorry still a newb at all this here
Hahaburger has quit [Client Quit]
Gerwin_J has quit [Read error: Connection reset by peer]
Hahaburger has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
domidumont has quit [Read error: Connection reset by peer]
<lennyraposo>
looks liek I am getting a pine next week
<lennyraposo>
so I have ot grow upa lot faster
<lennyraposo>
;)
Netlynx has quit [Quit: Leaving]
khuey|away is now known as khuey
<montjoie>
ssh working:)
<montjoie>
maz: it was CRC:)
<tkaiser>
:)
<maz>
montjoie: a classic.
<maz>
montjoie: been there quite a few times.
<montjoie>
but long output like dmesg doesnt work
<montjoie>
I know what is it
hansg has quit [Quit: Leaving]
premoboss has joined #linux-sunxi
Sieb has quit [Quit: Page closed]
hulu1522 has joined #linux-sunxi
<apritzel>
montjoie: can you post a fixed version somewhere?
zuikis has joined #linux-sunxi
<lennyraposo>
was thinking the same thing apritzel
<lennyraposo>
need usb next
tomboy64 has joined #linux-sunxi
poffs has quit [Ping timeout: 244 seconds]
tomboy65 has quit [Ping timeout: 248 seconds]
diego_r has quit [Ping timeout: 248 seconds]
tomboy64 has quit [Ping timeout: 244 seconds]
nove has joined #linux-sunxi
slapin has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
hulu1522 has quit []
<slapin>
hi, all!
<slapin>
I see clock gates in device tree as <&ahb_gates 39> etc. how can I distinguish which is which
<slapin>
and how can I match clock output-names to gate bits?
<slapin>
also I see that clock gates are handled a bit differently on different hardware platforms, any ideas?
<slapin>
mripard_: ^^^
tomboy65 has joined #linux-sunxi
dev1990 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 260 seconds]
<apritzel>
slapin: in the ahb_gates nodes both clock-indices and clock-output-names are ordered in the same way
<apritzel>
slapin: the indention is the same, that helps you to match them
<slapin>
apritzel: I need to find clock gate and setting for CSI0 on Allwinner A13, per manual, it is bit 8 in AHB_GATING_REG1, offset 0x64, address 0x01C20064, and clock source / divider setting is at CSI_CFG_REG, 0ffset 0x134, addr 0x01C20134
vagrantc has joined #linux-sunxi
<slapin>
apritzel: the problem is which clock setting should I use for the peripheral in my device tree
tomboy65 has joined #linux-sunxi
apritzel has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 260 seconds]
<apritzel>
slapin: bit 8 in REG1 would be 40 then
Hahaburger has quit [Quit: Page closed]
<apritzel>
so that's already named as ahb_csi in the A13 .dtsi
<slapin>
apritzel: how are reserved bits hadled for output-names ? I see reserved values are just skipped, but there is no information about which are reserved...
<apritzel>
for the clock the usual approach is to find a similar clock and use that
<apritzel>
slapin: well, we just enumerate those that are documented and useful
<apritzel>
everything else is not needed anyway
<slapin>
apritzel: output-names usage of values in ouput-names is prohibited, clock names should be defined properly to be used by names
<slapin>
apritzel: there are reserved bits in the middle
<apritzel>
are you talking about the gates or the CSI clock?
<slapin>
apritzel: I need both
<montjoie>
normal, I post the patch and found a missing part (txstats)
<slapin>
apritzel: I need to enable CSI clock, so I need to both enable it and set to useful value
<apritzel>
slapin: I was wondering about what reserved bits you were talking
<apritzel>
so for the gate everything is fine, just use <ahb_gates 40>
<slapin>
apritzel: gating register does have a set of bits reserved, these are 4, 3, 11, 12, 15-19, 23-27, I wonder if output-names handles these
<apritzel>
slapin: why do you care those? they are just not enumerated and never used
<apritzel>
*about* those
<slapin>
apritzel: yeah, <ahb_gates 40> should work, but how about main clock? do we have PLL7 on A13? no such thing in DT...
<slapin>
apritzel: now my main interest is to enable CSI clock
<slapin>
apritzel: via DT
<apritzel>
Unless you find a similar clock, I am afraid you have to define your own one here
<slapin>
CSI_CFG_REG is quite similar to others...
<apritzel>
really? the reset bit 30 in there looks unique to me
<mripard_>
slapin: if you want pll7 you'll need my DRM series
<apritzel>
yeah, the DE clock looks similar
<slapin>
mripard_: where I can get these? any repository?
<tkaiser>
What about creating a Github account right now (4.5 just released) and push your work up there?
zuikis has quit [Remote host closed the connection]
<tkaiser>
That's on an Orange Pi PC with internal Ethernet PHY
<longsleep>
tkaiser: i will increase the Pine64 critical trip point to 108C or would you suggest lower?
tomboy64 has joined #linux-sunxi
<lennyraposo>
what's it at now?
<longsleep>
100C
<lennyraposo>
hwo often does it reach that temp without heatsink
<montjoie>
tkaiser: the phy seems ok (id 44), perhaps you hit the same bug then me with big frame
<montjoie>
tkaiser: does arp works ?
<longsleep>
lennyraposo: probably only with artifical load, so never as throttling will happen earlier
<longsleep>
lennyraposo: but i want to increase all trip points by 5C eventually
<lennyraposo>
why not 105
<lennyraposo>
you still stay within near a 20% temp buffer to max
tomboy65 has quit [Ping timeout: 244 seconds]
<lennyraposo>
just thinking from an engineers standpoint
<lennyraposo>
leave a decent safety margin
<longsleep>
lennyraposo: well the higher the better, and i am currently not using any hysteresis
<lennyraposo>
besides I am sur emost will add their own heat sinks or cooling methods if they are concerned about temps
<longsleep>
lennyraposo: and the board will just shut down at that level
<lennyraposo>
I go with your judegment
<lennyraposo>
as I am boardless fo rthe moment ;0
<lennyraposo>
and still elarning
<lennyraposo>
learning*
<longsleep>
i am only concerned about people using the pine without thinking anything and getting whatever enclosure and putting it next to their tv where it is already hot
<lennyraposo>
especially that biege looking thing
<lennyraposo>
I am assuming it has a cover
<lennyraposo>
so heat is just ogign to build up on those things
<longsleep>
yes
<lennyraposo>
along with that playbox case
tkaiser has quit [Ping timeout: 250 seconds]
<lennyraposo>
a case package like the acryliic one with small fan plus heatsink package would be a wise design for these things
<lennyraposo>
or at the very least some sort of heatsink to go with the playbox
<lennyraposo>
a thermal pad to disappate thing s a bit better
tkaiser has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
apritzel has quit [Ping timeout: 244 seconds]
<lennyraposo>
it's hard to tell what the case has ot offer space wise for addons
<longsleep>
no fan please, those make noise
<longsleep>
i hate noise
<lennyraposo>
and add to more power consumption
<lennyraposo>
heatsink
<longsleep>
fans are for overclockers if you ask me
<lennyraposo>
and properly ventillated case design
<longsleep>
decent heatsink should be recommended though
<tkaiser>
montjoie: More feedback tomorrow. I was lazy and let just built an Armbian image with your patches and no network came up
<lennyraposo>
the acryllic seems ot be the best the pine has thus far
<tkaiser>
longsleep: Why not 110¡C?
<lennyraposo>
and if it is working correctly it should be throttling before hand am I right?
domidumont has quit [Remote host closed the connection]
<longsleep>
tkaiser: sure, but the temperature sensor might be off in the wrong direction and i was choosing the middle between 105 and 110
<tkaiser>
107.5 then ;)
<lennyraposo>
don't they say 1 - 3 degree variance
<longsleep>
well i hate decimals as well
<lennyraposo>
I liekmultiples of five
<tkaiser>
lennyraposo: Did you read through the most misused github 'issue' ever already?
domidumont has joined #linux-sunxi
<lennyraposo>
nope
<longsleep>
hehe i was thinking about closing it :D
<longsleep>
err locking it, its already closed
* slapin
wonders why [PATCH] clk: Add regmap support is needed...
<lennyraposo>
perhaps a little guidance tkaiser
<tkaiser>
longsleep: It's a pull request, you can't close it ;)
<mripard_>
slapin: because we're using a clock backed by a regmap ?
bwarff has joined #linux-sunxi
<longsleep>
its better there than the stupid whatever BB board they have
<lennyraposo>
point me to materials and I will read and assimilate
<lennyraposo>
then ask questions to be sure that I am on the right track
<longsleep>
lennyraposo: well, you could read up about the thermal zone in mainline kernel and send apritzel merge requests for the mainline dts reflecting our changes :)
<tkaiser>
And today I realised that only vibrations matter. As soon as the small fan was hanging around on its cables in the air since BluTack wasn't strong enough I couldn't barely hear anything.
<tkaiser>
Logical consequence: I touched it with my finger later. That was fun :)
<lennyraposo>
I hate geting nipped by fans
bwarff has joined #linux-sunxi
<longsleep>
tkaiser: i liked the picture with the heatpipe most :)
<tkaiser>
It worked pretty well. I learned quite a lot about heat dissipation the last days.
<tkaiser>
And 'enclosure design' also
<lennyraposo>
be back in a bit
<lennyraposo>
liek the mathod of assigning trip points and the actions defined on what to do
<lennyraposo>
method*
<lennyraposo>
brb
<slapin>
mripard_: what benefits regmap give? as the support for it is not mainlined?
<slapin>
mripard_: also, do you plan to submit pll3 and pll5 support for next window?
<slapin>
where do we get A64 boards with worldwide delivery?
<longsleep>
tkaiser: commited 108C, with that the board should no longer shut down
<longsleep>
tkaiser: what about your HID problems? I checked and i think most of the stuff should already be enabled or do you need multi touch for magic mouse?
avph has joined #linux-sunxi
<mripard_>
slapin: you can access the same register space without worrying about concurrency
mossroy has joined #linux-sunxi
<tkaiser>
longsleep: No idea, but I'll fix it myself and only if it's a real issue I get back to you. Have to focus on other stuff the next time :)
<longsleep>
tkaiser: ok thanks - let me know if i have missed some important module
ricardocrudo has quit [Remote host closed the connection]
bonbons has joined #linux-sunxi
bwarff has quit [Ping timeout: 276 seconds]
paulk-collins has quit [Quit: Quitte]
jstein has quit [Remote host closed the connection]
<mripard_>
slapin: and yeah, I'd like to send a v3 sometime in the next weeks