<vagrantc>
how do you verify which kind of NAND it has?
<lavamind>
vagrantc: is that question for me ?
<vagrantc>
anyone who might know? :)
<lavamind>
vagrantc: on the CHIP ?
<vagrantc>
yes
<vagrantc>
not urgent, by any means...
naobsd869 has joined #linux-sunxi
naobsd86 has quit [Quit: Ping timeout (120 seconds)]
mpmc has quit [Remote host closed the connection]
lurchi_ has quit [Remote host closed the connection]
lurchi_ has joined #linux-sunxi
lkcl has quit [Excess Flood]
lkcl has joined #linux-sunxi
<lavamind>
vagrantc: when the mtd module is loading it will log a device ID if it finds a match in drivers/mtd/nand/raw/nand_ids.c
<hanetzer>
vagrantc: heyo o/
<lavamind>
vagrantc: dmesg | grep nand:
mpmc has joined #linux-sunxi
jstefanop has joined #linux-sunxi
<lavamind>
if you recreate a mtd partition will it lose the wear-levelling data stored in the enclosed UBI filesystem ?
<lavamind>
or is it similar to manipulation a MBR partition ? (eg. you can add/remove a partition as long as the geometry is the same)
<vagrantc>
hanetzer: hi!
<hanetzer>
vagrantc: one of the #panfrost guys (urjaman or something iirc) has been doing some work for u-boot on the c201 as well
<vagrantc>
hanetzer: cool!
jstefanop has quit [Ping timeout: 246 seconds]
<lavamind>
vagrantc: the stock u-boot on my CHIP has commands like mtdparts and nand, but it doesn't seem like the versions packaged in Debian do (I've tried up to the version in sid)
<lavamind>
I wonder if that's yet another CHIP/NTC-specific hack ?
<vagrantc_>
"c950ca8c35eeb32224a63adc47e12f9e226da241 clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability" trivially applies to linux 5.0 ... needs some massaging for 4.19
Nyuutwo has quit [Read error: No route to host]
Wizzup has joined #linux-sunxi
Nyuutwo has joined #linux-sunxi
Rafael1980 has quit [Quit: Konversation terminated!]
<vagrantc_>
anarsoul: looks like it has been backported to 4.19
<vagrantc_>
anarsoul: as of 4.19.31
<smaeul>
I don't think the device tree patch got backported though, because the clocksource maintainer added the stable CC, not me
<vagrantc_>
and 5.0
<vagrantc_>
smaeul: the one-line device-tree patch ... i added it to debian's kernels at least
<vagrantc_>
without, apparently, the driver.
<vagrantc_>
er, as of 5.0.4
<vagrantc_>
so, it looks like i don't have to do anything
<vagrantc_>
i guess i have to make sure the kernel configuration gets enabled
<vagrantc_>
so i guess my question comes back to ... are the CPU stalls likely related?
<smaeul>
yes, it appears the RCU design didn't account for time travel
megi has quit [Ping timeout: 245 seconds]
Andy-D has quit [Ping timeout: 246 seconds]
<vagrantc_>
engineers these days
<vagrantc_>
ok, the next 4.19.x upload to debian will definitely get it out of the box. yay.
<vagrantc_>
CONFIG_SUN50I_ERRATUM_UNKNOWN1=y
* vagrantc_
tests 5.0.x
KotCzarny has quit [Ping timeout: 245 seconds]
chewitt has joined #linux-sunxi
[TheBug] has joined #linux-sunxi
cch has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
t3st3rV2 has quit [Ping timeout: 256 seconds]
t3st3rV2 has joined #linux-sunxi
lurchi_ is now known as lurchi__
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
Putti has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
vagrantc_ is now known as vagrantc
KotCzarny has joined #linux-sunxi
vagrantc_ has joined #linux-sunxi
Putti has quit [Ping timeout: 245 seconds]
lurchi_ has joined #linux-sunxi
<vagrantc_>
pinebook with new kernel booted ... but left usb port unresponsive ... with only two usb ports ...
<vagrantc_>
hopefully it's just one of the many intermittant flukes on this thing
victhor has quit [Ping timeout: 258 seconds]
lurchi__ has quit [Ping timeout: 245 seconds]
<lavamind>
bbrezillon: OK I've been able to run ubiformat with MTD_MLC_IN_SLC_MODE! however, I did this by specifying the end of the rootfs mtdpart at 4096m, which results in formatted space of 2.0 GiB (as reported by ubiformat)
<lavamind>
my Hynix NAND is 8G (afaict) so I'm wondering why I can't format it to 4.0 GiB ? is it because the dist6 pairing scheme give 1/4 space instead of 1/2 with dist3 ?
<anarsoul>
vagrantc_: it's a known glitch of usb phy driver that switches port mode between ehci and musb. I'm kind of tired of fighting it
<vagrantc_>
anarsoul: ouch
<vagrantc_>
well, at least it's not "just me"
vagrantc has quit [Quit: leaving]
vagrantc_ is now known as vagrantc
<aalm>
can't it be forced to host/ehci mode or something?
gnufan_home has quit [Quit: Leaving.]
wwilly has joined #linux-sunxi
wwilly_ has quit [Ping timeout: 252 seconds]
chewitt has quit [Quit: Zzz..]
nuuuciano has quit [Ping timeout: 255 seconds]
selfbg has joined #linux-sunxi
chewitt has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
selfbg has quit [Remote host closed the connection]
selfbg has joined #linux-sunxi
disik has joined #linux-sunxi
<bbrezillon>
lavamind: nope, that should work with 4G too
<bbrezillon>
lavamind: what's the error you get when defining a part of ~8G?
jstefanop has joined #linux-sunxi
<anarsoul>
vagrantc: it worked for me in 4.19, I haven't tested it with 5.0
<anarsoul>
let me try...
<anarsoul>
vagrantc: it works for me
<anarsoul>
vagrantc: make sure you have CONFIG_USB_MUSB_HOST=y and CONFIG_USB_MUSB_SUNXI=y
<vagrantc>
anarsoul: i've seen it sometimes loose usb on 4.19.x or 5.0.x ... frequently returns after a reboot
<vagrantc>
CONFIG_USB_MUSB_SUNXI=m but ... # CONFIG_USB_MUSB_HOST is not set
<vagrantc>
hmmmm.
shfil has quit [Quit: Connection closed for inactivity]
<wens>
if you are using OTG instead of HOST in Kconfig, make sure you also have a UDC configured, preferably built-in
<wens>
since they don't seem to always auto-load, and musb does not work until you load one
<wens>
s/UDC/USB gadget
chewitt has quit [Quit: Zzz..]
jstefanop has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
chomwitt has joined #linux-sunxi
jstefanop has quit [Ping timeout: 246 seconds]
chewitt has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
chewitt has quit [Quit: Zzz..]
kaspter has joined #linux-sunxi
chewitt has joined #linux-sunxi
wwilly has quit [Ping timeout: 246 seconds]
wwilly has joined #linux-sunxi
cmeerw has joined #linux-sunxi
f0xx has joined #linux-sunxi
reinforce has joined #linux-sunxi
<suprothunderbolt>
as soon as I get my DSI panel working I'm going to attempt to get TDM I2S working, if anyone has already does this and has a patch I'd love to see it. Otherwise I'm going to attempt to port the BSP code.
return0e_ has joined #linux-sunxi
return0e has quit [Ping timeout: 246 seconds]
clemens3_ has joined #linux-sunxi
<jerbob92>
karlp, well afaik in bulk transfer information can only flow 1 way through the different endpoints, so not read/write on both IN and OUT. Correct me if I'm wrong. According to the USB sniffer the device does both.
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
airwind has joined #linux-sunxi
jrg has quit [Ping timeout: 244 seconds]
vagrantc has quit [Quit: leaving]
jrg has joined #linux-sunxi
pmpp has quit [Remote host closed the connection]
msimpson has joined #linux-sunxi
pmpp has joined #linux-sunxi
marble_visions has quit [Quit: bye]
marble_visions has joined #linux-sunxi
tllim has quit [Read error: Connection reset by peer]
<angelo_ts>
clementp[m], well i mean on your 1st link, there are 2 links to 2 drivers versions, none of them works
<angelo_ts>
btw, thanks, i'll study !
<karlp>
jerbob92: this isn't something that would be "some weird software I need to emulate" this would be more likely that the rpesentation or interptreation of your sniffer traffic isn't doing what you think it's doing.
<libv>
ok, i will strip out the comments and the chinese, as that will squarely put us in copyright territory, and reduce it to the actual data needed to boot this device, as if we would've extracted it using our tools
<libv>
heh, this is indeed direct comments of the data that follows
<wens>
the fex file semantics changes a bit from platform to platform :/
<libv>
since we have often enough been grey with respect to these things, and we in the end make sure that allwinner hw is much more popular than it otherwise would've been...
<libv>
wens: yeah, keeping it, and pushing the chinese through google translate
<libv>
which did a good job of the first
<libv>
unless you want to spend some time on doing that :)
<libv>
nah, nvm, i've already copy/pasted,
victhor has quit [Ping timeout: 257 seconds]
fkluknav has quit [Remote host closed the connection]
Andy-D has joined #linux-sunxi
fkluknav has joined #linux-sunxi
t3st3rV2 has quit [Remote host closed the connection]
t3st3rV2 has joined #linux-sunxi
<clementp[m]>
I think they made a mistake on Beelink no ?
<clementp[m]>
the sys_config.fex shouldn't be accessible easily correct ?
<clementp[m]>
or is the dtb dynamically created at the boot ?
<libv>
not sure
<libv>
things were, iirc, not as convoluted back in 2015, and MoeIcenowy only just gave me some initial information yesterday
<MoeIcenowy>
libv: maybe you should try to grab a device and run it
<MoeIcenowy>
I think analyzing image might be easier than dumping it from rm
<MoeIcenowy>
s/rm/ram/
<megi>
I really should remember to run checkpatch.pl every single time
<megi>
before, not after sending
<megi>
:)
<clementp[m]>
megi: the Orange Pi 3 has been merged no ?
<wens>
the kernel driver is also merged for -next (5.2)
JohnDoe_71Rus has joined #linux-sunxi
<runtux>
Hi, I just spent some hours debugging second chipselect on spi (orangepi-zero), how about upstreaming the patch at the end of http://linux-sunxi.org/SPIdev? This solved my problem, oszilloscope pics at discussion in armbian forum https://forum.armbian.com/topic/4330-spi-gpio-chip-select-support/ which show that probably no device can work with that behaviour? The patch on that page is a year old now and probably will save people hou
<runtux>
rs of debugging...
<Ke>
wens: but do I need something else still?
<Ke>
like some xf86-video-notmodesetting
<Ke>
libdrm support I guess at least
<Ke>
I guess that would be anyway for the display controller
Mandragor has joined #linux-sunxi
<wens>
I can't really tell you as I haven't tried it yet
Andy-D has quit [Ping timeout: 255 seconds]
<paulk-leonov>
does anyone still have numbers about expected g2d performance on A20 for given DRAM clocks?
tilpner has quit [Quit: WeeChat 2.4]
tilpner has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
lurchi__ has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<libv>
naturally, a lemaker pull request is full of shit