rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi - *only registered users can talk*
<karlp> or, use uboot spl, than run your app instead of "uboot main"
<catphish> i might look into that
dmnq has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
dmnq has quit [Remote host closed the connection]
marcodiego has joined #linux-sunxi
dmnq has joined #linux-sunxi
dmnq has quit [Remote host closed the connection]
dmnq has joined #linux-sunxi
dmnq has quit [Remote host closed the connection]
dmnq has joined #linux-sunxi
nuuuciano has quit [Remote host closed the connection]
<tautologico> I remember there being some juggling with memory involved because FEL support itself uses some regions of SRAM
<tautologico> accessing flash memory directly (as in raw nand) is pretty involved too
dmnq has quit [Remote host closed the connection]
dmnq has joined #linux-sunxi
tllim has quit [Read error: Connection reset by peer]
Da_Coynul has joined #linux-sunxi
Da_Coynul has quit [Client Quit]
random_yanek has quit [Ping timeout: 244 seconds]
dmnq has quit [Remote host closed the connection]
dmnq has joined #linux-sunxi
dmnq has quit [Ping timeout: 272 seconds]
random_yanek has joined #linux-sunxi
dmnq has joined #linux-sunxi
dmnq has quit [Read error: Connection reset by peer]
nuuuciano has joined #linux-sunxi
xes_ has quit [Quit: bye..]
xes has joined #linux-sunxi
popolon has quit [Quit: WeeChat 2.3]
Dawidek26 has joined #linux-sunxi
Dawidek26 has quit [Ping timeout: 246 seconds]
_whitelogger has joined #linux-sunxi
leviathanch has joined #linux-sunxi
Andy-D has quit [Remote host closed the connection]
dmnq has joined #linux-sunxi
nashpa has quit [Ping timeout: 272 seconds]
dmnq has quit [Ping timeout: 268 seconds]
lurchi_ is now known as lurchi__
nashpa has joined #linux-sunxi
dmnq has joined #linux-sunxi
dmnq_ has joined #linux-sunxi
<wens> megi: cool. I have RGB565_2X8_BE working, but not RGB555. ov5640 driver doesn't do that
allohol0 has joined #linux-sunxi
allohol0 has quit [Remote host closed the connection]
marcodiego has quit [Quit: Leaving]
kelvan has quit [Remote host closed the connection]
merlin1991 has quit [Read error: Connection reset by peer]
merlin1991 has joined #linux-sunxi
kelvan has joined #linux-sunxi
dmnq_ has quit [Remote host closed the connection]
lurchi_ has joined #linux-sunxi
dmnq_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 245 seconds]
dmnq_ has quit [Ping timeout: 250 seconds]
vagrantc has joined #linux-sunxi
IgorPec has joined #linux-sunxi
f0xx has joined #linux-sunxi
dmnq_ has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
dmnq_ has quit []
aalm has quit [Read error: Connection reset by peer]
nuuuciano has quit [Read error: Connection reset by peer]
nuuuciano has joined #linux-sunxi
reinforce has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
hanetzer has quit [Remote host closed the connection]
hanetzer has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
nuuuciano has quit [Ping timeout: 246 seconds]
User998_ has joined #linux-sunxi
User998_ has quit [Remote host closed the connection]
Mandragor has quit [Read error: Connection reset by peer]
<MoeIcenowy> btw I has cooperated with people from RT-Thread to use U-Boot SPL to boot RTT on F1C100s
clemens3 has joined #linux-sunxi
scelestic has joined #linux-sunxi
vagrantc has joined #linux-sunxi
chomwitt has joined #linux-sunxi
IgorPec has quit [Ping timeout: 244 seconds]
BenG83 has quit [Ping timeout: 250 seconds]
clemens3 has quit [Remote host closed the connection]
alexxey has joined #linux-sunxi
<alexxey> Is it possible to convert boot.scr to boot.cmd?
<KotCzarny> yes
<KotCzarny> just remove few bytes from the start
<JuniorJPDJ> or use mkimage again
<KotCzarny> nah, mcedit will do
<arti> just cat the boot.scr file and copy the boot script
<catphish> dd if=boot.scr of=boot.cmd bs=72 skip=1
<catphish> according to ubuntu, it's 72 bytes to be removed and the rest is just text
Andy-D has joined #linux-sunxi
<alexxey> Oh!... Thanks, problem solved!
<catphish> i'm still struggling with memory speed, write through seems unbearably slow, i think what i need to do is use write back so that the writes are buffered through the cache then clean it once i've finished
<catphish> would quite like to push for 1GB/s so i'll do some more objective tests to see what can be achieved / what i might be doing wrong
vagrantc has quit [Ping timeout: 260 seconds]
<catphish> objective tests are much more useful, a plain sequential write achieves 550MB/s, that's more like it, but a sequential copy reduces that down to 18MB/s, i feel like i have a deep lack of understanding of how computers work all of a sudden
<catphish> with write-back, that copy runs at 400MB/s, would anyone be able to briefly explain to me what i'm seeing here?
RichardG867 has quit [Read error: Connection reset by peer]
RichardG867 has joined #linux-sunxi
Nyuutwo has quit [Read error: No route to host]
Mandragor has joined #linux-sunxi
Nyuutwo has joined #linux-sunxi
<catphish> in fact the slowdown applies to just reading, so i guess my real question becomes, why can i only read dram at 18MB/s when the mmu is configured with write-through? specifically with tex=0b000, cb=0b10
<catphish> that bufferability bit must have more impact that just a write policy
* catphish keeps reading
JohnDoe_71Rus has joined #linux-sunxi
<jelle> do I need a special /boot for arm64 or can I just use a single partition?
aalm has joined #linux-sunxi
<jelle> nvm figured it out :)
dddddd has joined #linux-sunxi
<mru> catphish: for a graphics framebuffer you probably want to use uncached "normal" (aka write-combining)
glamb has joined #linux-sunxi
glamb has quit [Remote host closed the connection]
<mru> buffering is a write feature
<mru> doesn't affect reads
<mru> caching is only useful if you expect to be reading the framebuffer a lot
<KotCzarny> isnt framebuffer in dram anyway?
<mru> yes, so?
<KotCzarny> isnt the cache small?
<mru> small is a relative thing
<KotCzarny> compared to usual framebuffer size
<mru> but you obviously don't want to be wasting cache space on data you're going to read
<mru> a large L2 cache could hold a small framebuffer
<catphish> mru: thanks, it is a framebuffer, uncached sounds ideal, caching it is totally wasteful, write-combining sounds good, but i don't know what that entails or how to enable it
<catphish> i'm going by this table: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0464d/BIIGJFFA.html
popolon has joined #linux-sunxi
<catphish> oh, "Shareable Device" is probably a much saner setting for this
<mru> no, you want "normal" memory
<catphish> i dn't see anything titled "normal" in that list :(
<mru> which list?
<catphish> these are the available options i'm looking at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0464d/BIIGJFFA.html
marcodiego has joined #linux-sunxi
<mru> you want tex=001 c=0 b=0
<catphish> ok, seems sane
<mru> "device" is for things like mmio registers
<mru> where reads and writes can have side effects
Putti has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
<catphish> on a related note, does tex=001 c=1 b=1 make sense for most other general purpose sram and dram? seems to give the best overall performance
<mru> that's usually a good choice
<catphish> or perhaps tex=001 c=1 b=1
<mru> that's what you just said
<catphish> i don't totally understand the difference, which seems to be "write-allocate"
<catphish> oh, sorry, you're right, i mean tex=000 cb=11 vs tex=001 cb=11
<mru> that determines what happens if you write to a cacheable address that isn't currently in cache
<catphish> oh i see, so a write to a non-cached address won't allocate cache if tex=000
<mru> with write-allocate, the line is fetched and written (dirtied)
<mru> making a subsequent adjacent write faster
<mru> without write-allocate, it writes go directly to dram until there is a read
<catphish> so yeah, tex=001 c=1 b=1 seems like a sensible general purpose choice
<catphish> i'll try all that now, thanks :)
<mru> no write-allocate is faster in some special cases
mzki has quit [Ping timeout: 250 seconds]
IgorPec has joined #linux-sunxi
ninolein has joined #linux-sunxi
mzki has joined #linux-sunxi
<jelle> booted y nanopi a64, quite suprised at the lack of ethernet
<buZz> jelle: did you enable the right interface in fex? (does a64 even still use that..)
<jelle> buZz: wut, fex, I use mainline
<mru> does anyone sane use fex?
<jelle> still have to look up the dts file :p
<buZz> :P
<buZz> -iirc- A64 have two different ethernet interfaces
<mru> still doing the emac/gmac thing?
vagrantc has quit [Remote host closed the connection]
<Mandragor> same problem here with nanopi a64
<jelle> I see an emac defintion, so I'll have to check the kernel config
<jelle> not sure if it's in 4.19 yet
<mru> no sun50i dts in 4.19
vagrantc has joined #linux-sunxi
<mru> sorry, I was looking in arm, not arm64
<jelle> ah 4.20
<mru> but that emac config is missing in 4.19
<jelle> mru: yes, since it's in 4.20
<catphish> mru: thanks for that, makes a lot more sense now, and setting my framebuffer to uncached "normal" while my source data is cacheable has improved things vastly
<mru> catphish: are you using sprites?
<catphish> mru: yes
<catphish> the code essentially just loops over the pixels in a sprite and copies them to a given location in the framebuffer
<mru> you could probably have some fun optimising those copies with neon instructions
<catphish> i did wonder if i could use some better functions (neon or dma) do to it
<mru> what size are your sprites?
<catphish> 16 x 16 x 32-bit
<catphish> though it's a tad complicated because some of the pixels might be transparent, and of course those 790 bytes don't land sequentially in the framebuffer, only each line of 16 pixels does
<catphish> brb
catphish has quit [Quit: Leaving]
catphish has joined #linux-sunxi
reinforce has joined #linux-sunxi
<mru> do you have a separate copy of the background image somewhere?
<catphish> my aim is that the background is generated from sprites in the same way, and they're layered up as needed
<mru> ok, makes sense
<catphish> so draw one set first, then draw a second set over the top, skipping any pixels where the alpha byte is 0x0 on the second pass
<mru> but I guess the foreground sprites can be positioned anywhere
nuuuciano has joined #linux-sunxi
<mru> and the background is simply tiled, yes?
<catphish> so, the concept is as follows: multiple layers can be created, each layer consists of a tiled grid of sprites, and an offset to render at, so a bakground might have lots of sprites in a 50x50 grid, and an offset of 0,0, whereas a foreground layer might have 4 sprites in a 2x2 grid and its position would change much more often, and there may be any number of these layers
<catphish> this is just a concept that seemed cool to me
<mru> makes sense
<mru> and it's perfect for neon optimisation
<catphish> this is my extremely naive demo implementation that i'm playing with: https://github.com/catphish/a20-lowres/blob/master/kernel.c#L89
<catphish> nothing more than a loop that conditionally copies each pixel into place
Putti has joined #linux-sunxi
<catphish> there's a lot of tidying up to be done, but it works :) i will definitly look into neon next then
<catphish> this is what it does https://imgur.com/RxBJJ9t
Nyuutwo has quit [Read error: No route to host]
<mru> neon should speed that up by at least 4x
Nyuutwo has joined #linux-sunxi
<catphish> cool, just reading about it now
<catphish> the transparency seems like the thing that will cause the most annoyance, but i'll look into what neon instructions can do and hopefully speed things up :)
<catphish> thanks for all the assistance, learning a lot here
<mru> I think you'll find the VBSL instruction useful
<mru> along with VCLT
<mru> but make it work first
<mru> then optimise
IgorPec has quit [Ping timeout: 250 seconds]
Andy-D has quit [Ping timeout: 250 seconds]
Andy-D has joined #linux-sunxi
<qschulz> wens: hehe, missed the IRC conversation on the alignment patch but good to see we're on the same page :) thanks quark_ for the patches!
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
giomba has joined #linux-sunxi
IgorPec has joined #linux-sunxi
popolon has quit [Quit: WeeChat 2.3]
clemens3 has joined #linux-sunxi
lykt has quit [Quit: leaving]
clemens3 has quit [Remote host closed the connection]
clemens3 has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
lykt has joined #linux-sunxi
nuuuciano has quit [Ping timeout: 268 seconds]
nuuuciano has joined #linux-sunxi
muvlon has joined #linux-sunxi
clemens3 has quit [Ping timeout: 272 seconds]
clemens3 has joined #linux-sunxi
\\Mr_C\\ has quit [Ping timeout: 272 seconds]
\\Mr_C\\ has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
alexxey has quit [Ping timeout: 245 seconds]
csims27 has joined #linux-sunxi
csims27 has quit [Remote host closed the connection]
nomad_fr_ has joined #linux-sunxi
nomad_fr_ has quit [Remote host closed the connection]
popolon has joined #linux-sunxi
abbe9 has joined #linux-sunxi
abbe9 has quit [Ping timeout: 240 seconds]
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
f0xx has quit [Ping timeout: 240 seconds]
pmpp has quit [Disconnected by services]
pmpp_ has joined #linux-sunxi
Mandragor has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
Mandragor has joined #linux-sunxi
Mandragor_ has joined #linux-sunxi
Mandragor has quit [Ping timeout: 246 seconds]
Mandragor_ has quit [Read error: Connection reset by peer]
Mandragor has joined #linux-sunxi
dev1990 has joined #linux-sunxi
Mandragor has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
Mandragor has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
giomba has quit [Remote host closed the connection]
reinforce has quit [Quit: Leaving.]
killown4 has joined #linux-sunxi
killown4 has quit [Read error: Connection reset by peer]
arete74 has joined #linux-sunxi
muvlon has left #linux-sunxi ["Leaving"]
marcodiego has quit [Ping timeout: 272 seconds]
marcodiego has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
Lavos has joined #linux-sunxi
Lavos has quit [Remote host closed the connection]
AneoX has quit [Ping timeout: 250 seconds]
IgorPec has quit [Ping timeout: 250 seconds]
tuxillo has quit [Remote host closed the connection]
\\Mr_C\\ has quit [Ping timeout: 272 seconds]
\\Mr-C\\ has joined #linux-sunxi
\\Mr-C\\ has quit [Client Quit]
\\Mr_C\\ has joined #linux-sunxi
ninolein has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
tuxillo has joined #linux-sunxi
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
NeuroScr has joined #linux-sunxi