melonipoika has quit [Quit: No Ping reply in 180 seconds.]
maksimlin has joined #linux-sunxi
melonipoika has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
tinti has quit [Quit: Leaving]
wenbin has joined #linux-sunxi
FreezingCold has joined #linux-sunxi
leviathanch2 has joined #linux-sunxi
leviathanch2 has quit [Ping timeout: 245 seconds]
popolon has quit [Quit: WeeChat 1.0.1]
protoCall7 has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
<wens>
mripard: then you'd pass bootargs in chosen in the dt?
viccuad has quit [Read error: Connection reset by peer]
protoCall7 has quit [Quit: protoCall7]
<ssvb>
hno: does fel protocol have a 'shutdown' command?
<ssvb>
hno: I mean de-initialize the MUSB hardware
FreezingCold has quit [Ping timeout: 260 seconds]
TheSeven has quit [Ping timeout: 260 seconds]
TheSeven has joined #linux-sunxi
kaspter1 has joined #linux-sunxi
kaspter1 has quit [Client Quit]
kaspter has joined #linux-sunxi
zeRez has joined #linux-sunxi
lioka has quit [Ping timeout: 260 seconds]
ganbold__ has joined #linux-sunxi
ganbold_ has quit [Ping timeout: 240 seconds]
zeRez has quit []
zeRez has joined #linux-sunxi
zeRez_ has joined #linux-sunxi
zeRez has quit [Read error: Connection reset by peer]
Zboonet has quit [Remote host closed the connection]
Zboonet has joined #linux-sunxi
wingrime has joined #linux-sunxi
philippe_fouquet has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
_massi has joined #linux-sunxi
sehraf has joined #linux-sunxi
<hno>
ssvb, not that I know of. But you can always load an executable that resets the system.
<mripard>
wens: yep
zeRez_ has left #linux-sunxi ["No boundaries on the net!"]
nicksydney has quit [Remote host closed the connection]
nicksydney has joined #linux-sunxi
bonbons has joined #linux-sunxi
HeHoPMaJIeH has quit [Quit: Konversation terminated!]
hipboi has quit [Ping timeout: 272 seconds]
hipboi has joined #linux-sunxi
jelly_ has joined #linux-sunxi
FR^2 has joined #linux-sunxi
<jelly_>
how cubieboard beginner can do to quickly study
<libv>
study what exactly?
<jelly_>
eg:step by step to learn cubieboard system including hardware and software
Andy-D has joined #linux-sunxi
<libv>
...
<libv>
jelly_: there should be a book out soon.
<jelly_>
when?please!
Andy-D has quit [Ping timeout: 245 seconds]
jelly_ has quit [Quit: Page closed]
Andy-D has joined #linux-sunxi
diego71 has quit [Ping timeout: 250 seconds]
JohnDoe_71Rus has joined #linux-sunxi
diego71 has joined #linux-sunxi
deasy has joined #linux-sunxi
Andy-D has quit [Ping timeout: 260 seconds]
paulk-collins has joined #linux-sunxi
<ssvb>
hno: resetting the system is not desired
<ssvb>
hno: I would want to load the u-boot/kernel using FEL and then use NFS root over the USB OTG cable
<ssvb>
hno: the MUSB hardware should be preferably in a clean state after the FEL boot is done, but I'm getting something like "ep_matches, wrn: endpoint already claimed, ep(0xc087e99c, 0xee913e80, ep1-bulk)" in the kernel
skaag has quit [Read error: Connection reset by peer]
skaag has joined #linux-sunxi
Andy-D has joined #linux-sunxi
<ssvb>
hno: actually re-plugging the mini usb cable after FEL boot with NFS root via GMAC helps, and then I can modprobe/rmmod g_ether/g_serial
wenbin has quit [Quit: Leaving]
<ssvb>
hno: so it is not like FEL screws up then MUSB state completely until reset :)
<ssvb>
hramrach_: earlier you mentioned that FEL boot followed by the use of USB OTG was working fine for you?
<arokux>
ssvb: are you working on usb otg driver?
<ssvb>
arokux: not working on it yet, but just trying to see what the current code from sunxi-3.4 can offer and maybe then transplant it into the mainline kernel
<arokux>
I see
megal0maniac is now known as Guest38825
Guest38825 has quit [Killed (verne.freenode.net (Nickname regained by services))]
megal0maniac has joined #linux-sunxi
<ssvb>
a complete system boot over usb otg, while using the sd slot for the serial console via sd breakout would be nice
paulk-collins has quit [Quit: Ex-Chat]
<rz2k_>
s/for the serial console/fot jtag/
<rz2k_>
fixed that for you
<rz2k_>
:p
<arokux>
ssvb: hm.. why do you need to boot over usb otg, if you can boot over normal usb already?
<ssvb>
arokux: some tablets don't have normal usb ports
<arokux>
ssvb: ah :)
<ssvb>
rz2k_: wow, do you use jtag on sunxi hardware?
<rz2k_>
I tried really long ago
<rz2k_>
but it is possible
<rz2k_>
mans are on wiki
<rz2k_>
by hno
megal0maniac has quit [Ping timeout: 240 seconds]
<ssvb>
rz2k_: ok, found it
<arokux>
rz2k_: what can you get by using jtag?
FreezingCold has joined #linux-sunxi
<ssvb>
arokux: do somewhat more advanced debugging easier?
megal0maniac has quit [Killed (sinisalo.freenode.net (Nickname regained by services))]
megal0maniac has joined #linux-sunxi
megal0maniac has quit [Ping timeout: 260 seconds]
megal0maniac has joined #linux-sunxi
<ssvb>
hramrach_: so far I could get either g_ether nfsroot or fel boot, but not both at once
leviathanch2 has quit [Ping timeout: 245 seconds]
<ssvb>
hramrach_: passing over the musb hardware from fel to g_ether does not seem to go smoothly
megal0maniac is now known as Guest94626
Guest94626 has quit [Killed (wolfe.freenode.net (Nickname regained by services))]
megal0maniac has joined #linux-sunxi
maksimlin has quit [Quit: ChatZilla 0.9.91 [Firefox 32.0.3/20140924083655]]
bengal has quit [Remote host closed the connection]
leviathanch2 has joined #linux-sunxi
megal0maniac has quit [Killed (sinisalo.freenode.net (Nickname regained by services))]
megal0maniac has joined #linux-sunxi
bengal has joined #linux-sunxi
wingrime has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
wingrime has quit [Read error: Connection reset by peer]
amitk has joined #linux-sunxi
megal0maniac is now known as Guest20225
megal0maniac has joined #linux-sunxi
Guest20225 has quit [Ping timeout: 260 seconds]
megal0maniac has quit [Ping timeout: 260 seconds]
viccuad has joined #linux-sunxi
<hramrach_>
it did with like 3.4.75 AW driver
<hramrach_>
with a slight patch
<hramrach_>
otherwise you had to replug cable :S
Svetlana has quit [Killed (sinisalo.freenode.net (Nickname regained by services))]
Sveta has joined #linux-sunxi
megal0maniac has joined #linux-sunxi
<ssvb>
hramrach_: can you upload a kernel branch to github with the necessary patch and your config tweaks?
<ssvb>
hramrach_: this would make everything much easier to verify, thanks
leviathanch2 has quit [Ping timeout: 258 seconds]
megal0maniac has quit [Ping timeout: 260 seconds]
castor3 has quit [Ping timeout: 250 seconds]
<hramrach_>
I don't have any I have a kernel that I boot from MMC and otg works on it but I did not upload it over fel since mmc is working for me
castor3 has joined #linux-sunxi
<hramrach_>
I can try uploading over mmc later
<hramrach_>
*fel
Black_Horseman has quit [Remote host closed the connection]
kaspter has quit [Ping timeout: 244 seconds]
paulk-collins has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
megal0maniac has joined #linux-sunxi
rafaelMOD has joined #linux-sunxi
Sveta is now known as Svetlana
leviathanch2 has joined #linux-sunxi
ZrZ is now known as RzR
FDCX has quit [Remote host closed the connection]
FDCX has joined #linux-sunxi
vicenteH has quit [Ping timeout: 246 seconds]
ricardocrudo has joined #linux-sunxi
leviathanch2 has quit [Ping timeout: 272 seconds]
Andy-D has quit [Ping timeout: 244 seconds]
leviathanch2 has joined #linux-sunxi
Andy-D has joined #linux-sunxi
paulk-collins has quit [Quit: Ex-Chat]
leviathanch2 has quit [Ping timeout: 258 seconds]
<hno>
arokux, jtag makes u-boot & kernel debugging a lot easier, almost like you are debugging a normal application.
<wens>
wiki feels a bit slow
<arokux>
thanks hno
rz2k_ has quit []
Svetlana has quit [Quit: sleep]
afaerber_ has joined #linux-sunxi
afaerber has quit [Ping timeout: 245 seconds]
<ssvb>
hramrach_: well, mmc and otg works for me too
leviathanch2 has joined #linux-sunxi
<ssvb>
hramrach_: all of this musb stuff is a little bit messy, so it would be nice to confirm what actually works and what does not
xavia has joined #linux-sunxi
leviathanch2 has quit [Client Quit]
leviathanch2 has joined #linux-sunxi
<hno>
ssvb, I did FEL boot + otg on the initial eoma68 prototypes with not too much issues. But I do not remember if I used g_ether. I for sure used g_serial, and it was quite long ago so lots have changed since everywhere.
<hno>
I used normal linux-sunxi kernel at the time. No extra patches.
<hno>
but I am afraid the exact versions used have been lost.
<ssvb>
hno: yes, that's why keeping track of exact steps and git commit hashes is always nice
esperegu has quit [Remote host closed the connection]
<ssvb>
hno: though I have a suspicion that USB in my PC might theoretically also play some role in this
<hno>
to do that you boot somethign build with the Android targeting SDK (AW or linux-sunxi if lucky), not mainline.
<hno>
slapin, sorry, can not help much, been hiding away in Bitcoin land for last 2 years. You really need to talk to bbrezillon.
<ssvb>
hno: maybe for libhybris or similar things
<slapin>
ssvb: you could know if you cared for :) my only goal is mtd to work on these beasts
konradoo77 has joined #linux-sunxi
<ssvb>
libv: btw, would it make sense to disable NAND support in the sunxi-3.4 kernel in order to prevent damage to Android?
<ssvb>
libv: iirc, you were the one who looked into this problem
philippe_fouquet has joined #linux-sunxi
<slapin>
ssvb: why do you care so much for damage to Android?
<slapin>
so it seems I have to look at these myself...
<ssvb>
slapin: people might have some use for the stock android on their tablets or tv boxes, and would not be very happy to corrupt it by just trying to boot sunxi-3.4 kernel
<ssvb>
slapin: read the mailing list archives, find the nand wip branches and try to use them
<slapin>
ssvb: they can recover with stock tools. also, why it should damage anything as it is now?
* slapin
hates reading mail recently, there is so much bills every day...
<wens>
slapin: cheap no brand tablets dont have "stock images" available for download
<slapin>
ssvb: found a lot for replacement, even better, was reflashing some unknown A20 tablet, which corrupted rootfs, and new flash made proper screen resolution and phone jack now works :)
<hramrach_>
it would be nice if you could read android with Linux
Gerwin_J has joined #linux-sunxi
<hramrach_>
but you have ADB
<hramrach_>
so you can read android fs with android
<hramrach_>
and the libnand support in 3.4 is bit rotten anyway - see the bug that causes nand corruption libv was hunting
<slapin>
but why not in stock linux-sunxi/linux-sunxi repo? that'd make it a lot more visible... :(
<hramrach_>
it's not like there is much hope keeping the nand code up to date with latest android code whim
<hramrach_>
my A13 tablet grew rootfs corruption but at least prestigio can give you a rom if you ask for one
* slapin
doess have here non-android box with ADB support and surfaceflinger as GUI. Damn perverted box that is...
<hramrach_>
so hope I can extract any needed files from that
<hramrach_>
adb is not such a bad idea but it's developed for devices that are like totally useless on their own and it shows in the design
<ssvb>
hramrach_: you have to *ask* for it? not just download from their website at the product support page?
<hramrach_>
like you are not expected to have any security or access control on the target device
<hramrach_>
no, they do not have up-to-date links on their product page
<hramrach_>
but they do have a call center ..
<ssvb>
hramrach_: at least MSI provides recovery images on the device support pages, I have downloaded and backed them up
<hramrach_>
prestigio does too .. bet they are older than what the device shipped with :s
<hramrach_>
can you like copy the stuff from the tablet with some AW tool to make the recovery image?
<hramrach_>
I did not find an option for that
<ssvb>
also MSI claims to provide kernel sources, but the download link is broken for Primo81 and the 1.6GB zip file with supposedly kernel sources for Primo73 just does not extract :-(
<slapin>
btw, what does with mele a1000g support? do they have any updated flash which doesn't drop dead afer couple of days?
<hramrach_>
is that the whole zip? SDKs tend to be larger
<slapin>
mumble-mumble
<hramrach_>
yes, it's called mainline kernel. it's under development :p
<slapin>
a-ha-ha
<ssvb>
hramrach_: it looks like an incomplete zip file, probably cut in the middle (I tried to download it twice with the same results)
<hramrach_>
with the AW libnand nobody knows how it is supposed to work but reportedly corrupted flash is normal and it got corrupted on like half the devices I use
Gerwin_J has quit [Read error: Connection reset by peer]
<ssvb>
slapin: "they" == "the device vendor"?
philippe_fouquet has quit [Remote host closed the connection]
Gerwin_J has joined #linux-sunxi
<hramrach_>
possibly the libnand code is not resistant to some bad block patterns that occur on some chips but not others
<ssvb>
hramrach_: you get NAND corruption problems in the stock android system?
<slapin>
ssvb: everyone do
<hramrach_>
technically neither was with stock android. one was with nand reused for linux installtion and another was while accessing the nand with linux
<slapin>
I have 3 of 5 devices with A10 and A20 had weird filesystem corruption with stock firmware
<hramrach_>
yes, read that part
<ssvb>
hramrach_: unless I'm mistaken, the mtd code in the mainline kernel had been developed with SLC NAND assumptions
<slapin>
MLC is cheap crap
ganbold_ has joined #linux-sunxi
<hramrach_>
and it's not completely solved with ubifs/mtd either
xeros has quit [Ping timeout: 260 seconds]
<slapin>
hramrach_: jffs2 proved reliable even on MLC, but it is not very efficient on NAND chips with huge pages.
<hramrach_>
but with ubifs you know what you are doing, it's documented how it should work, when it fails you have meaningful diagnostics, and when somebody finally solves the mlc problems or adds more safeguards at least you get that on each and every device using mtd - not just one vendor
<ssvb>
supposedly if you just hook for your MLC NAND hardware support into the standard mainline mtd, then you are expected to have data corruption problems
<slapin>
UBFS is prone to bitflip errors, but it is still more reliable than AW's block device.
<ssvb>
how come that this libnand stuff works supposedly ok for the end users on many android devices? even from reputable vendors such as HP, MSI and the others
<ssvb>
I would expect them to have some sort of QA
<slapin>
ssvb: no, the MTD idea is fine, the data corruption on MTD-level is not a problem as the filesystem is aware of them. MLC is not reliable
<hramrach_>
it works on every other device and you can always reflash when it fails
FreezingCold has quit [Ping timeout: 260 seconds]
<hramrach_>
also selecting a nand chip brand more suitable for use with libnand may give better than 50% success
<ssvb>
hno: I assume that you were using initramfs, right?
<hramrach_>
a;so nobody says it's working. HP made a few AW (and other Chinese SoC) based tablets possibly as experiment. MSI is not reputable vendor
<hramrach_>
btw anyone has slatedroid account?
<hramrach_>
I managed to register to like 2 different other shady forums but still got no activation email from slatedroid
<ssvb>
hramrach_: doesn't MSI make video cards, motherboards and other electronic devices? either way, it looks like they have already discontinued their Allwinner tablets
<hramrach_>
yes, and not the best ones. Not the worst ones either. like average Taiwanese junk
<ssvb>
at least they are providing recovery images, PDF documentation, are not lying about the specs, ...
<ssvb>
and the build quality seems to be good, with the use of metal back covers
<ssvb>
this looks like a big improvement over random no-name Chinese tablets
leviathanch2 has quit [Ping timeout: 272 seconds]
<hramrach_>
sure. Still spec confusion is common with this stuff. Even HP has contradicting info about its tablets
<hramrach_>
and you have nice Lenovo tablets (some of which were rk but seen no AW so far)
<hramrach_>
hmm, actually I do not care about nice tablets with AW SoCs. the SoC is passable and so should be the tablet
<hramrach_>
when they have nice SoC I will demand a nice tablet to go with it
<ssvb>
probably not going to happen with AW :)
<ssvb>
A80 has still has SGX graphics
<hramrach_>
so shady Chinese manufacturers are good enough
<slapin>
hno, hramrach, bbrezillon: btw, is there any bitflip code in libnand? can't see any :(
<wens>
hramrach_: :(
<wens>
should go with mediatek for tablets
<slapin>
any links on A80 specs?
<wens>
slapin: wiki
<slapin>
wens: mediatek does have some better mainline support, as long, as rockchip now. too bad :(
<wens>
slapin: they are mainlining _all_ support for their tablet soc
<wens>
afaik it was a requirement from a customer
xeros has joined #linux-sunxi
<wens>
will take a few releases though
<hramrach_>
interesting
<slapin>
wens: AW?
<wens>
slapin: mediatek
<slapin>
I know about mediatek, I'm pitying allwinner. Or myself, for that matter. Or not, as otherwise I wouldn't have so much fun...
<hramrach_>
but this tablet is a bit dated so back then you could find that there is some linux code for mtk, and that was about it
<slapin>
IIRC, mtk wanted to do some more than just one tablet...
<hramrach_>
what state is that support? can you get like 100% working device with mainline? which SoCs? where is the news?
<wens>
there is little support in current mainline atm, they've just started
<ssvb>
wens: what about tivoization? is it a part of their plan?
<slapin>
and they might like to do that... but this might look like some other vendor support - to run on real hardware you will have to do some work...
<wens>
slapin: hmm, i thought only we used the "mtk" shorthand
<ssvb>
allwinner still has sloppy security as an advantage for the end users :)
<slapin>
there is very little working devices in mainline.
<wens>
ssvb: tivoization? like locked bootloader?
<hramrach_>
yes
<slapin>
wens: it was because their phone CPUs do have mtk prefix
<wens>
afaik they aren't releasing their bootloader code
<slapin>
wens: and everyone used to it
<hramrach_>
tive requires signed firmware .. signed exclusively by tivo
<wens>
slapin: i thought all socs have MT prefix
<wens>
maybe they switched to that some time ago
<ssvb>
wens: yes, the mainline support would be worthless for the end users if they can't recompile and replace their bootloader/kernel and the userland stuff
<wens>
i myself am not very fond of the company
<slapin>
wens: dunno, my torture toy doesh have MTK, and router does have RT prefix...
<hramrach_>
technically even without loader sources if the kernel is not signed you can replace it
<wens>
slapin: RT sounds like realtek or some asus router...
<slapin>
I wonder, the router uses u-boot, so sources should be somewhere...
<ssvb>
hramrach_: the industry is moving to signed kernels, UEFI, trustzone and other buzzwords
<hramrach_>
then we will be left with cheap Chinese SoCs for real usable devices
<slapin>
wens: you won't beleive, RT5350 is made by mediatek :)
<hramrach_>
MS did not manage to make signing mandatory for x86 but it's mandatary for Windows RT devices
FunkyPenguin has quit [Ping timeout: 245 seconds]
* slapin
hates trustzones
<hramrach_>
Realtek uses rtl or what prefix
<wens>
slapin: that's from ralink, bought out by mediatek
<slapin>
and yes, signed firmware on bug arm socs (Cortex-A15-based ones) is the reality :(
FunkyPenguin has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 255 seconds]
<hramrach_>
if you can unsign it and the way to do it is know that's not such a big problem
<hramrach_>
but opening a glued together tablet to install usable firmware on it .. it's better to get a different tablet then
<slapin>
anyway, I've got a bunch of atheros and mediatek SoCs over there which were not mainlined at all, use ancient kernels and u-boot, and small flash memory, so they all use Linux for a long time, but nobody cared for mainlining or dropping code somewhere for somebody to mainline that... :( but they have jtag port and are big enough for using as a tool for some DIY-something, like CNC-attachment...
<ssvb>
hramrach_: on the arm chromebook, there is a security screw inside of the device, which shorts a few pads and allows to unlock the bootloader
<ssvb>
hramrach_: and the arm chromebook disassembly does not require special skills or experience :)
<slapin>
hramrach_: none of AW tablets I've seen were glued, only screws...
<hramrach_>
is there? did not open it yet. need to build a bootloader to replace the stock one first
konradoo77 has joined #linux-sunxi
* slapin
was prohibited of buying chromebook being from russia :(
<hramrach_>
it's like nice proof-of-concept device
<hramrach_>
but you need to fix so much on it to make it usable :s
ysculo has quit [Quit: Quitte]
<wens>
mripard: if we want to include dt-bindings/*.h in the dtsi, we need to use #include instead of /include/ in the dts files :(
<hramrach_>
yeah, snow
<hramrach_>
best companion for hot summers ;-)
<slapin>
chromeos = Linux with surfaceflinger?
<hramrach_>
why SF?
<hramrach_>
just linux so limited nobody seriously uses it
<slapin>
hramrach_: this is something I've heard
<slapin>
nobody likes poor old X11 these days :(
<hramrach_>
how do you tell if it has SF or not? does it really make a difference?
<hramrach_>
not that X11 folk do not deserve that
<slapin>
hramrach_: ps ax|grep surfaceflinger
<slapin>
last day X11 folk really deserve to burn in hell, especially for RENDER.
<slapin>
my multi-display setup business is damaged by it
<ssvb>
slapin: Chrome OS is using X11 with their own Aura compositor
<hramrach_>
render is actually their attempt at getting something better than line acceleration
<slapin>
and nobody makes displays which can survive 5 years 24/7 :(
<hramrach_>
I am not sure what exact shortcomings the protocol has but the most important one is probably that once it has something you cannot ever remove it
<slapin>
hramrach_: well, it was attempt "at getting something better than line acceleration" without understanding X11 and really changing their inner workings
<hramrach_>
probably the not changing the inner workings is so that the line acceleration can *still* be used. which is insane
<ssvb>
slapin: RENDER is not too bad, the biggest problem is that the drivers quality is not that great and there are too many graphics card with different drivers
* slapin
has 200pcs setup of Toshiba and Sony industrial CRT monitors over 20 years old which need replacement, and there is none :(
<hramrach_>
what are the requirements?
<ssvb>
slapin: so one of your users is going to most definitely encounter a particularly bad driver
leviathanch2 has joined #linux-sunxi
<hramrach_>
if the requirement is that you do not have to replace the screens every year there are pro screens with improved durability .. at a cost
<ssvb>
slapin: Firefox folks were burned by this, they faithfully implemented the RENDER accelerated backend, and got really bad performance on some graphics cards
<ssvb>
slapin: and the users of course blamed Firefox, because that's what they see struggling on their monitors
<ssvb>
slapin: ARM drivers (-armsoc, -omap, -mali, ...) are particularly bad, a common pattern is to allocate uncached memory buffers and then call software fallbacks to move the pixels in these buffers :)
<ssvb>
slapin: doing so is like 10x slower than sane software rendering, not hindered by extra ballast
<slapin>
ssvb: RENDER is VERY bad, the problem is that to port it on display which it doesn't already support (like different color encoding) makes it very hard, some code is simply crashing in some execution patterns. The core X11 works without any changes, but RENDER takes months to fix all crap. Pixman is the biggest source of it.
<ssvb>
slapin: are you sure about pixman?
<hramrach_>
pixman is an attempt to outsource as much if this nonsense into a shared, reusable library as possible
* ssvb
is (or was) pixman's co-maintainer, at least for the ARM backend part
<slapin>
ssvb: pixman is CRAP. it is shittest piece of CRAP I ever seen. Only libstagefright is worse, and maybe bluedroid.
<hramrach_>
and you ultimately do need something like render. that it is not always done right and for concerns of backwards compatibility may be needlessly harder in X is another thing
<ssvb>
slapin: maybe you should try to report bugs if you have some problems?
<slapin>
ssvb: the whole concept. Look how X11 handles everything considering rendering, and how pixman does it. Finally I had to write RENDER-emulator for apps to vork properly in large multidisplay installs with X11 (remote displays).
<ssvb>
slapin: are you a fan of the GC approach? or what is the problem?
<ssvb>
slapin: is your RENDER emulator a free software?
<slapin>
ssvb: X11 is much much more flexible and thought over, and pixman is an ad-hoc hack attempt to solve some immediate needs immediately without much thought. Not an architecture-driven solution, just some patch-up for something.
<ssvb>
slapin: do you have a blog post or something explaining your concerns in more details?
<slapin>
ssvb: my emulator is proprietary, and this all stuff is proprietary, vith various extensions like DPS. if all this went into open, that'd turn the world over (to proper state), but alas i can't do anything about it :(
* ssvb
has not designed the pixman API, but just worked on making its performance reasonable
* Wizzup_
is trying to use initramfs with sunxi and mainline, and I can't get it to load the initramfs ... Any common pitfalls?"
<ssvb>
slapin: I'm afraid that it's difficult to verify your claims
<Wizzup_>
On my chromebook2 (exynos) I just add it to the kernel, and it's built in the uimage...
<Wizzup_>
but on the cubieboard2 it seems to completely ignore it, even though the correct options are set
<Wizzup_>
There's not even a single mention of the initramfs
bertrik has joined #linux-sunxi
<slapin>
the bad thing now is one have to seriously change X11 to use one of its features which are thought to be there, but are not. The solutions are known, but most are either proprietary or thought as know-how by people. Like making normal current apps over X11 over slow channels natively (without proxies, VNCs, etc.)
<slapin>
ssvb: there is no much need. I want to work on some project to improve this situation, but I can't do it alone, but there is quite big opression to it (we don't need X11, we need wayland or sourceflinger, everywhere), so it is very hard to find someone who would pay to improve X11 and opensource the changes.
<hramrach_>
X license allows you to make proprietary X server which is more awesome and never submit the changes back to X
<slapin>
if I find some cooperation and somebody interested in it funding it I'd immediately drop all my other food projects to be on this one.
<hramrach_>
also the thing with proxies is not as much improving performance as it is working around a shortcoming of the current X11 implementation which has no way to reconnect in case the connection is lost
<slapin>
hramrach_: this is something which kills mainline X11 now, as some people want to drop it, some meka proprietary solutions for sale and do not show changes.
<hramrach_>
there is nothing in the protocol saying you cannot recoonect afaik. just no client even tries
<hramrach_>
if they think it's the right thing to do. they will make more money off it short term but it probably kills the platform and hence the profit source long term
<slapin>
hramrach_: this can be fixed, btwm and not very hard, I seen working solutions (on HP-UX + X11R6, but it can be made cross-platform).
<slapin>
now I think X11 needs some large entity to lead it to future.
<hramrach_>
I don't really care what display protocol my apps use. In fact I would got for something simple more like wayland than X11 with its baroque extensions of extensions, anyway
<hramrach_>
not saying that wayland is perfect or that in its current state it is even better than X but they greatly simplified the display part of the protocol and that was good thing to do
<hramrach_>
I still wonder for one thing done right how many nasty surprises wait inside if you tried actually using thie thing
leviathanch2 has quit [Ping timeout: 260 seconds]
Quarx has joined #linux-sunxi
<bbrezillon>
slapin: haven't read the whole discussion yet, but yes libnand is correctly dealing with bitflips thanks to the ECC engine and the read retry mechanism
<bbrezillon>
and mainline kernels do the same (though read retry is not supported for all NAND chips yet)
<bbrezillon>
regarding the possible corruptions you might have with the MTD/UBI/UBIFS layers, these are mostly related with interrupted write/erase operations
<ssvb>
bbrezillon: how does it work? with the "read disturb" problem, reading from one location in NAND may sporadically cause corruption in some other location
<bbrezillon>
and as you stated these are due to MLC nand cells organization
<slapin>
bbrezillon: interrupted writes with libnand are deadly, though, can kill a whole filesystem, regularly seen on mele.
<ssvb>
bbrezillon: this other location has to be accessed in a reasonable time frame for the ECC correction to kick in and fix the problem before it becomes too bad and unrecoverable
<slapin>
bbrezillon: can you formulate task list with NAND left, I'd like to help with something.
<bbrezillon>
ssvb: well I don't know much about read disturb, except that they're not the most common ones
<ssvb>
bbrezillon: from what I read, if you have a frequently accessed file A and a rarely accessed file B, where reads from A may disturb (cause bit flips in) file B, then eventually the file B will be corrupted beyond ECC recovery
<slapin>
bbrezillon: these are common, and are the current source of FUD for libnand/ext3 vs ubifs. When you read page, some bitflip might occur in this and other pages
<ssvb>
bbrezillon: to fix this, some sort of a crawler must walk over NAND regularly and ensure that the errors never accumulate too much
<slapin>
ssvb: this can be made like GC process
<bbrezillon>
yep there is some WIP to support this in mainline
_massi has quit [Quit: Leaving]
<ssvb>
bbrezillon: do you have some sort of reliability stress tests for NAND to ensure that everything really works fine?
<ssvb>
bbrezillon: and maybe with some artificial software simulation for read disturb and other problems
<slapin>
muhahah, what do you expect from capacitor-based memory?
<ssvb>
bbrezillon: what I'm saying is that it's in the best interests of the *driver developer* to ensure that he has good automated tests in his disposal
<ssvb>
bbrezillon: in other words, it's not my problem, but yours ;-)
<ssvb>
slapin: don't they have just the old tests with SLC NAND assumptions, which may be inadequate nowadays?
<slapin>
bbrezillon: is there anything i can do to help with NAND stuff on AWs?
<slapin>
ssvb: no, they changed for MLC too.
konradoo77 has joined #linux-sunxi
<slapin>
ssvb: lots of people tested ubifs these days on mlc, so there is huge demands on tests
bertrik has quit [Remote host closed the connection]
<bbrezillon>
ssvb: I tried to keep focused on getting the NAND controller working, and thus left performances and stress testing on the side
<bbrezillon>
but any help in this area is welcome
<bbrezillon>
anyway if you really want to check MLC robustness against power-cut failures you'll have to develop a power-cut infrastructure, and I'm not sure this is worth the pain because UBI/UBIFS does not support power-cut failures on MLC flashes
<slapin>
hramrach_: the current trend is to simplify and remove features, i know. The wayland lacks features I need. But customers demand wayland, and so I have to hear all this obscene speach around me from people trying to make wayland work on hardware :)
<bbrezillon>
the first thing to do is to propose a solution to handle paired-page corruption when a write is interrupted
<bbrezillon>
then develop a tool to test the robustness of your approach
<slapin>
bbrezillon: controller-wise, is the current implementation feature-complete?
<bbrezillon>
slapin: almost, the only missing things are DMA (not sure this is essential), read retry on specific nand chips (I added support for the hynix one), and boot0 layout (though this could all be handled in userspace)
paulk-collins has joined #linux-sunxi
amitk has quit [Quit: leaving]
<bbrezillon>
rz2k, ddc and quitte tested the driver a few weeks ago, not sure if then ran some stress test on it
<bbrezillon>
another thing I might need your help for is getting stuff mainlined
<bbrezillon>
I'm still waiting for my driver to be reviewed by the MTD maintainer, and showing some interest in it might convince him this is something other people are waiting for
<bbrezillon>
so testing and reviewing the driver would hopefully help me get his attention
kaspter has joined #linux-sunxi
<ssvb>
bbrezillon: is there some standard reserved area in NAND for the board DTB data, and maybe also something like SPD for DRAM?
<bbrezillon>
ssvb: nope, you'll have to declare a partition somewhere
ninolein has quit [Ping timeout: 272 seconds]
ninolein_ has joined #linux-sunxi
<ssvb>
bbrezillon: this sounds like a major oversight, which may cause some hurdles later
<bbrezillon>
ssvb: what do you mean ?
<ssvb>
are we supposed to glue the dtb data to the u-boot binary somehow?
viccuad has quit [Read error: Connection reset by peer]
<ssvb>
or what is the plan?
<ssvb>
and in the case if we are booting the system (both u-boot and the kernel) from the SD card, doing a lookup for the DTB data in some standard place in NAND might be handy
<ssvb>
ijc: ^
<bbrezillon>
the dtb is passed to kernel by the bootloader itself, and a common practice is to create a partition which stores your dtb and load the data in memory from u-boot (using a u-boot cmd)
<ssvb>
who knows where this partition resides?
<bbrezillon>
your bootlader through its bootenv(s)
<bbrezillon>
this is what bootenv are used for
<ssvb>
which brings again the question about "some standard reserved area in NAND"
<ssvb>
if we are expected to have it at the same place in NAND on every board, then we can hardcode this data in the bootenv
<ssvb>
if not, then every individual user is going to have his very unique setup with a lot of hassle to get everything up and running, which kinda defeats the purpose
<bbrezillon>
ssvb: if you want to define a standard the define a standard, but IMHO this is not a good idea, because each board is different, and will most likely use a different NAND
<bbrezillon>
each NAND chips has its own organization (pagesize/blocksize, ...)
<bbrezillon>
forcing everybody to store their dtb at the same place would force you to define a maximum block size
<ssvb>
how is the BROM code able to deal with different NAND chips and boot from NAND correctly on every device?
<bbrezillon>
and then define how many blocks are reserved for the dtb parition
<ssvb>
is defining a maximum block size a bad thing?
syeekick has joined #linux-sunxi
johanbr has quit [Ping timeout: 272 seconds]
syeekick has quit [Changing host]
syeekick has joined #linux-sunxi
johanbr has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
<bbrezillon>
ssvb: actually I don't care :-), you can define a standard, this won't change the fact that there's no reserved are for storing metadata (or firmware data) in a NAND chip
<bbrezillon>
ssvb: but if you think it is worth it, then try to propose something ;-)
<ssvb>
bbrezillon: that's what I'm doing now, before things went out of control ;-)
<ssvb>
and that's why I have pinged ijc
kaspter has quit [Quit: kaspter]
kaspter has joined #linux-sunxi
<ijc>
I've only skimmed things, but the way it typically works today (on sunxi as well as most other platforms) is that the dtb is next to the vmlinuz etc in /boot, and the u-boot default env will hunt for things in that directory. Distros tend to write a boot.scr or an extlinuxconf, both of which can reference the dtb in one way or another.
<ijc>
The std logic is in u-boot/include/config_distro_bootcmd.h
<slapin>
bbrezillon: have you got rid of separate NAND table?
<ijc>
Sadly until the DTB ABI is actually stable in practice having hte kernel and dtb come from the same place is probably best.
<bbrezillon>
slapin: what do you mean by separate NAND table ?
<hno>
slapin, what do you mean by bitflip code?
<bbrezillon>
ssvb: yep, then as ijc suggested relying on a FS layer and a common path in a FS is better than hardcoding a partition to store it
<ssvb>
the ijc's described model has a number of problems
<slapin>
bbrezillon: in libnand there is a separate table for chips with settings like clock speed, etc.
<ijc>
ssvb: It's the "u-boot model", it's a bit crap in various ways but it's what people (including distros) are currently geared up for.
<ssvb>
bbrezillon: for example, swapping a single sd card between multiple allwinner devices will not work right, because you carry the DTB file with you to a different hardware
<slapin>
bbrezillon: and i don't think it is possible to handle boot0 layout in userspace, as it uses different ECC/different randomizer seed, which are lowlevel enough.
<ijc>
ssvb: the u-boot env contains $fdtfile which is the filename to use for that particular platform. Relies on distros using that scheme though. It comes for free via the extlinux.conf mechanisms
<ssvb>
ijc: yes, this is crap too
<ijc>
Well, unless you have the energy to push something else onto all the distros we are basically stuck with it. If you can come up with something better and actually get people to use it then great. I expect that unless it is more general than sunxi you'll have a hard job, and even then you'll be fighting plenty of inertia.
<bbrezillon>
slapin: provided a way to define per-partition ECC and randomizer config
<bbrezillon>
slapin: take a look at my github repo
<bbrezillon>
slapin: the only thing I'm not dealing with is the "I only use 1k on each page" appraoch
arokux2 has joined #linux-sunxi
<bbrezillon>
ssvb: instead of saying this is crap, just think about the variety of platforms using u-boot, some of them have legacy NAND with 1 or 2k page reserving a whole 2MB block (as imposed by MLC chips) would implies loosing 2MB of storage
<bbrezillon>
this is not acceptable on small devices
<bbrezillon>
just don't forget sunxi is not the standard
FR^2 has joined #linux-sunxi
<bbrezillon>
anyway, you'll most likely need to have your own u-boot/u-boot-env depending on your board, so I don't see the problem in defining a per-board env specifying where your dtb is stored (would it be on a raw NAND part or on a FS)
notmart has quit [Quit: notmart terminated!]
konradoo77 has quit [Ping timeout: 272 seconds]
syeekick has quit [Read error: Connection reset by peer]