<apritzel>
In case someone is interested: I pushed a sunxi64-beta branch to my U-Boot github repo, with H5 support, FIT support and some new fancy stuff
<apritzel>
A README update is still missing though :-(
<apritzel>
also I pushed some fixes to the ATF repo
vicenteH has quit [Ping timeout: 245 seconds]
<swabbles>
apritzel: cool, might try that on my Pine :).
<swabbles>
if it also works on A64, at least.
<apritzel>
swabbles: yes, it targets the Pine64 primarily
<apritzel>
just combine spl/sunxi-spl.bin and u-boot.itb on a SD card
<swabbles>
I'll probably try this on Wednesday at work.
jernej has quit [Ping timeout: 264 seconds]
apritzel has quit [Ping timeout: 264 seconds]
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
deskwizard has quit [Remote host closed the connection]
deskwizard has joined #linux-sunxi
fdcx has quit [Ping timeout: 240 seconds]
fdcx has joined #linux-sunxi
cosm has quit [Remote host closed the connection]
mfa298 has quit [Ping timeout: 240 seconds]
mfa298 has joined #linux-sunxi
cosm has joined #linux-sunxi
deskwizard has quit [Remote host closed the connection]
deskwizard has joined #linux-sunxi
muvlon has quit [Quit: Leaving]
vishnup has quit [Ping timeout: 240 seconds]
cnxsoft has joined #linux-sunxi
Laibsch has quit [Read error: Connection reset by peer]
deskwizard has quit [Quit: disapeared.]
deskwizard has joined #linux-sunxi
<wens>
MoeIcenowy: for OpenRISC, you probably want to ask how to do interrupts (R_INT), and the interrupt number table
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
<wens>
MoeIcenowy: and maybe R_DMAC for the A80 if you can
<wens>
i think someone mentioned the A80 has a cortex-m instead of openrisc
Andy-D has quit [Ping timeout: 240 seconds]
dave0x6d has joined #linux-sunxi
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 276 seconds]
wzyy2 has joined #linux-sunxi
Laibsch has joined #linux-sunxi
wzyy2 has quit [Read error: Connection reset by peer]
muvlon has joined #linux-sunxi
stoned0651 has joined #linux-sunxi
pg12_ has quit [Ping timeout: 260 seconds]
pg12 has joined #linux-sunxi
chomwitt has quit [Ping timeout: 256 seconds]
<stoned0651>
Is the I2s codec support for ESP32 available ?
tlwoerner has joined #linux-sunxi
tlwoerner_ has joined #linux-sunxi
IgorPec has joined #linux-sunxi
tlwoerner has quit [Client Quit]
tlwoerner_ is now known as tlwoerner
stoned0651_ has joined #linux-sunxi
victhor has quit [Ping timeout: 252 seconds]
stoned0651 has quit [Quit: Page closed]
lurchi_ is now known as lurchi__
Laibsch has quit [Read error: Connection reset by peer]
stoned has joined #linux-sunxi
stoned is now known as Guest2748
terra854 has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 252 seconds]
stoned0651_ has quit [Ping timeout: 260 seconds]
TheSeven has quit [Ping timeout: 256 seconds]
[7] has joined #linux-sunxi
lkcl has joined #linux-sunxi
reinforce has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
<beeble>
wens: yes, a80 has a cortex instead of the openrisc
Gerwin_J has quit [Client Quit]
<KotCzarny>
ARM Cortex-M3 (to be verified)
<KotCzarny>
can you verify that?
Laibsch has joined #linux-sunxi
<KotCzarny>
willmore: oh fun, it's less than 2% error when clocked to 32k though ;)
jernej has joined #linux-sunxi
<beeble>
KotCzarny: we have code running on it, so i think thats a verification :)
<KotCzarny>
please edit wiki the if you have a moment (maybe add some details etc)
<KotCzarny>
*then
muvlon has quit [Ping timeout: 245 seconds]
jernej has quit [Quit: Konversation terminated!]
jernej has joined #linux-sunxi
<jernej>
MoeIcenowy: A83T HDMI code is released under GPL, so no secrets there
muvlon has joined #linux-sunxi
IgorPec has quit [Ping timeout: 252 seconds]
f0xx has joined #linux-sunxi
stoned0651 has joined #linux-sunxi
ganbold has quit [Remote host closed the connection]
Guest2748 has quit [Ping timeout: 260 seconds]
jernej has quit [Ping timeout: 255 seconds]
tlwoerner_ has joined #linux-sunxi
tlwoerner_ has quit [Changing host]
tlwoerner_ has joined #linux-sunxi
tlwoerner has quit [Ping timeout: 252 seconds]
tlwoerner_ has quit [Ping timeout: 260 seconds]
HeavyMetal has quit [Ping timeout: 276 seconds]
ganbold has joined #linux-sunxi
tlwoerner_ has joined #linux-sunxi
<MoeIcenowy>
jernej: I remembered A83T uses unobfuscated DW HDMI, right?
HeavyMetal has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
HeavyMetal has quit [Changing host]
msevwork has joined #linux-sunxi
<wens>
oh my, looks like i may need to implement BFS for of graphs
JohnDoe_71Rus has joined #linux-sunxi
huawei has joined #linux-sunxi
<plaes>
BFS?
<plaes>
graphs?
<KotCzarny>
big-frigging-sheduler?
paulk-collins has joined #linux-sunxi
<plaes>
no, I assume it's breadth-first-search
<wens>
plaes: correct
<wens>
seems i can get away with not doing it
<KotCzarny>
where would it be needed?
<wens>
KotCzarny: i need to ensure all display backends get probed/bound before any tcons are probed/bound
stoned0651 has quit [Ping timeout: 260 seconds]
<plaes>
wens: does it involve also a10/a20? ;)
<wens>
plaes: yes, i'm doing cleanup for dual display pipeline support
<plaes>
cool
<rellla>
seems 2017 gets another sunxi year :)
<wens>
plaes: there's a lot of code movement involved
<MoeIcenowy>
oh I think nearly all SoCs with DE2 have also dual pipeline...
<MoeIcenowy>
except V3s, which only have one TCON ;-)
<jelle>
btw did anyone add that composite out git repo for the orange pi zero to the wiki?
<plaes>
um..no
<jelle>
I forgot who it was who worked on it
<plaes>
wens: this was one of the reasons I wanted to get preliminary LVDS support in :S
<jelle>
ah it was agin_
<rellla>
MoeIcenowy: is the deinterlacer sunxi-di also of interest?
<plaes>
yeah
<MoeIcenowy>
rellla: sorry, but I still do not know what deinterlace is
<rellla>
i suppose it now uses a separate hardware block, iirc on DE1.0 it was included in the display engine
<MoeIcenowy>
P.S. I think we need some more "mainlining effort" matrixs
<MoeIcenowy>
at least one for AXP, and one for peripherals
<montjoie>
peripherals ?
<MoeIcenowy>
oh I mean external hardwares
<MoeIcenowy>
e.g. Wi-Fi, Touchscreen and so on
<plaes>
like?
<plaes>
ok
IgorPec has joined #linux-sunxi
<plaes>
MoeIcenowy: it's quite a work to actually keep the sunxi-related stuff up-to-date..
<MoeIcenowy>
yes...
<KotCzarny>
plaes: can it be automated somehow?
<wens>
rellla: is there any documentation for the deinterlacer?
<mripard>
I don't see why we need the peripherals
<mripard>
this is going to be a nightmare to maintain across all boards
<rellla>
wens: we have that source code i linked, but it has no/restricted license in the hardware/register parts
<mripard>
PMIC and DRM definitely make sense though
<rellla>
wens: i haven't found any docs in user manuals and no sample usage code for ./char/sunxi-di using it with DE2.0
<MoeIcenowy>
I even do not know what does it do :-(
<KotCzarny>
MoeIcenowy: imagine 50 scanlines
<KotCzarny>
no imagine updating only even ones at frame one
<rellla>
wens: though we got it work with DE1.0 (kernel 3.4) at the time of DE1.0(A20)
<KotCzarny>
*now
<KotCzarny>
and odd ones at frame two
<MoeIcenowy>
the deinterlace really mean the opposite of interlace?
<KotCzarny>
and even ones at frame three
<MoeIcenowy>
I know interlace ;-)
<KotCzarny>
now deinterlace tries to make it look good on planar without artifacts
<MoeIcenowy>
but I thought deinterlace as "Display Engine" interlace...
<rellla>
MoeIcenowy: it should compose two interlaced half-frames (e.g. from a tv stream) to a complete frame which is "viewable"
<KotCzarny>
nope, it's to remove interlace
<MoeIcenowy>
ok I know it...
<rellla>
it should be a next step towards multimedia functionality, once display support is ready...
<KotCzarny>
but honestly, i haven't seen interlaced material since long time
<rellla>
KotCzary: 1080i, 576i
<KotCzarny>
rellla, but are those used?
<KotCzarny>
and by used i mean 'in videos you see on the internet'
<rellla>
yes in DVB-S2 TV streams.
<rellla>
and problay no/ not much 'in videos you see on the internet'
BenG83 has quit [Quit: Leaving]
<MoeIcenowy>
it's now the date of IPTV ;-)
<KotCzarny>
that's what i meant by internet too
<plaes>
mripard: how similar are A13 and A10/A20 clocks?
<plaes>
regarding the clk-ng ;)
<wens>
there's probably extra clocks, but otherwise should be pretty similar
<wens>
it's hard to share the drivers though, as the header has clock indices for the dt bindings, and you probably can't have 2 sets of conflicting ones in the same driver
<mripard>
what wens said :)
<rellla>
KotCzarny, MoeIcenowy: i'm oldschool television user... *duck*
<MoeIcenowy>
now A10/20 is the latest to get clk-ng ;-)
<KotCzarny>
rellla: where do you get your interlaced signal from? ;)
<rellla>
DVB-S2
<KotCzarny>
is any allwinner product touching it somehow?
Andy-D has joined #linux-sunxi
<MoeIcenowy>
at least I think H3 have the hardware capability to read DVB
florianH has joined #linux-sunxi
<MoeIcenowy>
although no mainline driver now ;-)
<plaes>
also A10/A20 might have it
<plaes>
transport stream?
<MoeIcenowy>
yes...
<rellla>
plaes, yes TS stream.
<plaes>
is 'TS stream' another example of the RAS Syndrome?
<rellla>
http://tvdr.de/ is the main software and then it's decoded and displayed (and deinterlaced) using libvdpau-sunxi
<wens>
problem is there aren't any products pairing allwinner chips with DVB tuners
<MoeIcenowy>
everyone is wasting some part of an Allwinner SoC ;-)
<rellla>
user woppr started TS stream support but dropped it imho
<MoeIcenowy>
especially A10/A20 is the most critical area of the waste ;-)
leon-anavi has joined #linux-sunxi
<leon-anavi>
morning
<wens>
i would really love to get my hands on one, since we use DVB-T here
<plaes>
MoeIcenowy: you mean wasting our time? or...
<rellla>
wens: get a DVB-T receiver card :p
<MoeIcenowy>
plaes: wasting the hardware
<plaes>
ah..;)
<KotCzarny>
MoeIcenowy: not enough bandwidth to to everything at once ;)
<KotCzarny>
*to do
<wens>
rellla: that doesn't hook up to the TS block on the chip :p
<rellla>
yeah, it doesn't
<rellla>
H3 and newer are interesting SoCs for the upcoming german DVB-T2 because of the HEVC decoder ...
<MoeIcenowy>
we in mainland China have already evolved into IPTV...
<MoeIcenowy>
some people even do not go to broadcasting company to apply for TV route, instead buy an Android OTT box ;-)
<MoeIcenowy>
(although most of the OTT boxes are using Amlogic SoCs
<wens>
MoeIcenowy: iirc some of the content is unlicensed? :p
<MoeIcenowy>
wens: sometimes
<MoeIcenowy>
but now the permission to make OTT box is restricted
<MoeIcenowy>
and the vendor pays for the content
<MoeIcenowy>
then earn the money back by using fee or ad
<wens>
it's either cable or MOD (ISP-based IPTV) here, but cable is not always digital, and digital cable standards are non-existent
<MoeIcenowy>
analog cable also exists here
<MoeIcenowy>
but digital cables have nearly never exist
<KotCzarny>
who watches tv in the era of the internet
<wens>
the cable provider gives you a shitty set top box you can't switch out
<wens>
KotCzarny: true
<MoeIcenowy>
it's also the situation of cable TV users in mainland China ;-)
<KotCzarny>
nowadays tv is mostly ads and political tube with some cheap entertainment between
<MoeIcenowy>
(P.S. my home bought a TV with android, with very small RAM, and cannot run smooth at all
<MoeIcenowy>
(although TV cable is also applied, analog
<wens>
KotCzarny: my dad watches sports on TV
<MoeIcenowy>
P.S. some AW SoCs seems to have the ability to decode analog TV?
<KotCzarny>
wens: yeah, previous gen, will fade out in 10-20 years
<MoeIcenowy>
(although it may date back to the era when analog TV signals are not encrypted...
<wens>
MoeIcenowy: there's a tv decoder in the early chips, but that probably only does CVBS
<MoeIcenowy>
CVBS only? ah-oh
<wens>
maybe component
<wens>
still, not very useful...
<MoeIcenowy>
yes, as a CVBS decode card now only costs $5, at least in China ;-)
<wens>
the later chips don't have it, so they add a decoder chip connected to CSI
<MoeIcenowy>
is the decoder in the std design?
<MoeIcenowy>
(I think in H8 OTT solution the composite out is even in external chip?
<MoeIcenowy>
maybe sun8iw6(A83T) is the AW SoC with most name ;-)
<wens>
A83T ~ H8
<wens>
don't know what the difference is
<MoeIcenowy>
I've heard that the SoC ID is different?
<wens>
they are paired to almost identical PMICs, AXP813 and AXP818
<wens>
yeah, composite out on H8 is in the AC200 chip, which has no docs
<MoeIcenowy>
P.S. V66, R58, T8 seem to be also sun8iw6
<MoeIcenowy>
and so-called "H8vr"
<KotCzarny>
oh wow, bootargs can be passed via DT o.o
<plaes>
KotCzarny: also via sunxi-fel
<MoeIcenowy>
but A83T maybe a very valuable choice now, because of its 28nm process, except for bad mainline support...
<MoeIcenowy>
if one have done a PSCI support for A83T, I will purchase a board with it (maybe BPi M3)
<KotCzarny>
plaes, yeah, though i use boot.scr for that
<MoeIcenowy>
KotCzarny: bootargs is originally designed to be passed by via DT in systems without ATAGs
<MoeIcenowy>
what did in U-Boot is to write the "bootargs" uboot env's content to DT
<plaes>
KotCzarny: you need extra "compile" step for boot.scr
<MoeIcenowy>
plaes: yes, that's why I like uEnv-style data ;-)
<KotCzarny>
plaes, that's nice for initial work, but on final device you would use dt or uenv/scr on local storage
<plaes>
yes
<wens>
MoeIcenowy: A83T has 2 revisions, with opposite power controls
<wens>
which is going to bloat PSCI code
<wens>
but there was some A83T PSCI code on the mailing list in case you want to try
<wens>
mripard: hmm, i'm not sure why we have a separate sun4i_framebuffer file
<MoeIcenowy>
WHAT THE HELL...
<MoeIcenowy>
where's the document of the 2 revs?
<wens>
MoeIcenowy: there isn't any
foxx has joined #linux-sunxi
<wens>
it's probably somewhere in the code dump
<mripard>
wens: I wanted to split as much as possible to avoid having a big file
<mripard>
and did by feature / component
<mripard>
this one is pretty small, but we might extend it in the future as well
<MoeIcenowy>
mripard: P.S. I found that it seems difficult to reuse sun4i-tcon in sun8i-de2-drm driver
<wens>
mripard: i need to move drm_mode_config_cleanup out of there
<mripard>
MoeIcenowy: why?
<MoeIcenowy>
mripard: there's many calls across files
<wens>
i wonder if rockchip's vop block has the RGB interface
<mripard>
wens: ok, then please do so :)
<mripard>
MoeIcenowy: what's difficult about that?
<mripard>
the only thing that would be troublesome would be the TCON -> backend calls
<mripard>
but there's not a lot of them iirc
<mripard>
exactly 1, in the TCON / CTRC code
<mripard>
or are you talking about something else ?
<MoeIcenowy>
but it's difficult to judge whether a TCON is used with sun4i-backend or sun8i-de2
foxx has quit [Ping timeout: 256 seconds]
fkluknav has joined #linux-sunxi
<wens>
i think a bigger issue would be link failures if you only enabled de1 or de2
<wens>
you would need to add stub functions
<MoeIcenowy>
maybe we should merge them into one driverset ;-)
<MoeIcenowy>
I used to think to implement a mixer as a replacement of tcon
<wens>
you still have the tcon regardless
<MoeIcenowy>
s/tcon/backend
<MoeIcenowy>
but after jernej told me that the relationship of mixers and tcons can be switched by DE2_CCU_SEL register, I thought it as a difficult thing...
f0xx has quit [Ping timeout: 264 seconds]
<MoeIcenowy>
(my original design is to have DE2 CCU as a CCU driver (as it really looks like A80 DE CCU), then implement two mixers as a replacement of backend
<mripard>
MoeIcenowy: but we don't really care which backend is being used once the init is done, do we?
<MoeIcenowy>
yes
<MoeIcenowy>
so it's the reason of my original design
<mripard>
so the only thing you really need is to have different init functions
lemonzest has joined #linux-sunxi
<mripard>
with different compatibles
<MoeIcenowy>
the found of DE2_CCU_SEL broke my dream
<mripard>
which are going to call different probes anyway
<mripard>
so I really don't know what's difficult about that
<MoeIcenowy>
so that it's needed to implement the whole DE2 as a driver, not a single mixer
<MoeIcenowy>
the DE2 may have two outputs, to two TCONs
<MoeIcenowy>
when DE2_CCU_SEL's bit0 is 0, mixer0 is connected to tcon0, mixer1 to tcon1
<MoeIcenowy>
but when the bit0 is 1, mixer0 is to tcon1, mixer1 is to tcon0
lkcl has quit [Ping timeout: 255 seconds]
<MoeIcenowy>
or maybe we can just hardcode DE2_CCU_SEL to 0
<MoeIcenowy>
(but the problem is that mixer1 is weaker than mixer0
<wens>
whether it's a single driver/device or separate instances it really doesn't matter
<wens>
a device can register multiple drm objects
<mripard>
MoeIcenowy: do we care about that?
<mripard>
is there any use case where we would want to switch the two?
<mripard>
(and then, if there is, do we need to support it from day one?)
<MoeIcenowy>
mripard: mixer1 have only 1 UI channels, but mixer0 have 3
<MoeIcenowy>
and some functions, for example, "write-back", is only available on mixer0
<mripard>
then is there any point in supporting the mixer one from the beginning ?
<MoeIcenowy>
you mean support the mixer1 or support the mixer exchange?
<MoeIcenowy>
although I think in the beginning we can ignore the mixer exchange
<KotCzarny>
but maybe check for such case?
<wens>
MoeIcenowy: you can always just support mixer0 from the start, like what we have for sun4i
<wens>
unless some chips don't have mixer0 :|
<KotCzarny>
so at least you will know when things go broken
<MoeIcenowy>
wens: mixer0 will always exist
<wens>
then forget about mixer 1 and the exchange in the first version
<MoeIcenowy>
wens: but to make use of all outputs, maybe we need to support the mixer exchange function?
<MoeIcenowy>
P.S. support for mixer1 is as easy as support for mixer0
<MoeIcenowy>
the only difficult thing is exchange
<wens>
MoeIcenowy: exchange is not that difficult, it's what I'm going to do soon for sun4i
<MoeIcenowy>
P.S. if we really do a driver with only support for mixer0, we will support only LCD on A83T/A64, and support only HDMI on H3
<mripard>
wens: I'm not sure what you call exchange
<MoeIcenowy>
V3s is the easiest situation, as it have only one mixer connected to one TCON (LCD)
<mripard>
MoeIcenowy: it's your call, either you want to support all the features from the very first iteration, and it will take a long time to develop and merge
<mripard>
or you do it gradually
<mripard>
start small, and then build on top of that
<MoeIcenowy>
ok I think at the first I will ignore the exchange function
<wens>
mripard: the mux for tve and hdmi
<MoeIcenowy>
hardcode mixer0 to tcon0, and mixer1 to tcon1
<mripard>
wens: ok
<MoeIcenowy>
wens: in fact it's the mux for tcon0 and tcon1.
<mripard>
MoeIcenowy: as long as you keep the possibility open and design your code to be quite easy to extend
<mripard>
I've found the second solution to work better
<wens>
yeah, probably not the same as the tve and hdmi mux
<MoeIcenowy>
so maybe I will start my work from V3s ;-)
<MoeIcenowy>
V3s have only one mixer ;-)
Andy-D has quit [Ping timeout: 245 seconds]
<MoeIcenowy>
I have already done the driver for the clock control of DE2 as a sunxi-ng ccu driver
<wens>
doing a clock driver is nice, but not always necessary
<wens>
like we don't have one for the internal dividers in some hardware blocks
<Bocus>
pin6 of the 1x13 pin header is USB-DP3, not (as the wiki says) USB-DP2
<Bocus>
i don't have a login for the wiki and am not gonna create one just for that, so i can't edit the page. if anyone here happens to edit the wiki from time to time, it might be of interest to other users to correct that littke typo
<ssvb>
Allwinner boards are also using the DDR2 T-topology even with DDR3 chips instead of Fly-by
<ssvb>
beeble: but I guess there is no ZQ calibration on the DDR2 chip side, so it's implemented half-way
<beeble>
correct
<beeble>
fly by is more interessting for DRAM modules
<beeble>
imho
<ssvb>
yes, and it's perfectly reasonable to use a mix of features from different standards
cnxsoft has quit [Quit: cnxsoft]
<beeble>
for single board designs t-topology is more straight forward and reduces the "overhead" of calibration
<beeble>
at least thats my look on things
<terra854>
Anyone got a SoPine here?
<terra854>
Or the Pinebook?
<willmore>
I've been pining for the fjords.
<terra854>
What's with the THS in the status matrix?
<willmore>
What about it?
<terra854>
There are some fields in the status matrix that has "THS" written on it
<terra854>
I wonder what that means
<terra854>
In the mainlining effort page
<willmore>
That's the thermal settings. So, clock frequency/voltage table and the cooling table.
<willmore>
From a code side it can mean the driver for the voltage controller chip (PMIC) as well.
<willmore>
The A series chips use tablet style PMIC chips which are more complex--as you'd expect from a tablet with lots of things to control.
<willmore>
The H series use simpler PMIC chips as they're meant for set top box applications which are simpler.
fkluknav has quit [Ping timeout: 260 seconds]
victhor has joined #linux-sunxi
<terra854>
BTW for the VE driver, are you guys reverse engineering the code or you copy-paste the code from BSP and improve on it?
<willmore>
I don't know as I'm not a developer, but I don't believe any code is being copy/pasted as the license for the original code is always a bit iffy. Also, there's a lot of changes in the kernel since then, so old code isn't really suitable for mainline.
paulk-blaze has quit [Ping timeout: 256 seconds]
<wens>
willmore: nah, it means the thermal sensor
<willmore>
wens, ahh, just that? okay.
<terra854>
For the mainlining effort are you guys reverse engineering the code or you copy-paste the code from BSP and improve on it?
leviathancn has joined #linux-sunxi
<wens>
terra854: which part?
<terra854>
Well, all the driversin general
<willmore>
wens, he's looking at A64
<mripard>
terra854: it depends, we've been doing both
<mripard>
the MMC driver for example has been the one from allwinner that was cleaned up
<Macer>
hm. i'm a little stuck on how i manage the network with armbian on the opi+2e
<Macer>
i'm just trying to configure the ethernet
fkluknav has joined #linux-sunxi
<terra854>
So for the reverse engineering parts, do you guys refer to the BSP code or is it clean-room?
<wens>
often look at the BSP code
paulk-blaze has joined #linux-sunxi
paulk-blaze has quit [Read error: Connection reset by peer]
<terra854>
Can't seem to tell from there if increasing freq beyond 1.15 is possible...
<BenG83>
I have never looked at the PLL and clock config in the user manual so far
<BenG83>
should probably do that at some point
<BenG83>
there are derived clocks though
<beeble>
the pll goes up to 2.1ghz
<BenG83>
APB clock is derived from CPU it seems
<BenG83>
and there is a AXI-AHB bridge
<BenG83>
the A64 has a pretty convoluted internal bus structure imho
<ssvb>
terra854: you can increase the CPU clock frequency beyond 1.15GHz (this requires some core voltage increase too), but the biggest problem is the current draw and power consumption at this operating point
<ssvb>
people tried to experiment with this, but the results were discouraging
<MoeIcenowy>
BenG83: it's a usual SoC with AXI, AHB and APB
<ssvb>
BTW, the Pine64 board was advertised as 1.2GHz, so people were really motivated to at least try to make it working reliable
<BenG83>
I think the stock image that came with my PB prototype did go to 1.2Ghz
<jernej>
rah: I'm not really familiar with any dram init code
<apritzel>
rah: think of SPL replacing boot0
<rah>
jernej: ok, thanks
<jernej>
rah: that pdf might not be the clearest description. apritzel's explanation is better
<rah>
I get it, it's just an earlier stage
<rah>
thanks
<apritzel>
rah: despite boot0 being apparently board specific, it's mostly setting generic and failsafe DRAM settings (DDR3/1333 on newer boards)
<apritzel>
which is what we do in U-Boot as well
<apritzel>
though this will possibly change now
<rah>
apritzel: change how? not do it in U-Boot?
<apritzel>
rah: the BROM just loads 32KB and at this point there is DRAM up, so the SPL is fixing this
<apritzel>
rah: no, making it board specific or autodetected
<apritzel>
for instance all A64 boards use DDR3 1600 DRAM chips
<rah>
ok
<rah>
apritzel: what is it now, if not board specific or autodetected? :-)
<apritzel>
rah: "... and at this point there is _no_ DRAM up" it's supposed to mean above
<apritzel>
rah: fixed values per SoC
<beeble>
apritzel: 1600 is not sufficient info. you should also know the speed bin
<beeble>
that could differ from board to board
<rah>
apritzel: ah I see
<apritzel>
rah: every A64 (and H3) sets up some slightly dodgy DDR1333 timings
<apritzel>
beeble: sure, but at this level of discussion I consider this as a detail ;-)
<beeble>
should read the full backlog, sorry :)
<apritzel>
but isn't 1600 already the speed bin and it's the CAS latency that differs?
paulk-collins has quit [Quit: Leaving]
<beeble>
no. the cas latency differs by the speed bin. aber for example there is 1600G 1600H 1600J as defined by jedec. this is usualy translated into something vendor specific. micron has endings like -125 -125E for example