<smaeul>
jernej: thanks, I will check those patches the next time I am looking at U-Boot
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
cnxsoft has quit []
<MoeIcenowy>
apritzel: BTW could you re-review the V853 sunxi-tools PR?
cnxsoft has joined #linux-sunxi
<apritzel>
MoeIcenowy: yes, it's on my list. On a first glance the addresses and the size looked a bit suspicious, and it would be much easier with a memory map
<apritzel>
MoeIcenowy: and that "/* Guessed values */" comment doesn't really help ;-)
<smaeul>
MoeIcenowy: no, I don't have any D1 boards with 2G of DRAM
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
szemzoa_ has quit [Remote host closed the connection]
moteen has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
<MoeIcenowy>
apritzel: I have now a memory map
<MoeIcenowy>
which says `SRAM C 0x00020000-0x00040FFF 132K (Using ISP SRAM)`
<MoeIcenowy>
but as I don't change anything there, they're really guessed values
<apritzel>
MoeIcenowy: do you know what areas the BROM FEL code uses? just the end? or something in the middle as well?
<MoeIcenowy>
apritzel: the end + 0x21000 IRQ stack
<MoeIcenowy>
I think this is every Allwinner ARM BROM uses
<MoeIcenowy>
(well every new ones)
<MoeIcenowy>
BTW RISC-V one does not have IRQ stack
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
<MoeIcenowy>
smaeul: BTW about R329 R-CCU
<MoeIcenowy>
should I reserve clock/reset slices for things difficult to verify now (and not documented in the user manual)?
<MoeIcenowy>
BTW should we just use some structural slice numer instead of sequence?
<MoeIcenowy>
apritzel: ^
moteen has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
<MoeIcenowy>
smaeul: I am thinking about not reserve them but document the oddity somewhere else
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
szemzoa has quit [Ping timeout: 480 seconds]
cnxsoft1 has joined #linux-sunxi
szemzoa has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
<wens>
DT maintainers are very against trying to have holes in the sequence so that they end up basically as the bit offsets
<wens>
probably not exactly what you are planning, but since the indices are just that, random indices, I don't see why you would need to reserve them
<apritzel>
tbh I find those made-up clock numbers quite problematic:
<apritzel>
for a start they are arbitrary, as they do not relate to the hardware
<apritzel>
and technically we would need to describe them in the binding, as they are part of it
<apritzel>
I was already thinking about using something like "register offset / 4", at least for the PLLs
<apritzel>
and some other, related scheme for the gates and mod clocks
<apritzel>
ah, I see that is mostly what MoeIcenowy meant ... ;-)
<smaeul>
the header is part of the binding, so they are already described in the binding
<smaeul>
since we have found that the current-generation CCUs are mostly subsets of a master design (at least for registers/offsets), we could reserve numbers based on that design
<smaeul>
but anything with many reserved numbers wastes space in the arrays
<apritzel>
agreed, it should be rather dense
<smaeul>
my ML comment to MoeIcenowy was about how we know that the PRCM has gates/resets in at bits 0/16 in registers 0x???c, even if we don't know what they are gates/resets for right now
<smaeul>
so I think we are somewhat in agreement, but I was only concerned about a limited subset
<apritzel>
I don't remember exactly, but are all bits implemented in those registers? for pinctrl you can query that, by writing all Fs to Px_CFGy_REG, and see which bits stick
<apritzel>
as implemented pins are constant 0s. is that the same for those gates/resets?
<wens>
the bits could be toggle-able, but nothing connected to them
<wens>
the hardware might be implemented in 8/16/32 bit multiples
<apritzel>
bits toggle-able: yes, but this is fine, I think, as we aim to have only one kind of super-set driver for those SoCs anyway (and already have, see the H616)
<apritzel>
on the H616 you can use the CSI interface, for instance, but the image would reflect the actual inside of the SoC: everything pitch black!
<gamiee>
lol :D
paulk-bis has joined #linux-sunxi
paulk has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
cnxsoft1 has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
paulk-bis has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
cp- has quit [Quit: Disappeared in a puff of smoke]
bauen1_ has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
cp- has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
moteen has quit []
moteen has joined #linux-sunxi
<MoeIcenowy>
well I am just against reserving some numbers in the random sequence
<MoeIcenowy>
I agree with a very dense sequence with what we implement
<MoeIcenowy>
I agree with very loose and self descriptive values
<MoeIcenowy>
but I think making holes in a dense sequence for TODOs not useful
<moteen>
Hello, I have been trying to connect the LICHEE RV board using UART but cant seem to have any output on minicom, I have built the image using https://linux-sunxi.org/Allwinner_Nezha#Manual_build adding linux kernel as well
<jernej>
what is the final price converted to eur or usd?
<jernej>
is it in range of 300 eur?
<gamiee>
as far as I calculated, yeah, 300 euro
<gamiee>
(with lcd)
<MoeIcenowy>
around ~300eur
<hramrach>
not sure the LCD is all that useful - depends on what you want to do with the board I suppose
apritzel has joined #linux-sunxi
rajkosto has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
apritzel has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
ftg has quit []
vagrantc has quit [Quit: leaving]
bauen1 has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
hentai has joined #linux-sunxi
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
hentai has quit [Max SendQ exceeded]
hentai has joined #linux-sunxi
rajkosto has quit [Read error: Connection reset by peer]
<smaeul>
in my experience, all toggle-able CCU gate/reset bits actually control some module. so once we determine which module that is, those bits are no longer TODOs
<smaeul>
I didn't want to block the driver on doing that investigation, but maybe it is worth doing up front?
<smaeul>
moteen: If you connect the OTG port to your computer, does a FEL device show up? If so, your SD card is not formatted correctly (SPL at the wrong offset, or you overwrote it with a GPT header). If not, most likely your minicom settings are the problem (make sure you are using 115200 baud).
<apritzel>
great, looks like the D1 and R528 (and their two little sisters) have the same SoC ID
<apritzel>
and as usual sunxi-fel needs some overhaul to deal with that ...
<apritzel>
xfel reads the first word of the BROM, with is either an ARM or a RISC-V instruction, so they can be told apart