ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion
vagrantc has joined #linux-rockchip
kevery has joined #linux-rockchip
stikonas has quit [Ping timeout: 260 seconds]
vagrantc has quit [Quit: leaving]
camus has joined #linux-rockchip
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 248 seconds]
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 276 seconds]
kevery1 is now known as kevery
f476_ has joined #linux-rockchip
f476 has quit [Ping timeout: 260 seconds]
f476 has joined #linux-rockchip
f476__ has joined #linux-rockchip
f476_ has quit [Ping timeout: 250 seconds]
f476 has quit [Ping timeout: 276 seconds]
f476__ has quit [Ping timeout: 256 seconds]
f476 has joined #linux-rockchip
indy has quit [Ping timeout: 248 seconds]
f476 has quit [Ping timeout: 276 seconds]
f476 has joined #linux-rockchip
indy has joined #linux-rockchip
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #linux-rockchip
f476 has quit [Ping timeout: 248 seconds]
f476 has joined #linux-rockchip
s1b1 has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
s1b1 has joined #linux-rockchip
f476_ has joined #linux-rockchip
f476 has quit [Ping timeout: 248 seconds]
f476_ has quit [Ping timeout: 248 seconds]
f476 has joined #linux-rockchip
f476_ has joined #linux-rockchip
f476 has quit [Ping timeout: 248 seconds]
Stat_headcrabed has joined #linux-rockchip
wiagn has joined #linux-rockchip
wiagn has quit [Client Quit]
wiagn has joined #linux-rockchip
robmur01_ is now known as robmur01
<amazingfate>
I have this device waiting_for_supplier: /sys/devices/platform/fdca0000.syscon/. Anyone knows why?
<amazingfate>
Many syscon devices on my rk3568 board have this state
Rathann has left #linux-rockchip [Leaving]
matthias_bgg has joined #linux-rockchip
Jmabsd has joined #linux-rockchip
<Jmabsd>
Guys, on ARM, can you set the page size to a really small value like 128B or 64B?
robmur01 has quit [Ping timeout: 276 seconds]
<urja>
I'd say no (looked up and traditionally the ARM MMU had a smallest page size of 1kB ... but i bet the modern stuff is only 4kB or bigger)
robmur01 has joined #linux-rockchip
robmur01_ has joined #linux-rockchip
robmur01 has quit [Ping timeout: 256 seconds]
robmur01_ is now known as robmur01
kevery has quit [Ping timeout: 246 seconds]
Jmabsd has quit [Ping timeout: 248 seconds]
Jmabsd has joined #linux-rockchip
<maz>
Jmabsd: 4kB, 16kB, 64kB. that's complicated enough. If you want less, try a VAX! :D
<maz>
(the above is for arm64 only, of course)
<Jmabsd>
maz: so bad!
<Jmabsd>
maz: AMD64 can do 128B apparently
<maz>
good for them.
<maz>
I seriously doubt this is related to actual page sizes (as in individual translations). maybe some sort of sub-page protection.
* robmur01
imagines how absurd the pagetable structure and page allocator overhead would be would be if you really had two only PTEs per page... you'd basically use most of your memory just for managing your memory
<maz>
robmur01: yeah. and the depth of these page tables....
<robmur01>
indeed IIRC even ARMv5 tiny pages were only 1KB granularity for permissions; translation granularity was still 4KB
<robmur01>
and of course on the original ARM MEMC, the page size was a fixed division of however much RAM you had installed :D
Jmabsd has quit [Ping timeout: 248 seconds]
Jmabsd has joined #linux-rockchip
<maz>
robmur01: who had more than 1MB anyway?
<Jmabsd>
maz: tiny page size would open for a lot of possibilities.
<Jmabsd>
riscv? hm
Jmabsd has quit [Changing host]
Jmabsd has joined #linux-rockchip
<maz>
Jmabsd: I doubt you've worked out the implications of smaller translation granules in a world where you have tons of memory.
<Jmabsd>
maz: there are situations when it's worth it
<Jmabsd>
you mean the TLB could be huge, well, it can be structured as a set of intervals
<Jmabsd>
it's a CPU complexity design thing
<CounterPillow>
what if we took this to its natural conclusion and allowed 1 byte pages, or even better, do bit addressing and do 1 bit pages
<robmur01>
CounterPillow: nah, reductio ad absurdum already stops when your "page" is the size of your PTE - smaller than that and mapping all your memory requires *more* memory than you have ;)
<CounterPillow>
btw my RK3588 arrived, but I'm still waiting for access to SDK sources.
<Jmabsd>
CounterPillow: 1 byte would be great
<Jmabsd>
robmur01: this is because the page table is stored in an inefficient form
<Jmabsd>
if it's a set of intervals, then byte granularity is fine.
<Jmabsd>
right now it's a 1:4096 map tree structure
<Jmabsd>
CounterPillow: Oh la la. Which model?
<CounterPillow>
ok now calculate the algorithmic complexity of doing lookups in your interval structure
<CounterPillow>
QuartzPro64, aka just a cost reduced EVB
<CounterPillow>
debug port is literally a FT232, which is nice, don't need to fiddle around with USB to uart adapters
amazingfate has quit [Quit: Leaving]
* robmur01
isn't going to hold his breath for the miracle of efficiency that can store a practical minimum of at least 20-odd bits of output address plus permissions in 1 byte
<maz>
robmur01: it's only a CPU complexity problem. stop making a fuss.
<CounterPillow>
just make the byte larger, duh
<robmur01>
come back 9-bit bytes and 12-bit slabs, all is forgiven!
* psydroid
won't settle for anything less than 32-bit bytes
<CounterPillow>
Intel to announce AVX-2048
<CounterPillow>
Speaking of low level stuff, is there any reason why clang's assembler doesn't implement the mnemonic syntax described in the ARM instruction set manual like gcc does, but instead invents its own incompatible one that doesn't do the "lsl" stuff?
<robmur01>
you'd probably have to ask the Clangers. Bring soup.
Jmabsd has quit [Ping timeout: 256 seconds]
<robmur01>
I do recall that Apple made up their own asm syntax for A64 SIMD register data types, but I've never heard of any other major differences
Jmabsd has joined #linux-rockchip
<CounterPillow>
problem solved, it was in fact not clang's fault but my fault (gcc was more tolerant)
<CounterPillow>
e.g. v0.4S[0] works on gcc, but clang wants v0.S[0] as the manual specifies
kevery has joined #linux-rockchip
<CounterPillow>
and mov lsl isn't standard, had to use lsl instead
<robmur01>
ah, yeah, the wacky relationships between shift and move instructions that differ in all 3 ISAs are fun :)
lurchi_ has quit [Read error: Connection reset by peer]
lurchi__ has quit [Ping timeout: 276 seconds]
wiagn_ has quit [Quit: Leaving]
camus has quit [Ping timeout: 260 seconds]
matthias_bgg has quit [Quit: Leaving]
Rathann has joined #linux-rockchip
stikonas has joined #linux-rockchip
<Bitweasil>
Any rumors on when the Rock5s might be shipping?
urja has quit [Ping timeout: 276 seconds]
<macc24>
ok so
<macc24>
would it be welcome in the upstream u-boot to add mechanism for autodetecting what rk3326 handheld it's run on, in order to load different dtbs based on value read from an adc channel?
<macc24>
both odroid go advance revisions, odroid go super, anbernic rg351m/rg351p(they use same board), anbernic rg351v and anbernic rg351mp should support this mechanism
<macc24>
i see a similar mechanism implemented in board/sunxi/board.c, maybe for that usecase it would belong to board/rockchip/board.c, board/rockchip/rk3326_handheld_common/board.c or board/rk3326_handheld_common/board.c ?
urja has joined #linux-rockchip
Tenkawa has joined #linux-rockchip
stikonas has quit [Read error: Connection reset by peer]
stikonas has joined #linux-rockchip
Rathann has quit [Ping timeout: 256 seconds]
stikonas has quit [Remote host closed the connection]