<apritzel>
compiles and boots at least the SPL on a Pine-H64 (staying in AArch32)
jakllsch has quit [Quit: brb]
jakllsch has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
KyTiX has joined #linux-sunxi
KyTiX has quit []
rajkosto has joined #linux-sunxi
rajkosto has quit [Read error: Connection reset by peer]
mehdix has quit []
mehdix has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<smaeul>
U-Boot SPL works on D1! 68360 bytes for spl/u-boot-spl-nodtb.bin without any major size optimization, so it's big but not too huge. (SRAM is 160k.) This includes full DM and OF control.
<smaeul>
now that this is working, I can start upstreaming D1 support without worrying about TOC1 nonsense
apritzel has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
paulk-bis has quit [Ping timeout: 480 seconds]
evgeny_boger has quit [Ping timeout: 480 seconds]
paulk-bis has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
megi has quit [Quit: WeeChat 3.5]
megi has joined #linux-sunxi
paulk-bis has quit []
paulk has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
cnxsoft1 has quit [Ping timeout: 480 seconds]
paulk has quit [Quit: WeeChat 3.5]
paulk has joined #linux-sunxi
apritzel has joined #linux-sunxi
ftg has joined #linux-sunxi
MoeIcenowy has joined #linux-sunxi
<MoeIcenowy>
smaeul: do you have any idea how could we adapt existing dram codes of sunxi to SPL DM?
<MoeIcenowy>
cc apritzel
<MoeIcenowy>
I am thinking adapt my R329 DRAM code to let it work on D1 too
<apritzel>
MoeIcenowy: do you mean UCLASS_RAM? That doesn't look too complicated, we could have one driver support both interfaces
<apritzel>
MoeIcenowy: speaking of R329: is this still a thing? Do you plan on reposting some patches?
<MoeIcenowy>
apritzel: yes
<MoeIcenowy>
but maybe I should do kernel first
<apritzel>
MoeIcenowy: yeah, I was somewhat de-prioritizing the U-Boot patches because of the missing kernel support
<MoeIcenowy>
apritzel: BTW should we adapt them to UCLASS_RAM or should we just move them to board/sunxi/
<MoeIcenowy>
?
<MoeIcenowy>
adapt to UCLASS_RAM seems to be a big refactor
<MoeIcenowy>
okay I support the latter, adding DM to sunxi SPL isn't acceptable
<apritzel>
UCLASS_RAM seems to just require you to export base and size, and call sunxi_dram_setup() from the probe routine, that should be fairly easy
<apritzel>
MoeIcenowy: I mean we do this "support both DM and non-DM" already in the MMC driver
<apritzel>
it's not pretty there, but DRAM should be far easier. The most work would be for using DM clocks, I guess, maybe the regulator
Daanct12 has joined #linux-sunxi
<MoeIcenowy>
btw I think most code in arch/arm/mach-sunxi is really not arch dependent
<MoeIcenowy>
they should go otherwhere
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-sunxi
jelly has quit [Read error: Connection reset by peer]
jelly has joined #linux-sunxi
<apritzel>
MoeIcenowy: sure, no question about that
Daanct12 has quit [Quit: Leaving]
evgeny_boger has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
dliviu has quit [Read error: No route to host]
dliviu has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
paulk has quit [Ping timeout: 480 seconds]
paulk has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<machinehum>
apritzel: Thanks I'll give it a shot
<apritzel>
machinehum: I read somewhere that some devices have different addresses between V5 and H6, and you wanted to abandon SUN50I_GEN_H6?
<machinehum>
The memory map is different, unless I'm reading it wrong
<machinehum>
I havn't noticed any different addressed for periperals
<machinehum>
addresses
<apritzel>
what do you mean with "memory map is different", then? if the peripherals use the same addresses ...
<gamiee>
just wanted to ask this :D
<apritzel>
do you mean the U-Boot internal load addresses, for kernel_addr_r, for instance?
<machinehum>
In the V5 manual in section 3.1 there is a memory map, those addresses don't match up completely with the H6
<machinehum>
I'm not sure what kernel_addr_r is, I'll look around see what I can find
<apritzel>
machinehum: don't worry about kernel_addr_r, this is all handled by U-Boot
<machinehum>
Oh okay
<apritzel>
machinehum: if you are concerned about some addresses in cpu_sun50i_h6.h, quite some of them are not used
<apritzel>
I will have a look at the differences between the V5 and H6 later, if there are just a few, we can get away with them using #ifdef's, like we did for the H616
<machinehum>
Perhaps I should switch back to cpu_sun50i_h6.h
<gamiee>
btw, it's interesting that mainlining for V5 wasn't happening sooner. The Lindenis V5 devboard is out for quite a time.
<machinehum>
Lindenis sucks
<machinehum>
lol
<gamiee>
why?
<machinehum>
Because they naked forked uboot from 2014 didn't upstream anything and it doesn't even build anymore
<gamiee>
That's not Lindenis fault :D they're just using Allwinners BSP
<machinehum>
Then provided some Debian kernel 4.4 image
<machinehum>
Yeah fair enough, but if you're going to sell hardware you should make at least some effort to upstream the stuff
<gamiee>
anyway, the Lindenis V5 board is quite decent, and the sensors they're giving to it have really good quality (at least, the ISP is configured pretty well by default)
<machinehum>
Oh that board is great
<gamiee>
And when using armhf (not armel), it's quite fast too.
<machinehum>
Well it's lacking a lot of testpoints
<machinehum>
I talked to Lindenis, they claimed to have modern buildroot and uboot support
<gamiee>
machinehum: well, we should be happy, that lindenis at least published SDK with some documentation, if they wouldn't, there wouldn't be possible to get V5 SDK elsewhere. At least I don't know if any other company released SDk
<gamiee>
hmm, probably it will be just modern BSP from Allwinner most likely
<machinehum>
Fair enough
<gamiee>
The down-side of V5 is that I never was able to get full performance on H.265 4K encoding, it never worked fast enough.
<machinehum>
hmm
<machinehum>
My main interest in this board are the two Mipi busses
<machinehum>
I can't find anything else for the price
<gamiee>
Yes, as far as I remember, it works great :)
<machinehum>
Cool
<machinehum>
I actually got into contact to Allwinner, signed an NDA and they got me into contact with Sochip, they said the V5 is EOL and reccomended the V536
<machinehum>
But that looks to only have one mipi bus... so I guess I'll stick with with the V5 and hope I can buy enough parts off the secondary market
<gamiee>
Yes, V536 is recent one, have also better support, but only one mipi bus.
<machinehum>
rats
<machinehum>
You know anything about V5 supply chain?
<machinehum>
I found some people selling the chip on alibaba
<machinehum>
Seems... alright?
<gamiee>
no insight to that, but I would stick to what Allwinner and their partners says.
apritzel has quit [Ping timeout: 480 seconds]
<machinehum>
Fair enough, but it seems the V5 is the only part that works for my application, so I'll have to risk it
ftg has quit [Ping timeout: 480 seconds]
<gamiee>
i wish you good luck. It's good SoC, it just need some love.
<gamiee>
Even BSP is quite usable, only down-side is that everything is armel for some weird reason.
<machinehum>
Thanks, appriciate it
<machinehum>
Well hopefully someone else will one day find my work useful
JohnDoe_71Rus has quit []
apritzel has joined #linux-sunxi
machinehum has quit [Read error: Connection reset by peer]
machinehum has joined #linux-sunxi
ftg has joined #linux-sunxi
<apritzel>
machinehum: so I don't see any significant differences in the memory map, at least not as far as U-Boot (or rather just the SPL) is concerned
<apritzel>
for U-Boot proper we have the DT anyway, so any changes for USB or the missing PCIe would be covered there
<machinehum>
Need to run out now but I'm planning on working on this more tonight
<machinehum>
I'm also planning to try the diff you sent me
<apritzel>
machinehum: the pin controller looks quite different, though
<apritzel>
for a start UART0 is on PB9/PB10, not PH0/PH1 as on the H6
<apritzel>
I guess that's the debug UART you (or the BSP) is using?
<apritzel>
machinehum: (for when you are back): you would need to start much smaller, so as a placeholder just the H6 DT, or a *very* basic V5 DT, with just CPU, memory, UART
<apritzel>
and disable PSCI for now
<apritzel>
that probably requires some less trivial changes to work, so you have to live with UP for now
<apritzel>
in general the biggest work items for now would be the Linux pinctrl and clock drivers
<apritzel>
since also the clocks looks sufficiently different from the H6
<machinehum>
apritzel: Yeah PB9/PB10 are the uarts pins I'm using
<machinehum>
What do you mean by "UP?
<machinehum>
"UP"
<machinehum>
I was worried about the clocks... I guess I'll take a look right now
<apritzel>
UP = uniprocessor, the opposite of SMP: so just one core
<machinehum>
I see
<apritzel>
the clocks don't seem to be conflicting, so for U-Boot it's probably fine
<apritzel>
but the H6 has clocks that the V5 doesn't, and vice versa
<machinehum>
Say the next goal is: "see something on the uart", what would you say a logical starting point would be?
<machinehum>
I have the clock source code open, I was going to take a look through that
<machinehum>
clock_init_uart()
<machinehum>
Maybe
<apritzel>
yes, UART is the first step, I am actually surprised you don't see anything
<apritzel>
as long as you have the right pins and muxes selected, you should be good
<apritzel>
I doubt that the UART clock is different from the H6
<apritzel>
machinehum: if you are going to try my patch, you need to fix the UART mux setup, as this is still on the H6 pins (PH0/1)
<apritzel>
you have the right values in your code already
<machinehum>
I'll give you patch a go and change the dts