ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
<KREYREN_oftc> apritzel, It's also ethical/political? decision like why support a flawed ISA that shouldn't have these issues to begin with?
<apritzel> flawed ISA? I think you now completely lost me ...
<KREYREN_oftc> apritzel, like the core is known to have a major hardware vulnerability so why support it's development instead of making the developers who get paid more than enough for the proprietary ISA to make a revision that doesn't have these issues?
<KREYREN_oftc> instead of trying to pretend that nothing is happening and try to patch it in software
<KREYREN_oftc> bcs that's what riscv is doing with the TH1520 that has a minor issue with underfloat exception make the developer be aware of that and demand a fix which seems to be happening
<jakllsch> easier to do when it's not already deployed much
<jakllsch> and you don't have to walk back your benchmarks
<apritzel> KREYREN_oftc: if you are concerned on that level: please don't use Allwinner chips
<KREYREN_oftc> jakllsch, shouldn't be deployed in the first place then e.g. riscv has a stack that can test the whole compilance that the TH1520 is very obviously failing i assume that ARM has similar thing
<KREYREN_oftc> apritzel, i don't mind the A53/A55 and depending on the results the A20 chips and am happy to develop on them
<jakllsch> speculative execution side channels are not simple to detect or fix
<jakllsch> at least, not without starting over with speculative execution
<KREYREN_oftc> and since allwinner is the only manufacturer who will give me all the needed docs, etc.. that i need to design the projects without having to sacrifice my 1st born
<jakllsch> and that would seriously hurt performance numbers
<KREYREN_oftc> jakllsch, ARM has the budged on having a system in place to detect these prior to releasing the core design though
<KREYREN_oftc> and probably on the performance as well considering that riscv can do that with significanly lesser budget
<jakllsch> what makes you think they can gain profit by doing that?
<KREYREN_oftc> jakllsch, like if riscv can provide better alternative to their core design that is significantly more affordable and doesn't have these issues then it's what will put them out of market
<KREYREN_oftc> so i don't think the short-term profit is worth for them in comparison to the long-term
<KREYREN_oftc> and especially if they are doing that intentionally then it's basically the same thing as phoebis cartel in the 70s and then all the deserved hell to them
<apritzel> what makes you think that T-Head has better verification than Arm?
<KREYREN_oftc> apritzel, because it's open-source and the companies that don't want to pay the licensing fee to arm or use proprietary ISA are investing the needed capital to discover these issues and it's in everyone's best interest due to the open-source model
<jakllsch> is the HDL for the T-Head core actually open source?
<KREYREN_oftc> and like i wouldn't mind using riscv chip with spectre because i can actually inspect the whole chip and figure out myself how much it affects things.. with arm it's basically a closed box that can do anything
<jakllsch> hahaha
<jakllsch> everything you didn't fabricate yourself is basically a closed box that can do anything
<jakllsch> because validating someone else's IC fabrication is probably almost as costly as fabing it yourself
<KREYREN_oftc> EU's getting 4 new fabs that i want to ideally fabricate these chip on which i was told can be arranged soon for an acceptable price ^-^
* apritzel is getting out here ...
apritzel has quit [Quit: Leaving]
* jakllsch same
* KREYREN_oftc :c
movedon5b2z4xywybidzannet[m] has joined #linux-sunxi
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
f_ has quit [Read error: Connection reset by peer]
f_ has joined #linux-sunxi
<KREYREN_oftc> i can't figure out the needed modules for initrd to have a functional display and input in order to input the decrypting password https://dpaste.com/8PGP7A7GM.txt
<KREYREN_oftc> any idea what to do there? The progress so far is that i got from a black screen to a screen that has a backlight
<Jookia> KREYREN_oftc: do you get the LCD after your machine loads?
<KREYREN_oftc> Jookia, yes i have working display in u-boot and in the OS
<KREYREN_oftc> actually the lack of input might be bcs i use armbian u-boot and it has the keyboard input disabled so that could be excluded for now
<KREYREN_oftc> it seems to be related to initrd
<Jookia> the device tree should tell you what your screen is, then you do lsmod once loaded to see that module
<KREYREN_oftc> it's expecting the ANALOGIX ANX6345
<KREYREN_oftc> probably scroll up diego was providing information about the device there
<KREYREN_oftc> it's parallel LCD -> eDP -> whatever A64 does for display
<Jookia> yeah you probably want the panel module
<KREYREN_oftc> i am not aware of there being a panel module
<Jookia> you have a penl connected to the anx6345
<Jookia> or something
<Jookia> the panel has a module that can include blobs to boot it or something
<Jookia> but it might be simple-panel
<Jookia> oh it uses edp
<Jookia> hmm.
<Jookia> yeah, the panel part is probably out of tree in olimex's tree
gnarface has quit [Quit: Leaving]
<Jookia> oh, it uses non-mainline kernel?
* KREYREN_oftc confused
<KREYREN_oftc> it uses mainline
<Jookia> i dunno, i can't find the sources for it
<Jookia> sorry
<KREYREN_oftc> open-source hardware and all of software with the exception of RTL8723BS bcs the staging driver might not be usable for everyone
<Jookia> if you find the device tree just link it
<KREYREN_oftc> Jookia, github.com/olimex/diy_laptop >_<
<KREYREN_oftc> Jookia, oke
<Jookia> yeah i dug through that, it's not too helpful
<Jookia> yes i don't see a panel in it
<KREYREN_oftc> Jookia, ye afaik it doesn't care about the panel bcs of the ANX6345
<KREYREN_oftc> it seems to have display in the old dt
<Jookia> there's a panel in the pinebook dtsi
<Jookia> dts*
<Jookia> generally bridges have a panel
<Jookia> oh, it says panel may be omitted if EDID works reliably
<Jookia> yeah i'm not sure, you should check which modules get loaded and just add those
<KREYREN_oftc> Jookia, that's what i did already kinda and it didn't work :D
<Jookia> wow that's a lot of modules
<Jookia> yeah i don't know, sorry. i usually compile LCD support in to the kernel
<Jookia> does it load after you decrypt/login?
<KREYREN_oftc> i have to input decryption over serial console and then everything works fine
<Jookia> you might want to track which modules get loaded then
<Jookia> unless this is a udev thing
<KREYREN_oftc> i am trying to track and document the kernel modules for 2 weeks now and didn't get much further tbh https://linux-sunxi.org/Olimex_Teres-A64#Linux_Kernel_Configuration_Reference
<Jookia> have you checked /sys ?
<Jookia> you can find out which driver is powering the vtcon and follow from there
<Jookia> i think at least
<KREYREN_oftc> Jookia, /sys for what?
<Jookia> sys shows how all the devices and drivers and modules attach together in the kernel
<Jookia> but it could be that the initrd isn't copying dependencies or something for the modules
<Jookia> maybe you could just copy all the modules and see if that works
<KREYREN_oftc> would like to avoid doing that bcs it takes time to compile
<Jookia> isn't it just copying files?
<KREYREN_oftc> Jookia, it would if i was using nixos's kernel but i haven't yet figured out how to fix https://github.com/NixOS/nixpkgs/issues/260222
gnarface has joined #linux-sunxi
<KREYREN_oftc> so it's building everything
<Jookia> ah
<Jookia> i don't use nixos so i don't know how to fix that
<KREYREN_oftc> bcs i use kernel with CMA_SIZE_MBYTES=128
<Jookia> you don't just pass the cma=128 kernel arg?
<KREYREN_oftc> Jookia, that doesn't work
<Jookia> cma=128M ?
<KREYREN_oftc> actually i did cma=128M
<KREYREN_oftc> ye
hexdump01 has joined #linux-sunxi
<KREYREN_oftc> was suggested to address that via DT overlay
hexdump0815 has quit [Ping timeout: 480 seconds]
<Jookia> cma=128M should set it from your bootloader. not sure why it wouldn't
<KREYREN_oftc> hmm actuall i can try booting with the kernel that causes pain
<KREYREN_oftc> Jookia, i tried that ye
<KREYREN_oftc> i can try again
<Jookia> anyway i would suggets if you're doing kernel dev to set up a mutable kernel you can modify and hack on instead of using nixos' thing
<Jookia> and make a test initrd or something
<KREYREN_oftc> it's building now
cakes has quit [Ping timeout: 480 seconds]
aerospace[m] has joined #linux-sunxi
<KREYREN_oftc> Jookia, loading of all the modules worked
<Jookia> nice!
<KREYREN_oftc> well it's any combination of these
<KREYREN_oftc> feels like a saw movie
<Jookia> why not just load them all at boot?
<KREYREN_oftc> bcs it makes me feel empty inside
<Jookia> well
<Jookia> the modules aren't aren't a stable ABI so you'll be maintaining a selected initrd module list forever
<Jookia> it's a lot easier to just dump in all the modules your machine uses
<Jookia> there's no guarantee you updating the kernel won't leave you with an unbootable system
<Jookia> maybe there's a smarter way to do that
<KREYREN_oftc> Jookia, maintaining a list is fine bcs nix has that well integrated
<KREYREN_oftc> so everyone else can use my list
<KREYREN_oftc> and it's applied automatically
JohnDoe_71Rus has joined #linux-sunxi
GrantM11235[m] has joined #linux-sunxi
fraolt has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
<Jookia> ah ok
evgeny_boger has joined #linux-sunxi
evgeny_boger1 has quit [Ping timeout: 480 seconds]
norton has joined #linux-sunxi
mkazantsev has joined #linux-sunxi
<KREYREN_oftc> weird the cma=128M now works
<KREYREN_oftc> O_O
<KREYREN_oftc> and seems to work much better than it being compiled in the kernel
mkazantsev is now known as Guest1815
mkazantsev has joined #linux-sunxi
mkazantsev has quit []
Guest1815 has quit [Ping timeout: 480 seconds]
<machinehum> Nice meeting everyone last weekend
<gamiee> same here, it was really great to meet all of you in person :)
<KREYREN_oftc> compared to me who sees meeting too many people at once as the idea of a personal help x.x
<KREYREN_oftc> *hell
bauen1 has quit [Ping timeout: 480 seconds]
evgeny_boger has quit [Quit: evgeny_boger]
dsimic is now known as Guest1825
dsimic has joined #linux-sunxi
Guest1825 has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
evgeny_boger has joined #linux-sunxi
<libv> machinehum: indeed, and thanks for helping with cleanup
pg12 has quit [Remote host closed the connection]
norton has quit [Ping timeout: 480 seconds]
pg12 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
<Jookia> KREYREN_oftc: yay it works :)
vagrantc has joined #linux-sunxi
mripard has quit [Ping timeout: 480 seconds]
<jernej> KREYREN_oftc, Jookia: note that overwriting cma size on kernel command line has side effect - it discards memory location limits set in DT.
<jernej> which are important for Cedrus on A20
<jernej> if you don't need it, then fine
bauen1 has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.0 Quasar http://www.kvirc.net/]
hexdump01 has quit []
hexdump0815 has joined #linux-sunxi
<Jookia> jernej: You sure? I read the code and it doesn't seem like it does
<jernej> ndufresne experienced that when testing Cedrus
<jernej> it wasn't obvious
<Jookia> huh. seems like a bug?
<Jookia> looks like the DT check was reverted or something
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
machinehum2 has joined #linux-sunxi
machinehum2 has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
vagrantc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]