youmukonpaku133 has quit [Read error: Connection reset by peer]
youmukonpaku133 has joined #linux-sunxi
youmukonpaku133 has quit [Read error: Connection reset by peer]
youmukonpaku133 has joined #linux-sunxi
youmukonpaku133 has quit [Read error: Connection reset by peer]
youmukonpaku133 has joined #linux-sunxi
youmukonpaku133 has quit [Ping timeout: 480 seconds]
cakes_ has joined #linux-sunxi
cakes has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: WeeChat 4.0.3]
Daanct12 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
junari has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
youmukonpaku133 has joined #linux-sunxi
NekoMay has quit [Ping timeout: 480 seconds]
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
<libv>
macromorgan: you could also just drive the display directly
<libv>
from the display engine
<libv>
which should theoretically be cheaper
NekoMay has joined #linux-sunxi
DarkNeutrino has quit [Quit: Quit]
DarkNeutrino has joined #linux-sunxi
warpme has joined #linux-sunxi
jason123onirc has quit [Read error: Connection reset by peer]
jason123onirc has joined #linux-sunxi
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
warpme has quit []
mripard has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
kuba2k2 has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
warpme has quit []
apritzel has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel_ has quit []
youmukonpaku133 has quit [Ping timeout: 480 seconds]
youmukonpaku133 has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
kuba2k2 has quit []
warpme has quit []
warpme has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
rsglobal[m] has joined #linux-sunxi
<macromorgan>
libv: how would that work? That's in theory what I'm seeing if its possible.
Daanct12 has quit [Quit: WeeChat 4.0.4]
JohnDoe_71Rus has quit []
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
DarkNeutrino has quit [Read error: Connection reset by peer]
DarkNeutrino has joined #linux-sunxi
DarkNeutrino has quit [Read error: Connection reset by peer]
DarkNeutrino has joined #linux-sunxi
arti has quit [Ping timeout: 480 seconds]
arti has joined #linux-sunxi
youmukonpaku133 has quit [Ping timeout: 480 seconds]
arti has quit [Quit: No Ping reply in 180 seconds.]
youmukonpaku133 has joined #linux-sunxi
arti has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
hentai has joined #linux-sunxi
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
kuba2k2 has quit [Ping timeout: 480 seconds]
youmukonpaku133 has quit [Ping timeout: 480 seconds]
arti has quit [Read error: Connection reset by peer]
youmukonpaku133 has joined #linux-sunxi
arti has joined #linux-sunxi
mripard has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
youmukonpaku133 has quit [Read error: Connection reset by peer]
junari has joined #linux-sunxi
youmukonpaku133 has joined #linux-sunxi
paulk-bis has joined #linux-sunxi
paulk has quit [Read error: Connection reset by peer]
junari_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
junari_ has quit [Ping timeout: 480 seconds]
evgeny_boger has quit [Ping timeout: 480 seconds]
youmukonpaku133 has quit [Ping timeout: 480 seconds]
youmukonpaku133 has joined #linux-sunxi
warpme has quit []
<libv>
macromorgan: the spi bound lcd has a chip in between
<macromorgan>
The ST7789V, right?
<libv>
and the lcd itself is talking to that chip with a parallel bus
<macromorgan>
right
<libv>
at least according to the datasheet, the s3v is capable of driving that parallel bus directly
<macromorgan>
right, my device isn't hooked up that way though
<macromorgan>
if it can't be done I'm not worried about it
<libv>
and i am not sure why that is so
<libv>
the standby display functionality is pretty gimmicky
<macromorgan>
because they probably got a cheap deal on a bunch of crappy LCDs no one wants...
<libv>
and there seems to be no other advantage of this 240x240 is the primary display
<libv>
yes
<libv>
and board design and verification is easier
<macromorgan>
I didn't build the device, just trying to mainline it to make "eating the turd sandwich" easier
<macromorgan>
Anbernic sends me stuff and I try to mainline it if I can
<libv>
right
<macromorgan>
that's my attempt in this case. So far the Unisoc and Actions Semi are the only devices I couldn't get mainlined
<libv>
and for emulation, the layers of the display engine would actually be nice to have, if the emulation engine supports them
<macromorgan>
I opened my big fat mouth and said "It's a V3S, I'll have it mainlined in a day". Then I encountered the display. Then I figured out their devicetree was all wrong. Then I broke the UART solder pads.
<macromorgan>
Fast forward 2 months later, and I'm finally there.
<macromorgan>
admittedly I'm just a hobbyist so it's not like I work on this stuff all day though
<libv>
in fact, DE1 (as in a20) would be perfect for emulation, as it has more 32 sprites per pipe
<macromorgan>
I don't know much about graphics hardware... honestly DRM and MAC80211 are places where I fear to tread.
<macromorgan>
if I understand though in theory the tinydrm drivers can use a GEM buffer as an input
<macromorgan>
and IF there is some way to get a GEM buffer as an output of the DE I could be in business
<macromorgan>
might be a better question for the dri-devel nerds though
<libv>
macromorgan: display engines serialize data to suit the old school CRTs
<macromorgan>
thought that was what the TCON did?
<macromorgan>
datasheet isn't super clear on that though
<libv>
yes, but actual display engines, not allwinner nomenclature
<libv>
this means gathering the right data from memory at the right time
<macromorgan>
yeah
<macromorgan>
again, probably not worth it in my case
<macromorgan>
it's not like I have a GPU, and I seriously doubt using the cedrus bits will be worthwhile on a 240x240 screen...
<libv>
if you can use layers in the display engine for drawing windows which overlap, and perhaps do colour space conversion and or scaling, then it happens at the time when the display engine needs it
<libv>
at the actual pixel
<libv>
if you use a 3d engine to do the same, you not only need to do a lot of setup, you also need to wait until the 3d engine is fully done, until you can use the bit of framebuffer that the 3d engine rendered into, before you can start feeding it to your display engine
<libv>
and from a hw bitbanging pov, overlays are trivial hw
<libv>
overlays/planes/sprites/etc
<macromorgan>
I dunno man... all over my head
<libv>
now since the hw is already designed and built, and it's spi anyway
<libv>
according to jernej (i have not touched allwinner display hw newer than "de1"), the display engine has writeback functionality, but that is not implemented
apritzel has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
<macromorgan>
I see that in the datasheet, but didn't see anything related to it (again DRM is not my comfort zone)
<libv>
macromorgan: drm is not provisioned for it in any way
<libv>
just like it cannot handle 32 sprites per pipe
<macromorgan>
okay
<linkmauve>
With atomic it actually should be able to, but providing the limitations to userland is still something that isn’t really done.
<libv>
linkmauve: display writeback?
<linkmauve>
Currently you can know whether your planes layout is working or not using an atomic TEST_ONLY.
<libv>
linkmauve: or planes
<linkmauve>
libv, no, many planes.
<linkmauve>
Display writeback I think is more the domain of V4L2? But I remember reading about that in the context of DRM too before.
<libv>
linkmauve: i have implemented de1 sprites for the fosdem project in kms
<libv>
jbarnes proposed drm kms planes at xdc chicaco in 2011
<linkmauve>
libv, did you send patches?
<libv>
this was a time when intel had just removed all but one overlay, as you can do it on the 3d engine anyway
<libv>
he did not even take into account x ordering
<libv>
z ordering even
<libv>
but then, jesse was never a display person
<linkmauve>
i915 still only has one overlay and one cursor planes.
<linkmauve>
But this is unrelated to sunxi.
<libv>
he only was told to do so because wayland was much more power hungry than androids surface flinger
<libv>
and intel was still hoping to make it in the mobile world
<youmukonpaku133>
hm
<youmukonpaku133>
is there a way to uh
<youmukonpaku133>
flash an image through FEL?
<libv>
now, given the initial shortsightedness of kms planes...
<youmukonpaku133>
cause my pb616 has soldered nand and its probably not possible to boot off sd
<youmukonpaku133>
so id like to flash an image to nand
<libv>
it comes to no surprise that planes are identified by a bit in a uint32_t for _all_ planes
<apritzel>
youmukonpaku133: sunxi-fel only supports writing to SPI-NOR flash directly, but not SD, eMMC or even NAND
<libv>
given that each pipeline in de1 has a background colour, and 4 "real" planes, and 32 sprites, per pipe
<youmukonpaku133>
fuck
<youmukonpaku133>
so uh what can i try
<apritzel>
and (raw) NAND flash isn't really supported for the newer SoCs anyway
<libv>
i can only use 12 sprites per pipe
<youmukonpaku133>
i have an allwinner a13 board (pocketbook 616)
<youmukonpaku133>
the pocketbook 626 has an internal sd slot but im not so lucky
<youmukonpaku133>
and i cant even seem to mount the sd card on stock
<youmukonpaku133>
xD
<apritzel>
youmukonpaku133: most boards try to boot from SD card first, so have you checked that?
<youmukonpaku133>
huh will try in a few minutes then
<youmukonpaku133>
i kind of doubt that itll boot from sd though...
<youmukonpaku133>
is there a quick way to make a bootable sd
<apritzel>
not being able to access the SD card from Linux (I guess?) could be a different problem
<apritzel>
write u-boot-sunxi-with-fel.bin to sector 16 (8KB) of an SD card: dd if=u-boot-sunxi-with-fel.bin of=/dev/sdX bs=8k seek=1
<apritzel>
(where /dev/sdX is your SD card reader)
<youmukonpaku133>
what about the rootfs though
<youmukonpaku133>
or is that not important atm
<apritzel>
please take one step at a time!
<apritzel>
the question now is whether the BootROM will try to load a bootloader from SD
<youmukonpaku133>
okay
<apritzel>
I don't even know what you are trying to achieve ;-)
<youmukonpaku133>
boot mainline linux
<youmukonpaku133>
on an ebook
<youmukonpaku133>
because yes
<youmukonpaku133>
alright so if it does boot from SD itll show up in uart i suppose?
<apritzel>
huh, mainline, well, hope you have some weeks at hand, then ;-)
<youmukonpaku133>
not really needed, the pb626 has full mainline
<youmukonpaku133>
and its an almost identical board
<youmukonpaku133>
except mine has emmc instead of an sd card slot + no wifi or touch
<apritzel>
sun5i-a13-pocketbook-touch-lux-3.dts?
<youmukonpaku133>
ok so i know this sounds stupid
<youmukonpaku133>
but what is a dts
<youmukonpaku133>
but yes its a close board to the touch lux 3
kuba2k3 has joined #linux-sunxi
<youmukonpaku133>
the touch lux 3 and 2 are both pb626
<apritzel>
the devicetree that describes the board, so the kernel knows what devices are there and how they are connected to each other
<youmukonpaku133>
i see
<youmukonpaku133>
so i assume that dts should work..?
<apritzel>
well, no
<youmukonpaku133>
oh.
<apritzel>
that's the point
<youmukonpaku133>
alright so how would i build a dts then
<apritzel>
you need a DT that describes *your* board, as you said it differs
<youmukonpaku133>
alright
<youmukonpaku133>
is there a way to rip it from stock firmware somehow?
<apritzel>
when it's only about serial access, you might get somewhere with some existing DT that is clse
<apritzel>
you can gather information from the stock firmware, but AW doesn't use proper DTs: if they use a DT at all (I think those older boards didn't)
<youmukonpaku133>
i dont just need serial access
<youmukonpaku133>
i was kind of planning on getting display out eventually when i get proper linux booting
<youmukonpaku133>
with GUD
<apritzel>
from what I can see in the pocket lux DT there is no display described
<apritzel>
well, good luck then, but it's a ton of work
kuba2k2 has quit [Ping timeout: 480 seconds]
<youmukonpaku133>
huh
<youmukonpaku133>
well the lux does have a kernel display drivwr
<apritzel>
indeed, and since it's eInk, that gets more complicated
<youmukonpaku133>
i dont need eink
<youmukonpaku133>
ill use GUD through usb if it works with the pocketbook in peripheral mode
<apritzel>
well, USB should work
<youmukonpaku133>
yea but the wiki for lux said it only has peripheral mode
<youmukonpaku133>
i mean worst case ill have to render over usb network or something
<youmukonpaku133>
anyway ill test if it boots with usb once im home
<youmukonpaku133>
*sd
<youmukonpaku133>
goddamit
<youmukonpaku133>
apritzel: wait if i need DTS where would i put it, or is it included in uboot
<apritzel>
yes, the DT is part of U-Boot
<youmukonpaku133>
oh ok ill just try using the prebuilt uboot for the lux
<apritzel>
but for basic peripherals support (basically just UART for the start), you can use something that's close by, like the Pocketbook
<youmukonpaku133>
both devices are pocketbooks xD
kuba2k3 has quit [Ping timeout: 480 seconds]
<youmukonpaku133>
but yea ill try uboot i suppose
<apritzel>
well, I meant the one that has a mainline DT
<youmukonpaku133>
yea got it
<youmukonpaku133>
anyway i still doubt itll boot from sd but if it does thatll be a very nice surprise
<youmukonpaku133>
thank lord i dont have to worry about display cause all i have is a bare board xD
<apritzel>
where does the vendor firmware boot from? eMMC? or SPI flash?
<youmukonpaku133>
whats spi flash
<youmukonpaku133>
but i assume yea emmc
<apritzel>
the Pocketbook lists a SPI NOR flash chip in the DT, so a smallish (a few MB) NOR flash chip controlled via SPI
<apritzel>
somewhat comparable to PC BIOS chips, if you like
<youmukonpaku133>
oh i see
<youmukonpaku133>
i assume it boots via emmc though
<apritzel>
but anyway: for experiments and development you actually don't need to boot from the board, you can boot entirely via FEL
<apritzel>
which is easier anyway
<youmukonpaku133>
oh true
<youmukonpaku133>
still ill have to test booting off sd
<youmukonpaku133>
because if it doesnt ill have to boot off emmc somehow..
<apritzel>
sunxi-fel loads the SPL, executes it, then you can upload whatever you like into DRAM, that includes U-Boot proper, a kernel and a rootfs
<youmukonpaku133>
dram wont really do for rootfs
<youmukonpaku133>
its only 256mb after all
<youmukonpaku133>
like sure maybe i could boot alpine in dram
<youmukonpaku133>
then what
<apritzel>
if it's really eMMC, then that should not be a problem
<apritzel>
you can access the eMMC from U-Boot, or from a booted kernel
<youmukonpaku133>
oh i see
<apritzel>
the Touch Lux 3 doesn't list eMMC, so you would have to enable that
<apritzel>
but eMMC is typically a no-brainer
<apritzel>
especially if the device is booting from it, since then everything has to be set up already when the BootROM starts
<youmukonpaku133>
alright
<apritzel>
so they hardwire the power supply, typically, and it's using PMIC reset defaults
<youmukonpaku133>
oh also the device only has peripheral mode for usb, any way to get networking with that?
<apritzel>
I think the "peripheral mode only" is only because there is no ID pin to switch on the fly
<youmukonpaku133>
oh
<apritzel>
you might be able to force host mode in the DT
<youmukonpaku133>
i see
<youmukonpaku133>
but the wiki page mentions that itd need something called vbus
<apritzel>
which is a bit tricky if the board runs of the incoming USB power, though ;-)
JohnDoe_71Rus has quit []
<youmukonpaku133>
i can run it off the battery terminals no problem
<youmukonpaku133>
from the wiki page
<apritzel>
if you refer to the Touch Lux 3 wiki page, that means that the board will not supply power via the external USB port
<youmukonpaku133>
USB OTG: - only peripheral mode, as ID detection pin is not routed to SoC - id-det from fex should be at PG2, but does not react to plug-in - vbus is not controllable - detection should be at PG1 (not tested) - vbus enable shoudld be at PG12 (not working)
<youmukonpaku133>
yes i know
<youmukonpaku133>
i can just use a powered hub
<apritzel>
yes
<youmukonpaku133>
as long as a setup of usb otg cable to a usba-to-usbc to dock works
<apritzel>
yeah, all highly non-standard, but I guess you don't care about USB logo compliance at this point ;-)
<youmukonpaku133>
lol
<apritzel>
setting: dr_mode = "host"; might be all you need to do
<apritzel>
you could of course also use an Ethernet gadget on your board, just need to connect it to some other machine providing some connectivity then
<apritzel>
youmukonpaku133: also: the Wiki page mentions that the extra USB host port is connected to the USB WiFi chip, but you said your boards doesn't have WiFi?
<apritzel>
so maybe the USB host port is free to use, then? Might be some pads somewhere, often labelled D-/D+ or DM/DP
youmukonpaku133 has quit [Ping timeout: 480 seconds]
silviop has joined #linux-sunxi
youmukonpaku133 has joined #linux-sunxi
youmukonpaku133 has quit [Ping timeout: 480 seconds]
youmukonpaku133 has joined #linux-sunxi
<youmukonpaku133>
anyway am back home, uboot time
<youmukonpaku133>
apritzel: ok it does not boot from sd
<youmukonpaku133>
lol apparently the pocketbook 616 is known as basic lux 2
<youmukonpaku133>
huh
<youmukonpaku133>
apritzel: now its kernel panicking on stock fw... wtf