wolfy has left #linux-sunxi ["Paradoxul homosexualilor este ca, desi nu reusesc sa se reproduca, sunt in fiecare an din ce in ce mai multi. (Tristan Bernard)"]
sgo11 has joined #linux-sunxi
<sgo11>
hi, just install lubuntu to cubietruck, the resolution is not right. I can only choose 1024x768. but my monitor is 1920x1080. how to fix this? thanks.
<sgo11>
oliv3r, thanks a lot. I think this channel is much helpful than #cubieboard. I keep asking many questions in #cubieboard for a week. never get a correct answer there. please let me be here. thanks for the help again.
<wens>
finally got gmac patches out!
<oliv3r>
sgo11: mind you, we are mostly about u-boot and the kernel and will point you at our wiki most of th etime ;)
<oliv3r>
sgo11: but sure, welcome :)
<oliv3r>
wens: yay!
<sgo11>
oliv3r, one more question, if I set screenX_output_mode to 1920x1080. what happened if I plug it to a 1024x768 monitor? will the monitor display anything? thanks.
<oliv3r>
puneet B: ethernet is not working
<oliv3r>
*sigh*
<oliv3r>
sgo11: nope, we don't have adaptive resultion thing; 1 fixed freq. yes very annoying; but that needs time
<sgo11>
oliv3r, got it. thanks.
sspiff has joined #linux-sunxi
sspiff has quit [Changing host]
sspiff has joined #linux-sunxi
hipboi has joined #linux-sunxi
_massi_ has joined #linux-sunxi
ssvb has quit [Remote host closed the connection]
<sgo11>
this question might be stupid. cubietruck has both hdmi and vga built-in. to configure hdmi/vga, I always need to change screen0_output_xxx. what is screen1_output_xxx? thanks.
<oliv3r>
screen1 is the second framebuffer; e.g. dualhead ;)
<oliv3r>
dunno how well it works; but should be fun experimenting with
<oliv3r>
look at disp_mode at the the available options
<sgo11>
oliv3r, thanks. even if I don't quite understand. i will look into it. thanks.
<oliv3r>
well to display something, your computer renders the windows etc somewhere into the memory
<oliv3r>
this is called the framebuffer
<wens>
time to start looking at otg
<oliv3r>
the videocard/chip/output bits also access this specific memory and read it to dispaly it
<oliv3r>
wens: :)
<wens>
oliv3r: the 'video engine' block is like the 2D graphics part in a PC, right?
<oliv3r>
wens: yeah, we have 'disp' g2d gpu the 'mixer' processor
<sgo11>
oliv3r, ok. I am getting it. thanks. :)
<oliv3r>
disp is the output bits, 'kms' i guess comes closest? g2d is the 2D engine, mali our 3d and mixer is a blender, i think it is in the BE bit
<wens>
oliv3r: that's the frontend and backend in the manual?
<oliv3r>
wens: basically; yeah
<oliv3r>
a13 also has IEP or something, image enhancement processor
<oliv3r>
wens: but i'm about 25% guestimating :p i'm not into the disp that heavily
<oliv3r>
sgo11: so you can a choice to use 1 or 2 framebuffers (1 or 2 videocards basically) and 1 or 2 'screens'
<sgo11>
oliv3r, but ct only has one video card. do you mean connecting another video card somehow? I don't know much about hw.
<oliv3r>
sgo11: nah, a20 has '2' videocards, well 1, but you pretend there's 2
<sgo11>
oliv3r, by the way, how to check if my system has 2d/3d engine working fine or not? in x86 world, I used to check by "glxinfo | grep direct".
<oliv3r>
sgo11: same
<oliv3r>
sgo11: glxinfo checks the opengl stack etc
<sgo11>
oliv3r, ok. thanks. i think i need to install glxinfo first. :)
<sgo11>
mesa-utils.
<sgo11>
oliv3r, hm.. the result does not look good. it has "OpenGL renderer string: Software Rasterizer" even if with "direct rendering: Yes". in x86, that means 2d/3d hw acceleration does not work, it's using software instead.
<oliv3r>
sgo11: same here :p
<mrnuke>
oliv3r: [A10] did you notice that timers stop ticking when the CPU is clocked from 24MOSC?
bbrezillon has joined #linux-sunxi
<oliv3r>
sgo11: you now have to venture into the world of installing mali drivers; http://linux-sunxi.org/Binary_drivers but it's not for the feint of heart!
<oliv3r>
mrnuke: erm, no; but haven't looked at that either
<oliv3r>
mripard: ^
<mrnuke>
oliv3r: just don't use udelay when changing system clock (CPU from MOSC). I spent two hours debugging perfectly fine timer code :p
<sgo11>
oliv3r, I cannot believe it. I installed rootfs from cubieboard latest tutorial and packages. it does not provide mali driver and sound driver. just unbelievable. what does cubieboard team do everyday? btw, sorry to trouble you, how to install sound driver again? thanks.
<mripard>
oliv3r: we always use the 24MHz clock for the timer
<oliv3r>
mrnuke: mripard knows all about the timers!
<oliv3r>
sgo11: sound driver should work, but i recall older images having omitted stuff or something
<oliv3r>
sgo11: Ubuntu 13.04 Desktop Linux with 3D acceleration with stage 3.4 kernel for A20 EOMA68 and Cubieboard2 particularly sounds interesting
<mrnuke>
mripard: timer0 stopped ticking while the CPU was clocked straight from the 24M oscillator. I haven't tested other timers, but it was odd to see this
<oliv3r>
no clue if it works or not
<oliv3r>
sgo11: but there's various reasons it doesn't come with 3D drivers, one is that they are binary blobs and may not be redistributed
<oliv3r>
sgo11: once lima driver is done, expect it to be shipped by default with many distro's
<mripard>
mrnuke: which kernel ? mainline?
<mrnuke>
mripard: not kernel. coreboot, but I thought it was a relevant observation for you guys
<mripard>
oh
<mripard>
coreboot works on !x86 boards?
<mrnuke>
yeah, for over a year now
<mripard>
I thought it was just a bios replacement
<mrnuke>
We get that a lot
<sgo11>
oliv3r, that image is for cubieboard2. I am afraid if I install that one, my wifi will not work. let me start from my current system first. thanks.
<mripard>
mrnuke: cool :)
<oliv3r>
coreboot is becoming like u-boot :p
<mripard>
oliv3r: <troll>we have like 10 years before it's bloated and ugly like u-boot :P</troll>
<oliv3r>
sgo11: cubietruck indeed has the wifi stuff pre-made; what kernel are you using? if it's not 3.4 your using something really old anyway
<mrnuke>
mripard: coreboot is pretty modular and well organized. 13+ years old
newleaves has joined #linux-sunxi
<mripard>
mrnuke: I thought it was much younger than that
<oliv3r>
sgo11: good, i think 3.4.61 is our kernel ;)
<mrnuke>
mripard: used to be called linuxbios
<oliv3r>
i remember those days
<oliv3r>
turned out, booting linux straight away wasn't that viable, as the bios set up more things then expected
<oliv3r>
i've been following coreboot/linuxbios very closely over the years
<oliv3r>
mrnuke: how does coreboot related to u-boot in the sense of u-boot.spl and u-boot.bin
<oliv3r>
mrnuke: i mean, the BROM has a limitation of loading a maximum of 24kb from the boot media; how does coreboot deal with that?
<wens>
oliv3r: cubieboard has their own repo
<oliv3r>
wens: *facepalm*
<mrnuke>
it's simpler than that. Hardware init got more complex, needing more code, and ROM sizes got smaller, so you could no longer fit a kernel in there
<oliv3r>
so bootblock is the BROM or allready part of coreboot?
<oliv3r>
ramstage is the setting up of the RAM controller?
<mrnuke>
oliv3r: so I use the bootblock to chainload romstage, and so on
<mrnuke>
it comes from x86, where real mode was limited to 64KiB, so we were using the bootblock to switch to 32-bit mode and load romstage
<mrnuke>
romstage is supposed to do memory initialization and that kind of stuff
newleaves has quit [Ping timeout: 265 seconds]
<mrnuke>
then ramstage has all the bells and whistles
<mrnuke>
not as useful on ARM to have all the stages, but they didn't get in the way
foubarre has joined #linux-sunxi
<oliv3r>
so spl -> spl -> u-boot -> kernel
<oliv3r>
as I think u-boot combined bootblock and romstage
<mrnuke>
yeah, uboot combines them
<foubarre>
I am looking into the recent "looks like a regression" about OTG that push cpu load to stars: https://github.com/cubieplayer/Cubian/issues/183 . Is there a place where i can find what is going on on this point, if at least it is handled by someone?
<mrnuke>
I'm initializing the memory in the bootblock (go figure), then using romstage to read our devicetree format and set up voltages and cocks
<mrnuke>
uuumh, make that clocks
<foubarre>
lol
<oliv3r>
mrnuke: you so dirty mon
<mrnuke>
hey, can't keep linux happy without a good c(l)ock, can you?
<oliv3r>
foubarre: afaik; a default load average is caused by the hostmode of the OTG controller; you can change it from otg to either/or and should be ok; has to do with polling a gpio pin
<oliv3r>
mrnuke: ;)
<foubarre>
oliv3r: problem is that i'm desperate having OTG work on a distribution. None work with 3.4 kernels and i can't retrieve old ones that used to work.
<oliv3r>
foubarre: changing the FEX makes the difference, so older configs probably changed the polling in the fex file
<oliv3r>
foubarre: you'll hav eto wait for Wens to fix up the musb driver; and have it backported
<mripard>
wens: good job for the gmac, it looks quite neat from a quick look at it :)
<foubarre>
oliv3r: oh, great so now i know that someone is around that part of things. I'll poke wens about this. This is such a problem to me..
<foubarre>
oliv3r: .. and my projects.
<foubarre>
oliv3r: thanks for the hint
<wens>
mripard: thanks
<sgo11>
oliv3r, I just find out my wifi is not working either. this latest rootfs has nothing. I have to figure out how to install drivers for RTC, GMAC, WIFI, S/PDIF, LI-BAT and SOUND. this is just too much.
newleaves has joined #linux-sunxi
<oliv3r>
sgo11: looks like the modules are simply missing
<oliv3r>
sgo11: check your /lib/modules/*
<oliv3r>
sgo11: compare the directory names with uname -a
<oliv3r>
sgo11: but i know nothing of the cubian images; so you actually need one of those devs
<foubarre>
wens: hi. Just asking: are you somewhere near enabling OTG?
<oliv3r>
foubarre: lol foubarre he sated earlier toay; like 45 minutes ago; it was time to START on the musb stuff
<oliv3r>
foubarre: i can tell you this much however, we know that the OTG driver is based on mentor graphics Inverta usb-otg IP; his driver is allready mainline as musb
<foubarre>
oliv3r: ah. Great. WAs not aware, or misunderstood.
<wens>
i still need hans to push out his usb phy driver first
<oliv3r>
wens: 09-01-14 : 18:57
<oliv3r>
wens: e.g. last night :p
<oliv3r>
wens: how does the otg and oehci relate?
<wens>
oliv3r: they share the same usb phy/port control registers
<wens>
i would take hans' simple usb phy driver, and add the otg bits for usbc0
<oliv3r>
wens: ohh, i thought they where completly seperated hardware/ports
<oliv3r>
didn't know they shared anything
<oliv3r>
wens: but hsi patches are pushed :p
<wens>
hsi?
foubarre has quit [Read error: Connection reset by peer]
<oliv3r>
his
<sgo11>
oliv3r, I asked question in #cubieboard. nobody replies. that channel is dead. sorry to interrupt you again. can you please show me a wiki page about sound card driver install? thanks.
<wens>
found it
<wens>
in his tree; he hasn't posted them yet
<oliv3r>
hansg needs to idle more here :p
<oliv3r>
i like how he handles the clock names, though i don't fully understand yet
<oliv3r>
wens: i'm reading the reviews on the linux-sunxi ml; should also be on the lkaml and lkml no?
<wens>
aren't they debating it?
FR^2 has joined #linux-sunxi
<wens>
he only posted the patches for ohci/ehci platform drivers
<wens>
he stated after these changes were accepted, he would post the phy driver and dt changes
<sgo11>
one more question, is that possible to shutdown cubietruck with power supply connected? it always reboots.
foubarre_ has joined #linux-sunxi
<wens>
in 3.4 kernel you should be able to
<oliv3r>
sgo11: it's not really a 'driver installation' you either have incorrect parameters for sound in your script.bin (unlikly) or missing the sunxi-codec audio driver; if your not scared to compile your own kernel; try stage/sunxi-3.4; if you isntall your own built kernel + its kernel modules; most things should work. i don't understand what is missing in the image, but i'm not familiar with it either
<oliv3r>
wens: ohh, i'm overlooked that; sorry
<oliv3r>
wens: should be; but doesn't reliably work
<oliv3r>
sgo11: i noticed the same on hansg's fedora 19 image; i saw it reboot and i seen it halt, but not power down
<sgo11>
wens, are you talking to me? 3.4 kernel, be able to shutdown?
<oliv3r>
sgo11: he was ;)
<wens>
sgo11: it worked for me the couple of times I used 3.4 kernel
<sgo11>
I am using 3.4 kernel. but it doesn't help. always reboots.
<oliv3r>
sgo11: sometimes reboots, sometimes halts, never powers down; it seemed it depended on the perhipals or powersource, not sure yet
<oliv3r>
sgo11: try running 'sudo poweroff'?
<wens>
hah, musb has a function named "nuke"
<sgo11>
oliv3r, thanks. I just don't understand. what those cubieboard guys thinking? a machine can not shutdown. let me try that. I always use "sudo shutdown -h now".
<sgo11>
oliv3r, that roobots too.
<sgo11>
s/roobots/reboots/
<oliv3r>
sgo11: let me power mine up :)
<oliv3r>
sgo11: well these chips actually never truely power down
<oliv3r>
sgo11: on a tablet for example, if you power down, it _always_ reboots
hsildaerD is now known as Dreadlish
<oliv3r>
sgo11: the bootloader reads a 'config' partition where the OS put a 'shutdown' bit on,
<arokux>
wens: gmac <-- cool. is it working in gigabit mode in u-boot? (it didn't afair)
<oliv3r>
sgo11: and then starts the 'battery charging, screen off' 'OS'
<oliv3r>
arokux: yeah it does :)
<arokux>
cool. you know, while I was working on the code I kept asking myself why things are so slow. now, that I just watched for the last 4-6 weeks I've noticed the development is actually fast :)
<oliv3r>
arokux: well things have been picked up since you wher egone :p
<oliv3r>
arokux: i think we have 2 guys now committing patches too :)
<arokux>
oliv3r: hannsg and who else?
<oliv3r>
btw, in case anybody is (back)reading; i still need a 3rd reviewer for my book;
<oliv3r>
arokux: wens :p
<oliv3r>
arokux: chen-yu tsai :)
<oliv3r>
arokux: the mainline_effort page has been updated to reflect that
<arokux>
your book?
<oliv3r>
yeah i'm writing a book about sunxi for packt publishing; they wanna call it cubieboard; but i want to focus on Lime/sunxi generically more
<arokux>
yes, but I know about great efforts of wens :)
<arokux>
a book on sunxi? interesting :) I guess you need some docs for that :p
<foubarre_>
wens: if i can be of any help on the OTG, please ask.
<oliv3r>
arokux: nah; it's a user book; think like those rasberry-pi starter books
<oliv3r>
arokux: setting up sd cards, etc
<oliv3r>
installing programs etc; more a generic linux book i suppose :p
<arokux>
I always wondered why such books. it is an ordinary embedded linux platform. 5% sunxi + 95% linux distro.
<wens>
oh crap, hansg is using the new general phy framework
<wens>
musb needs the old usb_phy stuff
<oliv3r>
wens: you mean musb needs to be ported :p
<oliv3r>
arokux: well this book will be atleast 25% sunxi :p
<oliv3r>
arokux: but yeah, 75% general linux stuff
<oliv3r>
arokux: it's a 'minibook' really
<arokux>
oliv3r: is it going to be "open source"?
<oliv3r>
arokux: the book; it won't be creative commons :(
<oliv3r>
arokux: but it earns me a little bit (really not a lot) of money and helps spread the sunxi word; so that's a plus
<ynezz>
and Linux word :) the more, the better
<arokux>
oliv3r: yes, definitely. I am very glad some of us can actually make some living for sunxi.
<oliv3r>
mrnuke: how dare you bash the mmc/sd code so badly! it needs heavy refactoring; I think its the most ugly code
<JohnDoe_71Rus>
arokux: welcome back
<arokux>
JohnDoe_71Rus: thanks!
<mrnuke>
oliv3r: oops. Forgot someone here actually reads the coreboot ML
<wens>
oliv3r: nope, the whole usb otg needs to be ported
<oliv3r>
wens: ouch
<oliv3r>
wens: i did notice that with a lot of the arm stuff 'oh this framework is outdated or doesn't support everything needed for this IP'
<oliv3r>
mrnuke: i'm interested in code sharing however between the platforms
<oliv3r>
mrnuke: linux <-> *boot is probably less likly; the *boot drivers are far more simpler and don't need every feature and big frameworks
<wens>
oliv3r: some of the platforms are old i guess
eyal has joined #linux-sunxi
<arokux>
so coreboot can now boot on bare sunxi and have linux as payload?
<wens>
why couldn't allwinner have used synopsys ip for otg
<wens>
dwc3 seems more active
<oliv3r>
mrnuke: but *boot should an possibly can share drivers?
<oliv3r>
wens: musb probably was cheaper
<oliv3r>
arokux: nah; very early stages they are at right now
<mrnuke>
oliv3r: we're going to be doing a generic interface in coreboot. I'm not sure how it will look like yet
<wens>
dwc3 is being ported to generic phy framework
<arokux>
oh, ok, but this is the objective. and now comes the real question: how is it better than u-boot? :)
<mrnuke>
arokux: I yeah, it's possible to boot a linux kernel directly. I have WIP code that can load uboot as a paylod, and that loads linux from SD
<mrnuke>
arokux: it's quality and readable code
<arokux>
mrnuke: ah, nice. even I dislike u-boot.
<oliv3r>
well in the past; coreboot and u-boot where 2 seperate things, one for embedded use, coreboot for x86
<oliv3r>
but they are kinda both doing the same now :p
<wens>
arokux: hey, google just found your post on usb phy framework
<mrnuke>
arokux: it's layered into components.
<arokux>
wens: yeah, I had a question if I should use it, ppl said no. but hansg decided this is the way to go :)
<mrnuke>
arokux: we don't have to #ifdef every single step just because things are hooked up differently on this board than the prebious one
<mrnuke>
all these things try to load a kernel and OS and do too much stuff. We do the bare minimum, and that is init the hardware
<wens>
arokux: hansg is using the "generic" phy framework
<arokux>
mrnuke: so now it is coreboot->u-boot->linux. is it planed to remove u-boot from this chain at some time?
<arokux>
wens: ok.. I do not know much about all these frameworks... :(
popolon has joined #linux-sunxi
popolon has joined #linux-sunxi
<wens>
arokux: generic phy only does on/off init/exit
<wens>
but you can do all kinds of phys, samsung has put in phy drivers for hdmi and sata
<wens>
usb phy framework seems geared towards otg stuff
<mrnuke>
arokux: not really. what happens after coreboot is not our concern. I can see someone using depthcharge instead of uboot, thogh
<arokux>
wens: sometimes I ask myself why a framework should be used to set/clear several bits
<sgo11>
if I have lubuntu-desktop-nand.img.gz, is that possible to dd it to sdcard? I think they should be similar. I don't understand why there are two versions, one for nand and one for sd card. thanks.
<wens>
arokux: proper seperation, especially if they share a common bus
<arokux>
mrnuke: I'm confused. why to add a (quality coded) coreboot in front of (ugly) u-boot? sorry, for asking too many questions.. :)
<wens>
in our case, the 3 usb ports share a common register to control some bits
<wens>
and ports are shared between ohci and ehci
<arokux>
wens: yep, this was my problem and why I was asking people how to solve it. they suggested to do some other thing, but then hansg came along and over weekend did the job with phy driver.
fredy has quit [Excess Flood]
<mrnuke>
arokux: I don't care what the payload is. It can be WinCE for all we care. uboot makes a lot of assumptions that we don't, and it would probably be a pain to make uboot reside in an SPI chip, for example
fredy has joined #linux-sunxi
<arokux>
mrnuke: I see. the latter - "u-boot in an SPI chip" is going to be tried at some time. hardware manufactures (of the sunxi boards) were advised to include such a chip. then there will be no need for SD cards, one could boot from a usb stick/hdd
<oliv3r>
mrnuke: to be fair, the ifdef thing is mostly because we haven't done allt hat cleaning up yet :) mind you, this is far from mainline u-boot quality. IF we can fit if () over #ifdef into the 24k; we may actually support multiple chips with 1 u-boot
<oliv3r>
mrnuke: but since we only have < 1k space left; we'll have to see
<mrnuke>
oliv3r: Im @19K with raminit and MMC
<arokux>
oliv3r: I think mrnuke means ifdefs in the core code of u-boot, not our ifdefs
<oliv3r>
sgo11: nand is quite idfferent from mmc; 2 images are probably needed to have fstab etc right. the biggest difference in the images will be bootloader
<oliv3r>
wens: how about a PHY framework driver for sata; sounds sensible no?
<oliv3r>
mrnuke: as for SPI; that will happen soon and it won't be a pain at all :p
<sgo11>
oliv3r, I can only find lubuntu v1.01 for nand img. there is no sd img. can I use v1.0 bootloader and extract rootfs from v1.01 nand img for my microsd? thanks.
<mrnuke>
oliv3r: I'm glad YOU are the one doing it (AKA "not me") :p
<oliv3r>
sgo11: rootfs should be 'ok', the big diference is really only the bootloader
<oliv3r>
mrnuke: :p
<sgo11>
oliv3r, I just want to have sound/wifi and other drivers. if I use v1.00 bootfs and v1.01 rootfs from nand.img, will those drivers work? thanks.
kivutar has joined #linux-sunxi
<wens>
oliv3r: not sure if they intend to have all phy drivers under the generic framework
<oliv3r>
sgo11: the rootfs contains everything from the kernel, to the modules; the kernel version and module version need to match
<oliv3r>
sgo11: the only thing you have to watch out for, is to not replace your 'uboot partition' that holds your kernel, your script.bin etc
<oliv3r>
sgo11: it has to be an exact match; worst thing that can happen is, your kernel boots, but doesn't find the modules; you can then simply extract the modules from the image and place them in /lib/modules
rellla has joined #linux-sunxi
<oliv3r>
rellla: hi! how are your xbmc trials coming?
<sgo11>
oliv3r, Do you mean I don't need to install v1.01 and I just need to mount nand.img and copy /lib/modules to my current v1.00 system and then reboot? will this work? thanks.
<wens>
best not use emdebian toolchain for 3.4
<oliv3r>
sgo11: probably yeah
<oliv3r>
sgo11: same goes for the kernel; you can just extract the kernel binary and place it in your boot partition
<rellla>
oliv3r: negative. atm i'm trying to get VDR working with vdpau and idling my sunxi efforts a bit since ct is running quite stable. i have to do some web-application coding atm :o
<sgo11>
oliv3r, do you mean uImage ? should I replace uImage? I am a newbie on this. thanks.
<rellla>
oliv3r: i tried to get some contact to vidon.me to open their sources for their allwinner-xbmc built
<oliv3r>
sgo11: yes, uImage is a (special packaged) kernel image; rename the old image to uImage.old; put the new one in place :)
<rellla>
it is reported to run well at least with android...
<oliv3r>
'with android' meh
<rellla>
meh, too
<sgo11>
oliv3r, thanks a lot. why the bootloader is so important here? does bootloader in arm mean something like grub? I thought grub is a bootloader. thanks.
<oliv3r>
sgo11: exactly, but because some hardware limitations, we have 1 bootloader depending FROM what you boot; so there's a bootloader when booting from mmc; and one when booting from nand;
<rellla>
i'm more active in motivating some people around VDR to dig into sunxi. we need some kind of useable thing (xbmc, vdr ...) with or without blobs, just useable to get more (multimedia)people, that are interested in this soc. not just kernel devs ;)
<oliv3r>
rellla: that's why i keep bugging you :)
<sgo11>
oliv3r, thank you very much for the help. I will try this later today. gotta go home now. thanks!!!
<rellla>
oliv3r: too much $work$ atm, and the rest of the time i'm quite happy to do things with my 7mths old "little" rellla ;)
<rellla>
oliv3r: but xbmc is on schedule. i want to use this devices as clients all around, once my housebuilding finishes. otherwise i don't know what to do with all the lan cables...
<rellla>
how's your sunxi book and fosdem preparation going?
<oliv3r>
sgo11: good luck :)
jemk has joined #linux-sunxi
<oliv3r>
rellla: aww bebe
<oliv3r>
rellla: are you attending either?
<sgo11>
oliv3r, thank you very much again. ^_^ see you.
<oliv3r>
rellla: for the book i'm looking for 1 more reviewer :)
<juanfont>
rellla, oliv3r, but xbmc with vdpau has the issue of GLES lacking from GL_NV_vdpau_interop
<juanfont>
or that is what i've understood...
sgo11 has left #linux-sunxi ["Leaving"]
<rellla>
juanfont: shouldn't it be possible to use vdpau only for decoding and the existing allwinner gles code for presentation?
<rellla>
juanfont: i'm too less skilled for vdpau, though knowledge is growing by reading ...
<rellla>
oliv3r: i need some input for my new ebook-reader ;)
<juanfont>
i have absolutely no idea xD i've inferred it from xbmc compilation. it doesn't like compiling with gles and vdpau support
<rellla>
oliv3r: did you solve your /dev/sda1 issue?
<rellla>
oliv3r: i had unreproduceable issues with sata too, which resulted in a buggy uEnv.txt. rootfs on /dev/mmcblk0p2 was fine. mount /dev/sda1 too. but rootfs on /dev/sda1 wasn't possible
<rellla>
iirc i cleaned out the fatload-sth args
<oliv3r>
rellla: well i want to load the entire kernel from the sd card; but only the the rootfs from sata
<oliv3r>
hansg said should be possible no prob
<rellla>
ok. seems reasonable.
<mrnuke>
damn moronix
<mrnuke>
I didn't commit the initial cubieboard support for an hour (mind you, it was only enough to get you a console), that moronix hailed me as the hero who brought coreboot to the cubieboard
<mrnuke>
and now people are asking about it
foubarre_ has quit [Remote host closed the connection]
<mripard>
mrnuke: don't worry, FEX will make it impossible to bring A10 support to coreboot :)
<wigyori>
powervr wasn't supposed to be burnt to ashes already?
<oliv3r>
we wish
<mnemoc>
hopefully having an inexpensive 8x a15/a7 soc will motivate people to RE the damn SGX
<mnemoc>
specially having a devboard with jtag
<oliv3r>
heh
<oliv3r>
that'll be like a 2 year endevour
<jinzo>
at least
<oliv3r>
atleast i got my fosdem setup almost done
<oliv3r>
spoiler; i'll be using a TI_CHronos!
mkutsevol has left #linux-sunxi [#linux-sunxi]
<mnemoc>
haven't the beagle guys already started REing the sgx544?
<juanfont>
one noob question. it is really hard to create a brick when messing with the NAND, having access to fel mode and/or a SD card reader, isn't it?
<aep>
didnt rpi get bcom to open sauce some drivers? maybe there's hope for powervr...
<oliv3r>
juanfont: it is next to impossible to brick your device
<nikrou>
:-)
<oliv3r>
juanfont: a10 boots first from mmc0, always
<oliv3r>
aep: no they didn't
<panda84kde>
aep: unfortunately not. RPi had Broadcom spit out Yet Another Binary Blob(TM)
<aep>
ooh. meh
<oliv3r>
aep: what rpi folks did, was have broadcom create a message passing shim driver
<aep>
well better than nothing
<juanfont>
aep, and rpi devs work for broadcom. that usually helps...
<oliv3r>
erm it IS next to nothing
<juanfont>
oliv3r, cool :)
<oliv3r>
it's like opening the source code to 'cat' on ubuntu 13.10
<nikrou>
oliv3r : what can I do after having fedora running ? What is your idea ?
<libv>
it's in 3 weeks, everyone has booked flights already
<oliv3r>
who is 'zoobab'
<oliv3r>
and hansg proposed it on the ML
<oliv3r>
but i don't see where there's time
<oliv3r>
sat/sun people tend to watch presentations
<ccaione>
yuuuu I'll be in bruxells the 31st
<oliv3r>
yeah in the evening
<ccaione>
is there an official schedule for the hackaton?
* mnemoc
is a sat/sun person expecting to watch some talks :p
<libv>
ccaione: no, it's basically a brainfart that zoobab had this morning
<ccaione>
libv: yeah, sorry, I'm a bit slow
ganbold_ has joined #linux-sunxi
<montjoie[home]>
alea jacta est
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
Black_Horseman has quit [Remote host closed the connection]
newleaves has quit [Quit: Leaving]
shineworld has joined #linux-sunxi
shineworld has left #linux-sunxi [#linux-sunxi]
penghb has quit [Quit: Leaving.]
rellla has quit [Ping timeout: 272 seconds]
<oliv3r>
bah i'm starting to hate fedora!
Quarx has quit []
Quarx has joined #linux-sunxi
Quarx has quit [Client Quit]
<libv>
hehe
<libv>
every distribution has its own quirks
setkeh has quit [Ping timeout: 276 seconds]
<libv>
oliv3r: because ATI idiots (well alex deucher) were blaming us for everything, and they ran into an issue they couldn't debug, they blamed opensuse.
Quarx has joined #linux-sunxi
<libv>
oliv3r: i then went and installed 2 ubuntus, 2 debians, 1 fedora and a second opensuse
<oliv3r>
the hate was unjustified; other then i keep typing apt over yum
<oliv3r>
i wrote default instead of defaults in /etc/fstab :(
<libv>
and told them: works for me, please go install an opensuse now
<oliv3r>
lol
<libv>
wasn't a fun few days though
<libv>
because you get to run into all the quirks
<libv>
my conclusion, 6 years ago is, debian is baremetal, but this is known. ubuntu is the nanny os, you have to work real hard to get anything special from it (like installing to a specific partitiion), opensuse (then) got me a basic desktop on the right partition by offering me just about enough options but also not too many. Fedora back then... well. It was halfway between debian and opensuse and it needed the most work to get anywher
<libv>
i do remember that the first time i installed opensuse, i complained about some bits and bobs in its installer ui.
<libv>
so it really is about what one is used to deal with
dlan_ has quit [Quit: leaving]
dlan has joined #linux-sunxi
<wens>
i thought slackware was the barebone system
<wens>
anyone still using it?
<libv>
wens: i really rather doubt it :)
<libv>
wens: well, not anyone who does other useful work
<libv>
and the issue was something we at SuSE had with radeon hw, and the ati idiots told us it was our own fault for using opensuse. i think it turned out to be a hw specific issue, which of course they hadn't been willing to tell us about.
<libv>
it's been a while :)
<tkoskine>
My favourite used to be Caldera OpenLinux until the company merged with SCO and went crazy. Old SuSEs (5.x etc) used to be nice also, but then Novell bough them. Currently, I used a mixture of Fedora, Debian, and Ubuntu depending on what I need to do.
<libv>
tkoskine: what was the issue with novell buying SuSE?
<libv>
tkoskine: a statement like that really shows that you have no idea.
<tkoskine>
libv: I think the quality dropped a little and they also introduced various different versions (Personal, Pro, etc) and it looked somewhat messy in general.
<libv>
tkoskine: ah, you are right there
<libv>
tkoskine: novell laid off a lot of people over many rounds
<libv>
tkoskine: first few rounds were partly justified though
<libv>
but in the second half of the 2000s, there really wasn't more to be squeezed from SuSE without very directly damaging the product
<oliv3r>
sorry, back; had to $work :S
<libv>
tkoskine: and the different versions is just an attempt to try to sell things and to actually make money
<oliv3r>
libv: you forget to mention my baby; gentoo ;)
<libv>
tkoskine: i think they settled on SLE(D) and openSuSE in the end
<libv>
oliv3r: for those who like to compile all day long :p
<oliv3r>
wens: i used slackware AGES ago; but yeah its far more barebones then debian; debian has packagemanager; i don't think slackware really has that
<libv>
tkoskine: the really big issue was the following...
<libv>
tkoskine: novell wanted to get into the linux game. So they went and bought ximian
<libv>
and then were surprised that they hadn't bought a linux, but just some guys working on a desktop environment
<tkoskine>
Yep.
<libv>
luckily, SuSE hadn't been faring well after the dotcom crash, and they were almost bankrupt
<libv>
so with a little nudge from IBM, novell went and bought that a while later
<libv>
this meant that ximian guys were already established
<libv>
so one of the effects is that a strongly KDE oriented distribution suddenly had to become gnome based
<libv>
the other is that novell, for quite a while already, had been doing nothing more than buying promising tech companies, throwing loads of people out trying to make it profitable, and then wondering why the product broke and where the customers went
<libv>
it's really a miracle that SuSE is still around today
<libv>
and most of that is due to the stubborn assholes that form SuSE
<libv>
there really is a lot of things that novell wanted to do which got an amazing amount of pushback
<libv>
so all of that suse hating for being a novell and thus microsoft tool is unbelievably unjustified
<libv>
but it is how people loved to represent SuSE in the second half of the 2000s
<libv>
and the ms "partnership"... man.
<libv>
Novell and MS had a chat about patents. They both zipped open their pants and put their members on the table.
<libv>
Microsoft suddenly promised not to sue Novell/SuSE for any MS patent linux might breach, and agreed to buy 30m USD worth of SLE licenses for the next 5 years
<libv>
where all the noise comes from... you go figure it out
<libv>
but SuSE just got 30m usd free cash every year for the next 5 years, and MS pretty much became unable to sue anyone for anything linux breached.
<libv>
when truth mattered in any way, one would actually applaud novell
<libv>
(it's the one main thing they did well, that and the SCO case - they way they squeezed SuSE to death and only allowed it to shrink is what they really did bad)
<slapin_>
libv: and how about thousands of MS patents infridged by Linux? as they say...
<libv>
slapin_: did redhat, canonical or suse/novell/attachmate ever get sued for any of them?
<libv>
slapin_: companies like ibm didn't need such protection
<libv>
slapin_: i think MS is doing some things to android device makers though, but i do not think that the details are clear
<slapin_>
libv: IBM is still too big
<libv>
slapin_: novell, with its old SCO unix and netware patents really took the fuse out of the box of tnt
<slapin_>
libv: and I think MS doesn't see GNU/Linux as a competitor, only Android, that is.
<libv>
slapin_: but the issue was that an almost dead company like SuSE was at one point, suddenly had a multi billion dollar bank backing it, and then got 30m usd per year extra cash.
<libv>
slapin_: canonical was not a threat at the time
<libv>
now that SuSE has shrunk that much, it's no longer a threat either
<libv>
now the arrows are aimed at canonical
<libv>
and this is why i have been outspoken about some of the crap thrown at canonical
<libv>
not because canonical didn't or doesn't make mistakes
<slapin_>
libv: I think the only real competitors for MS on the same markets is Google. Neither Canonical nor Redhat are real competitors - they could becoma partners rather easily.
<libv>
but it's just out of proportion
<libv>
slapin_: redhat does servers, period.
<libv>
slapin_: they only do some desktop to keep the competition at bay, as they know that if others sell customers a desktop, they also sell servers to go with it
<libv>
slapin_: redhat really has a lot of money to burn
<libv>
slapin_: and they, to my knowledge, never did what canonical and suse have been doing for the past 5-6 years, which is work with companies like dell, msi, hp on preloading linux on their machines and selling these linux based machines directly
<libv>
if you take the desktop seriously, this is what you do
<libv>
slapin_: redhat will not lose servers overnight. ms has always wanted the server market, and to some extent succeeded because they sold desktops
<slapin_>
libv: I was supporting the web CRM system, which was made here with MS and Redhat cooperation under some integrator umbrella, as databases and storage systems were running on Redhat and Juniper, and web backends were MS servers (most systems seems to be built like this these days), getting support from both MS and Redhat (and having tea parties), so i think they really cooperate rather than compete.
<libv>
slapin_: sure, any company will sell any support indeed :)
<libv>
and a company is never a single faction
<libv>
slapin_: ms is actually actively cooperating with samba
<libv>
there was a time where they needed to be forced
<slapin_>
libv: the damn thing was engineered with perople from Redhat, MS and Juniper, so I think server market is not that much competitive, like desktop one, and has much more money to harvest than desktop market.
<libv>
but you do not see people shouting: die, samba, die
<oliv3r>
slapin_: ! mtd hacker extrodinair!
hipboi has left #linux-sunxi ["Leaving"]
<libv>
oliv3r: we caught him!
<libv>
oliv3r: all i had to do was built an excuisite trap disguised as one of libvs typical frustrated old fart rants, and bingo!
* slapin_
hides under carpet
<slapin_>
well, I'm still on it, it is a bit delayed, as I'm changing jobs ATM
<oliv3r>
libv: about gentoo btw; i find it a very compfy disto to dev with; as you always have all headers etc. yeah it can be pita distro; but meh :p
<libv>
oliv3r: all distros are pitas, in their own particular way :)
<libv>
oliv3r: just like firefox and flavouroffice will always be memory hogging, slow and buggy
<libv>
oliv3r: if you're comfortable with it, great
<libv>
oliv3r: i just do not have the patience to build everything, or to start builds before i stop working on the machine
<libv>
i tend to fall off my chair before i finally stop typing and go to bed, so there's no way i will start a build in the background :)
<libv>
it just doesn't work, for me :)
<slapin_>
libv: so you can't work with OpenEmbedded, too.
* slapin_
looks at his loudly screaming dual E3 server
<libv>
slapin_: not for my main machine, no
HdkR has quit [Remote host closed the connection]
<oliv3r>
slapin_: bbrezillon started to commit a simple (no dma no ecc) mtd driver to the ML i think
<oliv3r>
libv: heh, 6 cores, 2 monitors baby! I build why i do other things usually
<oliv3r>
libv: it does help me a little staying in the linux game, as otherwise, i'd probably forget many a things
<oliv3r>
slapin_: so what job you getting now? mtd related ;)
HdkR has joined #linux-sunxi
<oliv3r>
crap i must have done my rsync job wrong, since a 3gig fs is filling up a 53g one :(
<slapin_>
oliv3r: any links?
<slapin_>
ah, found it.
<oliv3r>
slapin_: sorry; was peeing :p
<oliv3r>
there's some info in the log here; and on ML too
<libv>
slapin_: i needed to install to nand because sdcard and uart are multiplexed on a device
setkeh has joined #linux-sunxi
<libv>
slapin_: so i ran into lack of documentation and loads of issues, and generally stirred things up
<libv>
slapin_: as luck had it, bbrezillon posted patches at the same time
<oliv3r>
slapin_: did kz1 contact you about potential sponsorship for the mtd work?
<slapin_>
oliv3r: no, but I was not checking mail properly last 10 days
lioka has quit [Ping timeout: 246 seconds]
<oliv3r>
kz1: ^ :p
<libv>
actually...
hero100 has quit [Remote host closed the connection]
<libv>
we cannot use nand properly atm, at all, can we
<libv>
we cannot just point fdisk at it and think it'll all be ok
<libv>
because there is that area we cannot access
<libv>
it should be possible to put a proper partition scheme on it, if one avoids the FFed out area
hani has joined #linux-sunxi
<libv>
so you'd have to be real careful
HeHoPMaJIeH has quit [Quit: Leaving]
<libv>
for sunxi-3.4 that is
<oliv3r>
libv: no, you need nand_part; fdisk will puke at you
<libv>
oliv3r: always?
<oliv3r>
never understood why the partition table isn't editable by fdisk
<libv>
oliv3r: why?
<oliv3r>
i think because the nand driver reads and parses it
<oliv3r>
i mean, you always see the partition layout when it boots
<oliv3r>
(when the nand driver boots)
<libv>
i think it could be that fdisk is just happy
<libv>
but that then libnand ruins the party for everyone
<libv>
worth a test on a development board
<oliv3r>
i tried running fdisk once, it pukes in your face and is very unhappy :p
<libv>
ok :)
kivutar has quit [Quit: Ex-Chat]
<oliv3r>
hmm, i pukes less now
<oliv3r>
it shows me an empty disk (on a filled one) so that's progress I suppose
<libv>
it might complain when writing out
<libv>
although there should be no reason why that is so
<slapin_>
the partition of nand is diffrent from disk, as it is not stored anywhere on NAND in general case, most of times it is assumed and hardcoded somehow, or stored in some application-specific way
hani has quit [Ping timeout: 252 seconds]
<oliv3r>
kinda like mtd doesn't have a partition table i guess?
<libv>
#define MBR_START_ADDRESS0x0
<slapin_>
oliv3r: not DOS partition table
<libv>
for nand-part
<slapin_>
oliv3r: neither GPT ones
<slapin_>
libv: NAND partition table is generally in kernel's configuration
lioka has joined #linux-sunxi
<libv>
slapin_: is there a reason why that is so?
<slapin_>
libv: you either hardcode it or do other means for configuration
<oliv3r>
slapin_: but why!
<libv>
slapin_: or is it just how people tend to use it today
<oliv3r>
why no partition table; same why goes for mtd
<slapin_>
libv: as NAND was never intended to be used by DOS I guess
<libv>
slapin_: bs
<libv>
slapin_: it's just storage
<slapin_>
libv: as other flash memory, I think.
<oliv3r>
slapin_: but why no gpt then?
<libv>
slapin_: you put a partition table on an sd
<slapin_>
libv: many translations layers understand DOS partitioning
FreezingCold has quit [Ping timeout: 272 seconds]
<slapin_>
oliv3r: it is just something which understands some command set. It can be used by MCU to store its crap without any partitioning and filesystems at all
<libv>
slapin_: i hope that the mtd infrastructure does too, and properly rescans the partitioning table, if it exists
<libv>
and then provides the right device entries
<oliv3r>
ah, that sounds reasonable reasoning
<slapin_>
it is just low level enough to get rid of all this high level crap, as it is self contained and doesn't care for higher layers
<oliv3r>
mtd is of course from the embedded world where less is more i guess
<libv>
slapin_: you can just put a raw fs on any storage
<oliv3r>
so it jus t'grew' to not have a partition table
<slapin_>
just ask why NICs this days won't understand TCP
<libv>
i really rather doubt that mtd doesn't do partitioning
<oliv3r>
and most embedded systems had very little space to begin with, 2mb FS isn't unheard of (old wrt's for example)
<libv>
all other storage does
<oliv3r>
libv: i can't find anything, all i see is commandline passing of, or hardcoded
HdkR has quit [Remote host closed the connection]
<oliv3r>
What’s special in MTD partitions is that there is no partition table as in block devices. This is probably because flash is an unsafe location to store such critical system information, as flash blocks may become bad during system life.
<oliv3r>
but not sure how valid that is
<oliv3r>
actually it is very valid
<oliv3r>
FTL is higher
<slapin_>
libv: NAND doesn't care for such things, mtd is just a layer on top of flash memory interface, so all you need is to put your partitioning info using the means MTD provide you and be happy
<libv>
oh, i see
<libv>
the filesystem is probably responsible for wear levelling and such
<slapin_>
libv: yeah, and in case of ubifs, it can be implemented multiple ways
<libv>
seems like it historically grew wrong
<libv>
or that someone involved early on thought that the dos partitioning system was stupid and it need complete reinvention
<slapin_>
and you can write your partitioning info in u-boot variable, and u-boot can do some fdisk-style interface for that if you care for usability
<libv>
slapin_: imho, that is broken
<libv>
slapin_: change your boot.scr and your data goes pop
<slapin_>
as soon as you boot, the partition table is unchangable without rebooting (but you can change the variable using fw_setenv, for example).
<slapin_>
libv: is is not as long as you provide wrong partition information
<slapin_>
libv: you're on UNIX-like, you can break your neck in a lot of amusing ways!
<libv>
slapin_: _as_ _long_ _as_
<libv>
slapin_: it's storage, it can spare a few sectors for a partitioning table
<slapin_>
libv: and there is nobody for you to ask 'are you sure?' here.
pwhalen has quit [Ping timeout: 260 seconds]
<slapin_>
libv: your u-boot environment is as good as your partition on storage
<libv>
it probably made sense when only a few mb nand flashes were around
<oliv3r>
libv: in the case of ubi/ubifs, ubi doe sthe FTL work; ubifs the rest, jffs does both, ftl + fs tasks; but ext4 does no wearlvling, hence why they say 'don't ever do it fool'
HdkR has joined #linux-sunxi
<libv>
oliv3r: now if you move wear levelling one level down from the fs...
<oliv3r>
libv: then you have a flash controller; and that's exactly what we have :p
<oliv3r>
libv: a uSD card, is basically, our flash controller + nand
<libv>
oliv3r: badly, in our case
<libv>
with libnand
<libv>
oliv3r: or are you talking about the nfc
<oliv3r>
yeah
<oliv3r>
i learned all this last week :p
<libv>
yeah, what? :p
<oliv3r>
bunnie from ccc did a talk about REing uSD cards
<libv>
libnand or nfc?
<oliv3r>
how tehre's actual firmware there (that you can replace etc etc)
<oliv3r>
so i was looking at our own stuff, we have the NFC, we have nand and we have a crappy 'firmware' (libnand)
<libv>
does our nfc do the wearlevelling, or do we need software to do that for us?
<oliv3r>
'freedom' wise, nfc + nand is superior (if we get it to work)
<oliv3r>
no hidden firmware (eMMC, has the firmware hidden too)
<oliv3r>
our nfc does not know about wearlvling
lioka has quit [Changing host]
lioka has joined #linux-sunxi
<libv>
as i expected
<oliv3r>
hence, why you want to use ubifs or jfffs ontop of the final nand thing
<libv>
so there are reason why the wearlevelling is built into the fs?
<oliv3r>
what libnand does, is wearlvling and expose it as a block device so you can put ext ontop
<libv>
so is there, even
<oliv3r>
yes, if you really are cfurious, read the linux-mtd.infradead.org stuff, mostly the ubi ubifs and mtd faqs
<oliv3r>
i doubt there's (m)any NFC controllers that do wearlvling, it's nearly always handled by firmware (uSD, eMMC etc) or software (libnand)
<oliv3r>
so 'easy' is using eMMC, but you have closed blob
<oliv3r>
albeit it maybe insignificant, who doesn't trust mmc
<libv>
oliv3r: i think everyone just thought that wear levelling built straight into the fs is the best option
<libv>
and perhaps it is the cleanest and quickest solution
FreezingCold has joined #linux-sunxi
<oliv3r>
well ubi/ubifs does it in a modular layering, like lvm
<libv>
but the flexible option is to build it into the device driver as common infrastructure
<libv>
u-boot doesn't need to know about the wear levelling, it just needs to know about how to access the mapping tables
<libv>
so it can read things
<libv>
and then you can have any fs you like
<libv>
that's one thing
<oliv3r>
yeah
<libv>
the fact that mtd, per default, stores no partitioning information is bogus.
<buZz>
oliv3r: bunnie is not a member of ccc
<oliv3r>
buZz: he did a talk at the ccc :p
<buZz>
hehe yeah
<buZz>
i've seen it, awesome stuff
<oliv3r>
libv: there is no wearlevling below mtd though; so you'd have to have a kernel framework that does the wearlvling
<libv>
partitioning info doesn't need to get rewritten much
<oliv3r>
libv: so if you want to store partition tables on mtd; you'd have to add an intermediate layer; which doesn't exist yet ;)
<libv>
and any mtd driver could just keep a handful of sectors in reserve for when a block does wear out
<libv>
lose 16 sectors, which only show as sector 0, and let the fs-es do their work from there
<libv>
heck, you could even just have a special tool for this
pwhalen has joined #linux-sunxi
pwhalen has quit [Changing host]
pwhalen has joined #linux-sunxi
<oliv3r>
libv: well any improvement is welcome :p patches welcome :p
<libv>
having to provide this as kernel/u-boot config is broken
<oliv3r>
i jest i jest
<libv>
it is tied 1-1 to the storage
<oliv3r>
well as i said, 'back in the day' from where mtd stems, you had 2mb flash
<libv>
time for a rethink
<oliv3r>
i would agree
<oliv3r>
well that's what UBI is tryig to solve i think
<libv>
oliv3r: it makes sense when flash is measured in kB, no longer when it is measured in MB
<oliv3r>
gb!
<oliv3r>
it didn't evolve with it i guess
<libv>
even MB
<oliv3r>
btw, flash tends to break a lot and often
<libv>
you can spare a few kB for a partitioning table and some backups
<oliv3r>
it could be one of the reasons; exposing the pure and raw flash via mtd because of that? recovery purpouses etc?
<libv>
history.
<oliv3r>
but one of the problems is, if you write sector 1 for example, and have a problem
<oliv3r>
sector 0 CAN get corrupt
<oliv3r>
so it's not a direct 'write once never worry' thing
<libv>
oliv3r: how do you know it is corrupt, today?
<oliv3r>
the above layers
<libv>
oliv3r: how do they know?
<oliv3r>
erm, I haven't studied the matter in depth :p
<oliv3r>
but the mtd site explains it :)
<oliv3r>
or tries to
<oliv3r>
and for ubifs, it's not even done yet :p
<oliv3r>
still wip
<libv>
if they have a scheme for finding out whether a sector is broken, then surely it can be used to manage 16 blocks as well
<oliv3r>
like yanking the power while flash is being written, it doesn't know about all possible errors
by_Fel has joined #linux-sunxi
<slapin_>
libv: I'd recommend you a basic reading on what really is flash memory, what is NAND flash, and what is MLC NAND flash. You will wonder how this even works. Then you'd probably think that current kernel approach is ok...
rose28357 has joined #linux-sunxi
<libv>
slapin_: i think i understand enough
<oliv3r>
mlc, slc, nor; they all behave differently, our mlc nand is one of the worst
<oliv3r>
lots of 'bit rot'
<oliv3r>
and you are not fully protected yet
<oliv3r>
i think most recommended way (like openwrt does it) is to have flash, that you write once, and then a ramfs overlayed on it
<libv>
slapin_: i am just questioning the fact why noone has used a standard (linux mtd) scheme for storing partitioning information on it
<oliv3r>
because the flash is so damn unreliable
<libv>
slapin_: and why this has to be untied from the actual storage
<mripard>
oliv3r: even reads can trigger bitflips to neighbour pages
<oliv3r>
mripard: there you go!
<oliv3r>
you basically have to assume flash is always corrupt :p
<slapin_>
mripard: bitflips problem is yet another thing which plagues flash interfaces (and ubifs for that matter)
<slapin_>
especially MLC one
<oliv3r>
yeah i think bitflips is one of the thigns ubifs is 'WIP'
<oliv3r>
get 3 flash chips and raid them!
<libv>
when i read that, then i know that solving wearlevelling on the fs level is wrong
<slapin_>
oliv3r: abd get 3 different problems in the same data block...
<slapin_>
s/abd/and
<libv>
but then, there is ecc
<oliv3r>
slapin_: raid6
<libv>
a whole block does not go broken
<libv>
bits break
<oliv3r>
slapin_: raid7!
<slapin_>
libv: random bit errors
<slapin_>
libv: when read random bits wrong is not error
<libv>
slapin_: again, those problems have been solved
<libv>
slapin_: otherwise we wouldn't be able to use any flash based storage
<libv>
there are means for telling whether blocks have broken
pacopad_ has joined #linux-sunxi
<slapin_>
libv: you use ECC algorithms to correct the bit errors
sgo11 has joined #linux-sunxi
<libv>
and if one of the first 16 blocks has bit errors, look for the partitioning table in the next
<oliv3r>
i think the hardware ECC controller figures out if a block is broken or not?
<oliv3r>
(or in bbrezillon's case, the software ecc controller)
pacopad has quit [Ping timeout: 252 seconds]
<libv>
8kB can be easily spared.
pacopad_ is now known as pacopad
<slapin_>
libv: but for cheap large MLC nand flashes, you see LARGE data chunks having bit errors. You seee 8K pages, which, unlike 2K pages, require larger ECC blocks and faster ECC processing
<libv>
and if your mtd really is minute, jsut don't use it
<libv>
slapin_: randomization
<libv>
slapin_: we have that built into our nfc
<libv>
slapin_: and we have the pattern programmed in our driver
<slapin_>
libv: randomization itself doesn't solve the problem, really
<libv>
and in u-boot and in brom
<oliv3r>
we do, but not all flash controlelrs have that :)
<oliv3r>
what about those chips that simply hook up gpio's and bitbang the whole damn thing!
<sgo11>
oliv3r, you are still here. I am trying to mount the nand.img, but all attempts failed. how to mount that properly? I tried fdisk -l nand.img, it returns "....Disk lubuntu-desktop-nand.img doesn't contain a valid partition table".
<libv>
slapin_: yes it does, otherwise we wouldn't have anything working today
penghb has joined #linux-sunxi
<libv>
slapin_: 16 sectors, semi-randomly over the whole storage...
<oliv3r>
sgo11: i'm pretty sure, there's several partitions and more in that single image
<libv>
with ecc, and multiple bit error checking in place
<slapin_>
libv: randomizations solves different problem and is required only on MLC nand due to its lack of cells and different approaches to data retention.
<oliv3r>
sgo11: if it's a livesuit image, check our wiki about awutils i think it's called to unpack it
<libv>
that's as reliable as anything else is
<libv>
and that's exactly how anything else probably works
<nikrou>
I install fedora on my uSD card and boot on it
<libv>
these things are solved
<sgo11>
oliv3r, thanks. let me check.
<nikrou>
But ...
<libv>
otherwise we wouldn't be using this hw as storage
<nikrou>
How to access it ?
<oliv3r>
nikrou: you did read the README right?
<oliv3r>
nikrou: running setup etc
<libv>
now why can 16 sectors not be used to store a bit of partitioning information?
<nikrou>
I should have missed someting ?
<libv>
it's not as if everyone, now, has to be forced to use this
<slapin_>
libv: that depends on your task, really. I still don't see much use of MLC nand flashes in industrial stuff where there is a lot of writes of data
<libv>
but why is the option to use an on flash partitioning table not available today?
<libv>
partitioning tables are written _very_ rarely
<libv>
all it needs is reader/writers to just verify the first few sectors for a) validity b) a signature
<slapin_>
libv: I have 3 chinise routers, which use flash data written on them as partition table, they have partition markers and build the table at runtime, so I think you can do this for your particular device, nobody will stop you.
jemk has joined #linux-sunxi
<oliv3r>
nikrou: you xzcat image.img.xz > /dev/mmcsdwhatever; eject, plugin; mount, run setup? it's all in the README :)
<slapin_>
libv: all mechanics needed is already here.
<libv>
slapin_: but it is not solved at the mtd driver level apparently
<libv>
slapin_: yet everyone believes mtd is the solution for all flash from 1kB all the way up to many GB
<oliv3r>
if you have /dev/mtd, without passing partitioning information, you probably can run fdisk /dev/mtd :)
<slapin_>
libv: it is part of flashmap code, so, technically saying, everything is here, just write proper partition map code
<nikrou>
i burned the image, select the board and boot on it
<libv>
zoobab: WTF
<slapin_>
libv: it is, it is the solution, if you don't like it, change it
<nikrou>
Now my tablet shows a "welcome fedora" with a mouse pointer
<libv>
zoobab: so you are benjamin henrion
<libv>
zoobab: why are you trying to create an event parallel to fosdem now?
<oliv3r>
nikrou: so everything is great; plugin a keyboard/mouse/hub and 'use' it?
<nikrou>
that's the problem
<oliv3r>
nikrou: you should have received a mini/micro USB -> USB adapter with your tablet; check the box
<oliv3r>
all cheap chinese tablets i've got had a cable
<oliv3r>
usb-otg cable
<oliv3r>
i can only use a keyboard or a mouse, never together on one tablet, so i have to plug a lot to type/mouse, but it's workable enough
Gerwin_J has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 246 seconds]
<libv>
zoobab: go to fosdem like normal people
<nikrou>
I've got the cable
<libv>
zoobab: or start organzing something months beforehand
<nikrou>
But the usb port is mini for the tablet
<libv>
zoobab: do not have a brainfart one morning a few weeks beforehand and expect people to buy into it
<nikrou>
I don't have a female adaptator
<oliv3r>
nikrou: the cable i got with my tablet, plugs into the tablet on one end, and fits a mouse on the other end
<oliv3r>
nikrou: anyway, if you can't input anything, your kinda screwed :p since you can't ssh in either
<oliv3r>
as you can't enter your wifi password :p
<oliv3r>
hometime
<nikrou>
ok thanks anyway Oliv
<nikrou>
I progress
FreezingCold has joined #linux-sunxi
pacopad has quit [Read error: Operation timed out]
pacopad has joined #linux-sunxi
npcomp has quit [Ping timeout: 252 seconds]
npcomp has joined #linux-sunxi
pacopad_ has joined #linux-sunxi
geekything has joined #linux-sunxi
<geekything>
howdy....does anyone have any clues on how to interface a parallel 8080 TFT LCD with the A10? I'm stuck on the control signals (CS, WR, RD, CMD)....it looks like PIOs can be possibly setup for this?
<geekything>
thanks, foubarre....interfacing is not so much the challenge as to whether or not the A10 can supply the 8080 control lines via PIO and how to enable/map that. I've looked through the FEX configs and the A10 data sheet and they do allude to 8080 parallel TFTs being supported :-/
<geekything>
I could use TFTFB to bit bang GPIO, but I'd rather use the GPU if possible :)
HdkR has quit [Ping timeout: 265 seconds]
pacopad_ has joined #linux-sunxi
<foubarre>
geekything: true.. true.
<juanfont>
i've repartitioned my NAND, and i'm getting "PHY_PageRead : too much ecc err,bank 0 block" when formating or mounting the nandb partition. is my nand screwed?
pacopad has quit [Ping timeout: 272 seconds]
pacopad has joined #linux-sunxi
pacopad__ has joined #linux-sunxi
pacopad_ has quit [Ping timeout: 245 seconds]
sgo11 has quit [Quit: Leaving]
pacopad has quit [Ping timeout: 264 seconds]
pacopad_ has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
pacopad__ has quit [Ping timeout: 272 seconds]
HdkR has joined #linux-sunxi
nikrou has quit [Ping timeout: 272 seconds]
geekything has quit [Quit: geekything]
jemk has quit [Ping timeout: 265 seconds]
t3st3r has quit [Ping timeout: 240 seconds]
t3st3r has joined #linux-sunxi
pacopad has joined #linux-sunxi
Turl has joined #linux-sunxi
Turl has joined #linux-sunxi
Turl has quit [Changing host]
foubarre has quit []
pacopad_ has quit [Ping timeout: 272 seconds]
jinzo has quit [Ping timeout: 272 seconds]
pacopad_ has joined #linux-sunxi
pacopad has quit [Ping timeout: 245 seconds]
pacopad_ is now known as pacopad
jemk has joined #linux-sunxi
pacopad_ has joined #linux-sunxi
pacopad has quit [Ping timeout: 264 seconds]
pacopad_ is now known as pacopad
by_Fel has left #linux-sunxi [#linux-sunxi]
pacopad_ has joined #linux-sunxi
FR^2 has quit [Quit: Connection reset by peer]
pacopad has quit [Ping timeout: 265 seconds]
pacopad_ has quit [Ping timeout: 246 seconds]
sgo11 has joined #linux-sunxi
pacopad has joined #linux-sunxi
pacopad_ has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
pacopad has quit [Ping timeout: 272 seconds]
pacopad has joined #linux-sunxi
ijc has joined #linux-sunxi
pacopad_ has quit [Ping timeout: 272 seconds]
matt_ has joined #linux-sunxi
matt_ is now known as Guest55381
<Guest55381>
Hi, have just upgraded the kernel on my Olimex A20 and it seems to have broken the audio capture... specifically the line-in audio capture is now overloading and clipping badly even at 0 capture volume, whereas previous kernel sounded ok at 100 capture volume
Guest55381 is now known as Mattcamp
sgo11 has quit [Quit: Leaving]
Fusing has joined #linux-sunxi
<buZz>
doesnt sound like a upgrade to me :)
<buZz>
better go back
<Mattcamp>
I have... but I'm also getting some weird alsa buffer overrun errors that I was hoping to fix by upgrading to a newer kernel
<Mattcamp>
every 46 minutes alsa overruns when capturing from line-in :(
paulk-collins has joined #linux-sunxi
pacopad has quit [Ping timeout: 245 seconds]
pacopad has joined #linux-sunxi
Mattcamp has quit [Ping timeout: 246 seconds]
t3st3r has quit [Remote host closed the connection]
pacopad_ has joined #linux-sunxi
t3st3r has joined #linux-sunxi
pacopad has quit [Ping timeout: 248 seconds]
<Turl>
howdy
pacopad has joined #linux-sunxi
pacopad_ has quit [Ping timeout: 260 seconds]
panda84kde has quit [Quit: Konversation terminated!]
bbrezillon has quit [Quit: Ex-Chat]
Mattcamp has joined #linux-sunxi
pacopad has quit [Ping timeout: 246 seconds]
pacopad has joined #linux-sunxi
pacopad has quit [Ping timeout: 252 seconds]
bsdfox has quit [Ping timeout: 246 seconds]
FreezingCold has quit [Ping timeout: 272 seconds]
pacopad has joined #linux-sunxi
bsdfox has joined #linux-sunxi
popolon has quit [Quit: Quitte]
<rm>
This is the driver for the Security System included in Allwinner SoC A20.
TomiK has joined #linux-sunxi
<rm>
Security System (SS for short) is a hardware cryptographic accelerator that support AES/MD5/SHA1/DES/3DES/PRNG algorithms.
<rm>
zomg
pacopad_ has joined #linux-sunxi
TomiK has quit [Client Quit]
Gerwin_J has joined #linux-sunxi
<buZz>
what
<buZz>
no scrypt? tsss
<buZz>
:P
<rm>
yeah and no sha256 either
<buZz>
:)
pacopad has quit [Ping timeout: 246 seconds]
pacopad_ is now known as pacopad
Quarx has quit [Read error: Connection reset by peer]
pacopad_ has joined #linux-sunxi
pacopad has quit [Ping timeout: 272 seconds]
_massi_ has quit [Remote host closed the connection]
pacopad_ has quit [Ping timeout: 252 seconds]
kriegero1 has quit [Quit: leaving]
kriegerod has joined #linux-sunxi
deasy has quit [Read error: Connection reset by peer]
pacopad has joined #linux-sunxi
earny has quit [Remote host closed the connection]
deasy has joined #linux-sunxi
earny has joined #linux-sunxi
notmart has joined #linux-sunxi
Fusing has quit [Ping timeout: 260 seconds]
<jelly-home>
sha1 is good enough for hash, and aes for block en/decryption
<jelly-home>
buZz ought to know better than to ask for scrypt consider the abysmal bandwidth to and from RAM
ZetaNeta has quit [Ping timeout: 264 seconds]
<jelly-home>
sorry, not useful for ltc
<buZz>
jelly-home: duh :P
jemk has quit [Ping timeout: 252 seconds]
<oliv3r>
mrnuke: i got my coreboot PCB's :)
<mrnuke>
oliv3r: the SPI switchwer? Pics or it didn't happen
<oliv3r>
you can see reasonable detail in the downloaded pic
<oliv3r>
though the green on green was probably not the bestest idea
<Mattcamp>
Hi oliv3r, not sure if you saw my earlier comment... you did a patch for me back in october to fix some of the sunxi-codec controls in alsamixer, however having just built a new kernel from a fresh git clone this seems to have been broken again
<Mattcamp>
although now it seems like the input gain levels are all messed up somehow... copying the older sunxi-codec.c file back over fixes the problem, but I can't figure out what has caused it
<Mattcamp>
(this is on an Olimex A20 board)
<oliv3r>
if copying helps; can do you a diff (or git diff)?
<Mattcamp>
I can, although the file I was using was the one where I manually inserted the changes you suggested, rather than your commited git fix.
<oliv3r>
shouldn't be a huge diff; as long as you get 'a' diff
<oliv3r>
so we can see what could have potentially changed
<oliv3r>
there's 2 patches after mine
<oliv3r>
so the great challange for you to:
<oliv3r>
backup the C file that works, put it somewhere safe :p
<oliv3r>
checkout the version from git that id id 2 patches ago
<oliv3r>
if that works; checkout 1 version later; if that works, check out the last version
<oliv3r>
mattcamp: i wish i could help you more then that, and i Know it puts some work and the burden on you; but my olimexino a20 is broken atm
<oliv3r>
hramrach: well appearantly mrnuke doesn't think it's worthy
<Mattcamp>
oliv3r: On my version I get good quality audio with the 'Capture Volume' control in alsamixer set at 100. On your version I have to set it to 0 to get ANY audio, and even then it sounds as if it's clipping badly
<Mattcamp>
seems almost like some input gain has been enabled somewhere
<hramrach>
it always depends on the person evaluating the board and on the use cases considered
<oliv3r>
mrnuke: also, HUGE
<mrnuke>
oliv3r: Not to be the cockblocker here, but such PCBs have been done and redone, and proved only marginally useful
<oliv3r>
mrnuke: for SPI, you only swap the chip select pins anyway
<oliv3r>
mrnuke: in theory, you can even connect a gpio to switch :p
<hramrach>
PCBs have been done and redone and non fits my use cases soo
<oliv3r>
hramrach: what is your usecase?
<oliv3r>
mattcamp: ah yes, input is to loud
<Mattcamp>
input is line-level
<oliv3r>
mattcamp: we probably have to disable one by default
<hramrach>
enclosing an arm board inside a leftover case
<oliv3r>
mattcamp: have you tried playing with some of the switches in alsamixer?
<hramrach>
so I need that the on/off switches, leds, etc have pins with which I can duplicate them elsewhere
<oliv3r>
hramrach: gepetto is for you then! someone linked it last night
<Mattcamp>
yeah, doesn't seem to make any difference unless i toggle the Left/Right Capture Mute ones
tgaz has joined #linux-sunxi
<oliv3r>
mattcamp: well mute is quite obvious there :)
<oliv3r>
so it's purely about capture right
<Mattcamp>
yeah
<oliv3r>
mattcamp: it's not the mic boost or mic volume? (shouldn't affect it)
<Mattcamp>
in the capture page in alsamixer I have every single control at 0
<oliv3r>
well toggle em all one by one :p
<Mattcamp>
and the audio is normal volume but clipping
<oliv3r>
also try playback switches :p
<Mattcamp>
tried that, no change at all
<oliv3r>
that's odd
<hramrach>
oliv3r: the gunmstix thing?
<hramrach>
sounds fun but last time I seen it it had really poor selection of SoCs to put there
<oliv3r>
hramrach: yeah
<oliv3r>
hramrach: it does
<mrnuke>
oliv3r: when you're flashing and reflashing, having mech switches to change gets in the way
<mrnuke>
that's why we prefer something electronic. Controllable from the keyboard
<hramrach>
so long as the switch is easy to toggle ..
<mrnuke>
if I have to take my hands off the keybord, that's wasted time :(
<hramrach>
eg. if you have a jumper there you can connect a wire with *any* switch you like instead
<oliv3r>
mrnuke: for that to work though; you need either an available GPIO, or control it via i2c i guess or some bus that's available; and on the motherboard that doesn't happen often
<oliv3r>
mrnuke: hardcore coreboot devs have dual-bios motherboards anyway :p
<oliv3r>
mrnuke: see, there's a lot of users, that wanna try coreboot, flash it in, maybe even compile a few minor changes, but easily switch back to something working
<oliv3r>
this is perfect for us :)
<mrnuke>
dual-bios is a PITA, not a helpful thing
<oliv3r>
as for the switch, glue the damn switch to your keyboard!
<oliv3r>
make it one of those on/off switches that eject in/out, done
<oliv3r>
with the FET, you should be able to drive it from a few meters away easy
<mrnuke>
oliv3r: come on maan, _YOU_ _CAN_ do better than a mech switch :)
<oliv3r>
mrnuke: i can't :( not in the required size i had set for myself
<oliv3r>
i wanted to make the PCB half the ssize
<oliv3r>
but i just didn't have the room for components, so i bucked in and doubled the size
<mrnuke>
you know they make FETs in SOT523, right?
<hramrach>
also $2k setup fee @ gepeto is not fun
<Mattcamp>
oliv3r: Solved! You need to add CODEC_SINGLE("Linein Pre-AMP", SUNXI_ADC_ACTL, 13, 7, 0), to static const struct snd_kcontrol_new sun7i_adc_ctls[] = {
<Mattcamp>
there is indeed a line-in pre-amp control
<Mattcamp>
which by some fluke I had added
<hramrach>
when you could achieve the same with a board that produces in volume with connectors to wire your LEDs and switches to fit almost any case
bsdfox has quit [Ping timeout: 246 seconds]
<oliv3r>
mattcamp: this is about half the size of sot523 it looks; and dual fet :p
<hramrach>
I mean it need not fit *exactly*. just have most connectors on one side and wirable switches and leds
<oliv3r>
mattcamp: then i forgot it last time; will ad it now
notmart has quit [Read error: Operation timed out]
<hramrach>
oliv3r: I am using this deceased LaCie drive case as paperweight but it would be really nice home for a small board and maybe a disk but there are no boards that would allow for wiring into a preexisting case
bsdfox has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
<hramrach>
well, I have a soldering iron but I would like to avoid that. I want reliable and reproducible results :p
<oliv3r>
hramrach: yeah that's a pretty specific usecase :)
ssvb has joined #linux-sunxi
<oliv3r>
mrnuke: well thanks for making me feel bad about having wasted my time and money on this then! :(
<oliv3r>
mattcamp: its on its way to the ML
<buZz>
oliv3r: what is this board?
<mrnuke>
sorry for being honest :(
<hramrach>
oliv3r: I don't think that having old cases is *that* specific. The problem is always the same. You have the case with jumperwires and no place to connect them on the board :/
<buZz>
ah. SPI switcher thingy
<oliv3r>
buZz: a board that lets you quickly and easily switch between 2 SPI flash chips on a board without having to reseat them
<buZz>
cool, so the board has 2 SPI fchipcs?
<oliv3r>
but mrrnuke is dissapointed it's not controlled via bluetooth on his iphone!
<buZz>
wtf @ typing
<oliv3r>
buZz: the idea is, you remove the spi chip from your motherboard from its dip-8 socket, and place it in the socket on this board
<buZz>
ah right
<oliv3r>
and you have a pre-solderd (not by me lol) smd flash chip on there
<hramrach>
then enjoy the board and let him make a BT controlled one for himself :p
<buZz>
cool :)
<buZz>
guess its not linux-sunxi related
<oliv3r>
you then just use a jumper, or a simple switch to switch between original, and the 'alternative'
<oliv3r>
so basically, dual bios
<buZz>
cause i read about coreboot getting cubieboard support?
<buZz>
assumed it had to do with that
<hramrach>
unfortunately, recent stuff is not socketed
<hramrach>
but if your mainboard still is good for you
<oliv3r>
buZz: one of the reasons also, i made this board, finding BIG 8 pin dip chips is hard/expensive, smd parts, any size, is easy
<oliv3r>
so i could buy some converter boards + mem, or just make my own converter board with a little extra
Fusing has joined #linux-sunxi
<hramrach>
indeed, my not completely obsolete AMD board has that 8pin thingy
<hramrach>
but AMD has nothing to compete with the likes of i3 4010U, does it?
<hramrach>
anyway, AMD does not make own boards so if you want a board with usable BIOS you need Intel/Dell/HP/Lenovo or something like that
<hramrach>
I mean desktop board
<hramrach>
sure the situation is different with server boards but for desktops those Taiwainese manufacturers fail at making the bios even remotely usable
<hramrach>
it's cool you can take it out but since there is nothing to replace it with it's not that helpful
<oliv3r>
hramrach: i care more about freedom that raw performance
<buZz>
oliv3r: you could put the smd footprint on the boards ;)
<oliv3r>
because be honest, what is the difference between a 150 E intel or 150 E AMD cpu
<oliv3r>
3 second compile time?
<hramrach>
oliv3r: I somewhat care about the amount of electricity required to power my PCs
<oliv3r>
buZz: that's what i did :) smd on the board, dip on the board + jumper; and then pins at the bottom to plug in the original hole
<buZz>
awesome :)
<oliv3r>
as do I, greatly
<oliv3r>
well i have an old phenom 6x II which was quite power efficient at the time
<hramrach>
well, at the time
<hramrach>
today Intel has the upper hand in power efficiency, and it delivers usable systems
<hramrach>
more than you can say about AMD
<hramrach>
my AMD board is underpowered *and* unusable due to fucked up bios
<hramrach>
so another paperweight
<buZz>
i dumpsterdived a first gen amd64 board some time ago
<buZz>
its in use for a mining rig with ati videocards
<hramrach>
that's cool. Still I want a desktop, not a mining rig
<hramrach>
so something that does double as heating and does not make you deaf just from sitting near it for an hour
<hramrach>
*not
bsdfox has quit [Ping timeout: 260 seconds]
<hramrach>
anyway, you get the idea
<oliv3r>
hramrach: don't paperweight it, coreboot it
<oliv3r>
hramrach: my bios is horrible; boots badly when USB is connected, boots really slow (when usb is connected mostly) and is just slow
<oliv3r>
but hey, its 'UEFI'
<oliv3r>
hramrach: i was searching and being all cool with a 'look' but a cool FX proc isn't avilable (FX-8300), it was a 95W part; now if you are referring to the FX-9590 holy shit yeah, 220 Watts, who will buy that crapshoot
<oliv3r>
hramrach: in my servers i have 1 that'sa neo thing, 15 watts or so; my other i got a phenom II 'E' series
<oliv3r>
the 8300 would have been MSRP 150 USD
<oliv3r>
but i'm looking at cpu's without integrated graphics
earny has quit [Remote host closed the connection]
earny has joined #linux-sunxi
<hramrach>
oliv3r: even if I coreboot it it's not gonna work
Gerwin_J has joined #linux-sunxi
<hramrach>
AMD is the company that advocates using their buggy bios blob for bringing up their graphics cards and effectively killed the effort to liberate their graphics cards
<hramrach>
so if you care about opensource and have the choice between Intel and AMD go Intel any day :P
<oliv3r>
hramrach: you mean intel which needs blobs to bring up their RAM controller?
<oliv3r>
and if you get CPU without onboard graphics, you don't need to worry about the grahpics bit
<oliv3r>
i'd have to strongly think about getting an APU to be honest
<hramrach>
I am not interested in a minig rig ffs
<hramrach>
and the AMD memry controller is that nicely documented or did just somebody happen to RE it?
<hramrach>
with either Intel or AMD you get a BIOS blob which sets up the chipset and load your OS. On Intel you can then use the chipset and the gprahics driver can even reset your gpu without a blob
<oliv3r>
hramrach: documented afaik
<oliv3r>
hramrach: better yet; amd 'said' they officially support coreboot (since 2013?) with code, docs etc
<oliv3r>
mrnuke: ^^^ :p
<hramrach>
well, they did really crap thing with their graphics support
<oliv3r>
'atom-bios' :)
<hramrach>
yes
<oliv3r>
yeah if it where up to some people here; we would have never seen that
<oliv3r>
but i'll take a graphics blob over a ram init blob any day of the week
<oliv3r>
and you know intel boards have shit like IME and stuff
<hramrach>
ok, so in the end it's all the same so just pick whatever has the best performance/power/$ atm
<hramrach>
accidentally the 4010U did not leave enough space to fit in an IME
<hramrach>
it has decent performance and IOMMU, after all
<oliv3r>
no, if you don't need graphics, you can boot amd without any blobs at all
<hramrach>
at least that's what the specs/reviews say
<hramrach>
well, I do need gprahics for desktop
<oliv3r>
i thought the IME is in the bios
<oliv3r>
you can do discrete graphics
<oliv3r>
where the blob resides in silicon on the card
<hramrach>
IME needs some sillicone in hardware
<oliv3r>
afaik not in the cpu though
bsdfox has joined #linux-sunxi
<oliv3r>
north/south bridge prob
<hramrach>
discrete graphics is getting obsolete
<oliv3r>
in maybe 20 years :p
<oliv3r>
but all the powerfull stuff, will be descrete for a while
<oliv3r>
for 'joe user' apu's are fine
<oliv3r>
(performance wise)
<oliv3r>
blob wise, obviously not
<hramrach>
when you are not getting a mining or gaming rig discrete graphics is already obsolete
<hramrach>
ok, there are a few applications that can use compute but very few
<oliv3r>
hramrach: yeah i had an androidized ht leo (originally win 6.5 phone)
<oliv3r>
kept having to do that
<oliv3r>
now i have a htc desire, with android (evervolv i think; it's like CM but lighter) and it works blissfully, no reboots or nothing
<oliv3r>
my other htc hero, also with cm gingerbread; runs perfectly fine for weeks! if not longer now
<oliv3r>
(i use it as an G sensor alarm clock)
Mattcamp has left #linux-sunxi [#linux-sunxi]
<oliv3r>
but we see all this perfectly happening in sunxi
<oliv3r>
many horribly crappy drivers
<oliv3r>
make things go shit
<ccaione>
mripard: do you thing is it worthy to adapt the irqchip driver also for A31?
<oliv3r>
ccaione: have you read the axp152, 806 and 809 specs?
<oliv3r>
ccaione: hopefully your able to do a nicely unified driver ;)
<ccaione>
oliv3r: not yet :) it is a complex beast
netlynx has quit [Quit: Leaving]
<ccaione>
it's like 30 drivers in 1
<oliv3r>
yeah
<oliv3r>
well basically, it's a MCU
bsdfox has joined #linux-sunxi
<ccaione>
yep, it's wip, but I'll post the skeleton for MFD as soon it is ready so everyone can join the development of subsystems
FDCX_ has joined #linux-sunxi
ssvb has quit [Ping timeout: 252 seconds]
notmart has joined #linux-sunxi
notmart has quit [Remote host closed the connection]
<deasy>
arokux back and no one alarm me ! :p
<deasy>
alert*
ssvb has joined #linux-sunxi
notmart has joined #linux-sunxi
jemk has quit [Remote host closed the connection]
chil has joined #linux-sunxi
<chil>
Hi, I'm having trouble trying to set a 1920x1200 resolution in a olinuxino a20 board. Anyone can help me?
<libv>
chil: sure, let us all just get out our crystal balls.
<chil>
:P
<libv>
chil: don't ask for help, state your problem, to the full, and explain where you are stuck
<chil>
I'll tried to set disp.screen0_output_mode=EDID:1920x1200p59 in kernel arguments
<chil>
and setup xorg with the modelines of the monitor connected via HDMI
<chil>
but monitor got no signal
<chil>
tried with 1080p and worked. But no luck with 1920x1200
* libv
points his editor at disp
<libv>
chil: first off, i was about to trash you for not having mentioned any script.bin changes
<libv>
chil: but since hd works on hdmi, you are off the hook there
* ojn
is trying to follow the arguments oliv3r is making above and is getting a headache.
<libv>
chil: xorg.conf shouldn't need any alterations
<libv>
chil: it talks to fbdev, fbdev tells xorg what resolution it is at, and that's pretty much it
<ojn>
there's definitely no need for vbios on intel platforms from a linux point of view. you do, obviously, need to initialize video in firmware if you need firmware to draw on the screen.
<ojn>
s/intel platforms/intel graphics/
<libv>
oh, i missed that
<chil>
libv and it has nothing to do with 1920x1200 not being defined in disp_clk.c kernel file? (it can use the EDID directly?)
<libv>
display support in bioses
<libv>
chil: just a sec.
<chil>
:)
<libv>
i believe i have a slight bit of experience in the display & bioses area, now they talked about it behind my back and missed my chance to be a whiny old fart again :(
<libv>
i could've had three big whines today...
<libv>
chil: stick a dmesg in pastebin.com please
<libv>
chil: it'll probably be useless, but maybe it isn't
<libv>
ssvb: it is actually the standard value for pll7, which tends to be the clock for all things display
<libv>
why they chose to also prefer it for the actual pixel clock is beyond me
<libv>
as all engines are affected and you might get wildly varying performance out of them due to change of resolution
<Nyuutwo>
as far as I understood sources disp uses pll 1,2 for clocking and fallback to pll7
<libv>
Nyuutwo: no, 3 and 7
<libv>
Nyuutwo: or video0 and video1
<libv>
same name for the same things
<chil>
I'm using a debian prebuild image from olimex with kernel Linux A20 3.4.67+
<libv>
chil: that shouldn't matter either
<chil>
ok :p
<libv>
chil: as there were little to no changes to disp code recently
<chil>
and with mali drivers? I tried sunxi-mali and fbturbo
<libv>
chil: does not matter for display stuff
<libv>
chil: either you have a working framebuffer, or you don't
<Nyuutwo>
oh, i forgot: don't asume everything is logical
<chil>
well, i've no clue whats happening
<libv>
chil: for the time being, pick another resolution, somewhere after fosdem i should have kms for sunxi-3.4 out, and that one is very easily debuggable
<chil>
:/
<libv>
i would expect this to be some issue with the pll setting, i do not know how reliable this code is when it comes to using pll-video0
<libv>
i have only used that pll in new code so far
<ssvb>
is the ppl setting code still using bizarre non-atomic multipliers configuration via bitfields?
<ssvb>
*pll
<libv>
ssvb: in disp?
<libv>
ssvb: or in kms?
<ssvb>
iirc in the sunxi pll clock related code
<ssvb>
let me check it again
<libv>
then yes
<libv>
i am not going to rewrite the sunxi clock handling myself
<ssvb>
chil might try to debug how exactly the pixel clock is being set for that particular video mode
<libv>
ssvb: i am not sure whether people have tackled that one for upstream
<libv>
chil: edit drivers/video/sunxi/disp/bsp_display.h and put "#define DEBUG 1" on top
<libv>
chil: build and test, and get a run for 1080p and for 1900x1200
<libv>
it should then show pr_debug and a load of extra disp info
<chil>
Ok. I'll read the wiki of how to manually build (not tried yet) and do this changes
<chil>
libv those pr_debug will appear in dmesg?
<libv>
chil: they should
<chil>
ok. btw just tried fbset after booting in 1080p. It just scales?
<ssvb>
chil: your monitor most likely can report the information about the real resolution, refresh rate, etc.
<chil>
yup, after fbset in console monitor reports 1920x1200@54
<chil>
x11 still at 1080p
<chil>
and I got in stdout: disp clks: lcd 148500000 pre_scale 1 hdmi 148500000 pll 297000000 2x 0
<chil>
(i did fbset -xres 1920 -yres 1200)
<libv>
chil: #define DEBUG 1
<libv>
chil: forcing some broken modes is not useful
paulk-collins has quit [Quit: Ex-Chat]
notmart has quit [Ping timeout: 272 seconds]
<oliv3r>
chil if i remember what hansg wrote in his readme, some monitors mess up the hdmi edid autodetect bit, and you should leave off the EDID: bit iirc
<chil>
sorry, i didn't understand that. You mean to not use EDID at all? or just remove the last part after the colon in kernel cmd arg?
<libv>
oliv3r: ssvb put in some patches to no longer reserve memory for mali
<libv>
oliv3r: they are on stage
<libv>
chil: manual build howto on our site
<oliv3r>
this is an old kernel though i suspect, 4.5.67
<oliv3r>
er 3.4.67
<chil>
was following the manual howto (kernel compilation)
<oliv3r>
but i can boot (via SD) from an SSD now; and i must say, it is quite fast
<chil>
but got slow connection and it takes forever to fetch the kernel
<oliv3r>
ah yeah
<oliv3r>
we have a tgz which might save you a few 100 megs
<libv>
chil: there is a flag that you can pass to git to only clone X commits
<libv>
chil: --depth
FDCX_ has joined #linux-sunxi
<oliv3r>
libv: gonna do 2 dev talks this year?
<chil>
ah, you're right. I forgot that
<oliv3r>
they added tons of IoT talks that i'm all missing :(
ssvb has quit [Ping timeout: 272 seconds]
<oliv3r>
oh! connor is having a talk!
<libv>
oliv3r: it'll be a short one
<oliv3r>
it's not scheduled yet is it?
<libv>
it indeed isn't
<libv>
i still need to fix up a few things in penta tonight
<libv>
but imho, with everything set up, i can talk for a few minutes about it, and then tell everyone to either help bugger off or help clean up :)
<oliv3r>
rgr; then i'll keep my schedule open at the end
<libv>
and then we'll have plenty of time to clean up the graphics devroom :)
<libv>
and then it's time for a nice meal at a really nice restaurant
<oliv3r>
on sunday?
<libv>
yes
<oliv3r>
well there's the saturday dinner :)
<libv>
and then after that it's time for the delirium cafe, and then breakfast, then a few h of shuteye, and then the train back, and then a week in bed with fosdem flu :p
ssvb has joined #linux-sunxi
<oliv3r>
hahaha
<oliv3r>
work @ monday :(
<oliv3r>
very early :S
<ssvb>
oliv3r: a few more tweaks are needed before we are done with the memory reservation
<ssvb>
oliv3r: I'll try to get it done when I wake up tomorrow
FDCX_ has quit [Ping timeout: 272 seconds]
<ssvb>
my internet is really broken lately :(
<Turl>
fosdem is feb 1&2 right?
<libv>
Turl: yes
<Turl>
I hope there's livestreams
<libv>
Turl: there are
<libv>
Turl: this year they want to record _everything_
<libv>
which is quite an insane task
<Turl>
:)
<mnemoc>
toilets too?
<Turl>
lol
<ccaione>
nope, only dark corners
<libv>
Turl: a quick scan says 30+ locations
<libv>
simultaneously
<Turl>
I just want to watch the sunxi talk :p
<ccaione>
that will be on BBC
<Turl>
I don't have cable :(
Fusing has quit [Ping timeout: 272 seconds]
<mrnuke>
<hramrach> with either Intel or AMD you get a BIOS blob which sets up the chipset and load your OS. On Intel you can then use the chipset and the gprahics driver can even reset your gpu without a blob
<mrnuke>
huh?
<mrnuke>
the hell you talking about man?
<oliv3r>
ssvb: no worries; i don't think i need mali anyway for what i wanna do
<oliv3r>
Turl: there's a tsvetsan talk; 2 lima talks
<ssvb>
oliv3r: I still think that it is reasonable to maximize the available memory while allowing to use cedar and mali
<oliv3r>
true; but i'll have 2gb of ram :) and 60 gb ssd
<Turl>
oliv3r, s/sunxi/sunxi relsted/
<Turl>
related*
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]