hipboi has quit [Remote host closed the connection]
naobsd has joined #linux-sunxi
gianMOD has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
naobsd has quit [Quit: naobsd]
gianMOD has quit [Ping timeout: 252 seconds]
akaizen has quit [Ping timeout: 244 seconds]
naobsd has joined #linux-sunxi
nemunaire has quit [Ping timeout: 272 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
hipboi has joined #linux-sunxi
nemunaire has joined #linux-sunxi
kaspter has joined #linux-sunxi
gianMOD has joined #linux-sunxi
gianMOD has quit [Ping timeout: 256 seconds]
lucaswang has quit [Ping timeout: 245 seconds]
hipboi has quit [Remote host closed the connection]
hipboi has joined #linux-sunxi
FreezingAlt has quit [Ping timeout: 250 seconds]
gianMOD has joined #linux-sunxi
p1u3sch1 has joined #linux-sunxi
gianMOD has quit [Ping timeout: 246 seconds]
nicksydney has quit [Remote host closed the connection]
p1u3sch1_ has quit [Ping timeout: 250 seconds]
JohnDoe_71Rus has joined #linux-sunxi
konradoo77 has joined #linux-sunxi
gianMOD has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 245 seconds]
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #linux-sunxi
cubeast has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
reinforce has joined #linux-sunxi
bengal has joined #linux-sunxi
alexxy has quit [Ping timeout: 256 seconds]
domidumont has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
akaizen has joined #linux-sunxi
bengal has left #linux-sunxi ["Leaving"]
leviathancn has joined #linux-sunxi
gianMOD has joined #linux-sunxi
marcin__ has quit [Quit: Konversation terminated!]
gianMOD has quit [Ping timeout: 245 seconds]
sehraf has joined #linux-sunxi
Andy-D has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
gianMOD has joined #linux-sunxi
gianMOD has quit [Read error: Connection reset by peer]
gianMOD has joined #linux-sunxi
marcin_ has joined #linux-sunxi
alexxy has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
focus_it has quit [Remote host closed the connection]
_massi has joined #linux-sunxi
leviathancn has quit [Ping timeout: 264 seconds]
premoboss has joined #linux-sunxi
naobsd has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
Net147 has joined #linux-sunxi
<oliv3r>
mripard_: you probably don't remember, but whenever i enable networking on my homenetwork, the stmmac driver panics in the IRQ routine: http://sprunge.us/BhEB i can't reproduce the problem on our office LAN, so i can only test kernels and supply more relevant logs tonight; this on a vanilla rc4.0.0-rc2. The full dmesg is here: http://sprunge.us/BGRd
selfbg has joined #linux-sunxi
<wens>
oliv3r: you should probably post this to netdev
<hno>
Who is nove?
<oliv3r>
hno: manauel braga iirc
<oliv3r>
one of the vdpau cedar guys
<oliv3r>
wens: you reasonably certain it's not a driver issue?
<wens>
oliv3r: we only did the glue layer for stmmac
<oliv3r>
wens: then i will post it to netdev and get some more tests ready
<oliv3r>
wens: also fair enough :)
<wens>
netdev should certainly have more people that are familiar with stmmac core
<oliv3r>
it's something my home-network, as that's the only difference
<oliv3r>
wens: good point
ricardocrudo has joined #linux-sunxi
blsd has quit [Remote host closed the connection]
jinzo has joined #linux-sunxi
domidumont has quit [Read error: Connection reset by peer]
allw has joined #linux-sunxi
allw has quit [Client Quit]
Andy-D has quit [Ping timeout: 264 seconds]
domidumont has joined #linux-sunxi
domidumont has quit [Client Quit]
leviathancn has joined #linux-sunxi
FR^2 has joined #linux-sunxi
blsd has joined #linux-sunxi
popolon has joined #linux-sunxi
hipboi_ has joined #linux-sunxi
hipboi has quit [Ping timeout: 264 seconds]
diego_r has joined #linux-sunxi
<pitillo>
hello, does someone know if sunxi-mali (r3p2-01rel1) and xf86-video-sunxifb (mali-r3p2-support branch) should work with xorg-server 1.17.1 and mesa3d 10.4.6 using kernel 3.4.104 (stage branch)?
<ssvb>
pitillo: sunxi-mali (the proprietary binary driver for mali) and mesa are two different alternatives and can't work together
<ssvb>
yes, you might want to still use mesa for the software rendered glx and desktop opengl implementation, but this is a slippery slope
<pitillo>
then I missunderstood something. I've relinked libs to the newer ones provided by sunxi-mali repo (libEGL.so.1, libGLESv1_CM.so.1 and libGLESv2.so.2)
<ssvb>
and you may encounter severe bugs in some applications, which happen to indirectly link both libGL.so and libGLESv2.so into the address space of the same process
<ssvb>
if both libGL.so and libGLESv2.so are implemented by mesa, this just happens to work
<pitillo>
ummmm that sounds interesting, I've understood that mali doesn't suppport GL and I thought it should be provided by mesa directly, and relinking libs (EGL and GLES) should make it use the new ones (splitting GL and EGL)
<pitillo>
which could be the best scenario possible then? removing glx stuff from mesa and providing it directly from sunxi mali?
leviathancn has quit [Ping timeout: 246 seconds]
<plaes>
hrm.. I don't get the "open source"-ness of the allwinners media-codec
<ssvb>
pitillo: I'm afraid that I don't know what would be the best scenario, eradicating mesa completely is the safest option (assuming that you have no applications which depend on it)
<ssvb>
we are dealing with the buggy proprietary blobs and don't have much flexibility or choice
<ssvb>
other than getting a fully open source driver for mali up and running :)
<pitillo>
ssvb: ummmm, with the cubieboard is the same situation? I've managed to mix mesa3d and fbturbo pretty well, but with the cb2 there is no way
<ssvb>
pitillo: what are you going to use the proprietary mali driver for?
<pitillo>
ssvb: is that driver lima?
<pitillo>
nothing more that a desktop use (xorg only and probably give a try to enlightenment gles support)
<ssvb>
there should be no real difference between cubieboard1 and cubieboard2 in the userland
<pitillo>
that's what is making me get a bit angry, because I found differences in case of cubieboard2 and I can't get to the same point as cubieboard
<ssvb>
what kind of differences? what happens if you just swap the rootfs between cb1 and cb2?
<ssvb>
plaes: it's the open source wrapper around the proprietary cedarx libraries, and separating these things into different repositories is the right choice
<ssvb>
plaes: this clears "some" confusion, which is good, but still does not resolve the possible ffmpeg LGPL violation problem
<pitillo>
in case of cb2, it always used mesa (swrast), this is why I tryied to bump up the kernel (stage) and use r3p2 instead of r3p0 (used in the cb1)
<ssvb>
mali r3p2 works on cb1 too
<ssvb>
it just does not provide a significant performance improvement there
iamfrankenstein has quit [Quit: iamfrankenstein]
<ssvb>
mnemoc: ping
<plaes>
ssvb: thx, it confirmed my suspicions
Renard has joined #linux-sunxi
<ssvb>
plaes: don't take my word as an expert opinion :) it is libv who is analyzing the cedar blobs
reinforce has quit [Quit: Leaving.]
nuuhku has joined #linux-sunxi
<pirea>
plaes wait until libv will make an open source driver for mali
reinforce has joined #linux-sunxi
<plaes>
pirea: mali and media-codec are different pieces of hardware
<pitillo>
ssvb: let's see if I can make some tests into the cb1 with r3p2 and keep both devices "synced" with versions
<pitillo>
here there are some logs of the current cubieboard situation (http://crux-arm.nu/~pitillo/log/cubieboard/) which seems to be right (and what I'm not able to reproduce on the cb2, with 3.4 master branch kernel or the stage branch, neither r3p0 or r3p2)
<ssvb>
just try to take this rootfs to cb2 (do the exact copy of the sd card and then only replace u-boot)
<ssvb>
but as I said, this configuration looks unsafe
<ssvb>
just imagine what happens if you have a large application which depends on a lot of graphics libraries
<ssvb>
some of these libraries may pull in libGL.so, and the others may pull in libGLESv2.so
<ssvb>
but of course everything works perfectly fine for the simple hello-world style applications :-)
domidumont has joined #linux-sunxi
<pitillo>
that isn't explicit to the libs? I mean, some could pick up libGL (if they use them) and others GLESvx (in the same case they use them)... may be I'm missunderstanding something, but if thbuild is right (-lGL or -lGLESvx... they should pick they right ones)
<pitillo>
s/thbuild/the build
<ssvb>
GLES is a subset of GL, or something like this
<ssvb>
they don't have different name spaces for the function names
<nove>
should i do it? is that my current motivation is again zero.
reinforce has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
leviathancn has joined #linux-sunxi
cubeast has quit [Quit: Leaving]
kaspter has joined #linux-sunxi
gianMOD has joined #linux-sunxi
ssvb has joined #linux-sunxi
leviathancn has quit [Ping timeout: 250 seconds]
ganbold_ has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
_massi has quit [Remote host closed the connection]
<ssvb>
libv: allwinner people are really lazy, they seem to have just removed the 'ff_' function name prefixes instead of doing a more creative renaming job
orly_owl has quit [Ping timeout: 245 seconds]
<ssvb>
nove: do you mean replying to that e-mail from simosx?
<nove>
ssvb: no,
<libv>
ssvb: ok, i have currently only looked into the symbols which i had identified as libavcodec in august, which remained
<libv>
ssvb: good to know, will dig that out now too
<nove>
should i do the v4l2 driver? is the trouble worth? does sunxi has future? why is this so hard?
<nove>
this questions
<ssvb>
nove: sunxi does have a future, as long as there are people interested in improving support for their devices
orly_owl has joined #linux-sunxi
bobby_ has joined #linux-sunxi
<ssvb>
nove: putting on a KO hat, I would say that it's up to you to decide whether you want to be a part of this future
<ssvb>
nove: yes, people are assholes, they want the job getting magically done for them for free and would not bother to even say thanks
<bobby_>
mripard_: I changed the voltage to 1.45V in sun4i-a10.dtsi for 1008MHz frequency, recompiled and replaced the sun4i-a10-olinuxino-lime.dtb, reboot the board, run the same test ...
<bobby_>
failed
<bobby_>
also tried 1.35V and 1.5 V - failed
<ssvb>
nove: moreover, they would blame you for not delivering it earlier :)
FDCX_ has quit [Remote host closed the connection]
<wens>
bobby_: what board are you using and does the dts file have axp209 regulators?
<ssvb>
bobby_: afaik wens said that the voltage scaling does not work in the kernel
<wens>
if not, changing the voltage would not matter, as it won't take effect
<bobby_>
so it is either not setting the right voltage or I'm unlucky with this SoC
<bobby_>
OK
<wens>
it is possible that your dts file is not complete, i.e. missing axp209 regulators
<bobby_>
I'll try sunxi 3.4 kernel then
<wens>
without them, it is not possible to over-volt the core, and hence 1008MHz would not be stable
<wens>
mripard_: which fix do you think is better? a) remove 1008MHz OPP, b) add fallback 1.4V fixed-regulator for cpu
<ssvb>
wens: but it's the a10-lime that strikes again
<ssvb>
how many confirmed a10-lime 1008mhz instability cases do we have now? maybe 4 or 5?
<wens>
afaik 1008mhz should be stable for a10
<wens>
1008MHz @ 1.4V that is
<wens>
i thought it was the a20, which i know is not stable
<ssvb>
yes, except for a10-lime where it is prone to fail
<ssvb>
imho this needs to be handled on a per board basis, and u-boot should either restrict the top clock frequency in the cpufreq table or adjust the voltages
<mripard_>
wens: disable cpufreq if no regulator support is found?
<wens>
mripard_: that is part of cpufreq-dt, not sure it would be easy to change
<wens>
ssvb: we were going with the fex files in sunxi-boards
<ssvb>
mripard_: how is it going to help us? u-boot is already setting the maximum supported 1.4V core voltage, cpufreq in the kernel should work fine for any clock frequency even without the voltage regulator support
<ssvb>
it might not provide the expected power saving though
<wens>
bobby_: do you have a heatsink on the SoC?
<bobby_>
yes
<mripard_>
ssvb: I don't know, you were the one suggesting to use 1.45V for the rev A limes and the A20
<mripard_>
and we really shouldn't rely on u-boot.
<wens>
bobby_: so maybe you could try setting it to 1.45V in u-boot, and give 1008MHz another test?
<ssvb>
mripard_: I was in favor of reducing the clock frequency, because with the voltage increase the processor is prone to overheating
afaerber_ has joined #linux-sunxi
khuey|away is now known as khuey
<bobby_>
wens: I don't have time now, I'll do it later
<wens>
bobby_: thanks
<ssvb>
mripard_: some kernels are relying on reading the speed grade information from efuses
<ssvb>
mripard_: how is relying on u-boot worse than that?
<wens>
how would the kernel or u-boot know the board is rev. A, and not the more stable rev. B or C?
<mripard_>
it's not a matter of wether it's worse or not
<ssvb>
wens: regarding the voltages in fex files, the idea is not too bad, but the execution is horrible
<ssvb>
wens: rev. B and rev. C were also reported to fail
<mripard_>
but rather are you 100% sure it happened
<mripard_>
and the fact is you aren't
<bobby_>
my board is rev. C
<mripard_>
and if you don't have any regulator support, the kernel can't do anything about it
afaerber has quit [Ping timeout: 255 seconds]
afaerber_ is now known as afaerber
<ssvb>
mripard_: 100% sure that happened what?
leviathancn has joined #linux-sunxi
<mripard_>
ssvb: that u-boot set up the right frequency
<ssvb>
mripard_: do you mean voltage?
<mripard_>
yeah, sorry
<ssvb>
the sunxi-3.4 kernel can report axp209 voltages, we can easily check it
<ssvb>
but the a10-lime board is a known offender, there is nothing surprising that it fails
<wens>
ssvb: so we should probably just override the opps in the a10-lime dts?
<ssvb>
wens: yes, that's an option
<ssvb>
does the thermal throttling work now?
<wens>
with the not so working thermal sensor on a10? i have no idea
<wens>
s/working/accurate/
<ssvb>
we can make the A10 CPU overheat even with 1008MHz @1.4V
<ssvb>
using an artificial workload though
<wens>
with the other SoCs, the limits are higher than what i can achieve with all cores fully loaded
<ssvb>
power consumption increases quite significantly at higher voltages, so going beyond 1.4V might be enough to overhead even the CPU alone
<nove>
wens: don't use the word "cedarx"(proprietary software) when talking about the hardware, use "cedar engine" or "video engine"
<wens>
ok
<wens>
ssvb: and overheating is witnessed as a crash?
<nove>
ssvb: do you believe that the video engine can be a good memory stresser?
paulk-collins has joined #linux-sunxi
<ssvb>
wens: yes, when it heats up too much (according to oliv3r, that's ~110C)
bobby_ has quit [Quit: Page closed]
<wens>
ouch
<ssvb>
wens: there were overclockers/overvolters who have experienced this, maybe I can find the relevant e-mail
<wens>
i don't think i'll have time to test it this week, so it will have to wait till mid-april
konradoo77 has quit [Ping timeout: 265 seconds]
<jemk>
need some more LGPLed symbols from libvdecoder.so or shall I publish them directly? Many important parts of h264 decoder are copied from ffmpeg, H264FillDefaultRefList and subfunctions are very obvious in disassembly for example.
konradoo77 has joined #linux-sunxi
<ssvb>
wens: are you going on a vacation until mid-april?
<wens>
business travel to U.S. for a month
<wens>
i'll most likely be very busy installing servers at our datacenter
<ssvb>
ok
cubeast has joined #linux-sunxi
<ssvb>
anyway, I have just started cpuburn-a8 on a cubieboard running with the default 1008MHz @1.4V and it is consuming 0.9A
<ssvb>
wens: I need to also run some lightweight 'canary' application, which could be used to detect fail on overheating
HeHoPMaJIeH has quit [Quit: Konversation terminated!]
<ssvb>
jemk: if they have not modified the ffmpeg code, then it should be relatively easy for them to move it into a separate shared library
<jemk>
ssvb: I'm not sure if it is modified, only had a quick look
<ssvb>
jemk, libv: regarding the older libvdecoder releases, at least allwinner did not distribute them to the end users directly
<ssvb>
which means that they in practice have no obligations to honor the requests of the end users
<ssvb>
the users should go to to the manufacturers of their tablets for the sources
<libv>
ssvb: which is exactly what allwinner had been hiding behind for years and years :(
<libv>
i am well aware of this, hence my definitive proof email
<libv>
and that does not make allwinners actions any more acceptable
<ssvb>
I'm just afraid that if they are pressured too much, then they will just go back to the old way of doing things
<libv>
the market changed in the meantime
<libv>
and they are part of linaro
<libv>
and we now have definitive proof
<libv>
allwinner would not be doing this if rockchip wasn't also slowly moving in this direction
Dodger78 has joined #linux-sunxi
<libv>
ssvb: i am convinced that at this point, now that this has some momentum, all the license issues should get resolved
khuey is now known as khuey|away
<ssvb>
nove: as for the memory stresser, g2d (90 degrees rotated blit) is a good memory stresser and can be used instead of mali in lima-memtester to induce memory errors
sehraf has quit [Ping timeout: 244 seconds]
<ssvb>
nove: I also tried video decoding with cedar, but it was not very good for this purpose
<ricardocrudo>
is possible use otg usb as device only?
<ssvb>
nove: we need some specific "bad" memory access pattern, and it may be hard to do this with cedar
<ssvb>
ricardocrudo: with the mainline kernel?
simosx has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
<ricardocrudo>
ssvb: both, mainline and sunxi 3.4.X
<ssvb>
ricardocrudo: pick one for the start :) but the answer is "yes"
ricardocrudo has quit [Ping timeout: 245 seconds]
gianMOD has joined #linux-sunxi
nuuhku has quit [Ping timeout: 246 seconds]
ricardocrudo has joined #linux-sunxi
<ssvb>
wens: ok, now my cubiebord has finally failed the cpuburn-a8 test and I'm stopping the torture
gianMOD has quit [Client Quit]
<ssvb>
wens: so I would guess that if you run cpuburn-a8 long enough on a10 with 1008mhz @ 1.4V, it can still gradually overheat to the point of failure
<wens>
my cubie has a heatsink, probably why it didn't crash
leviathancn has quit [Ping timeout: 272 seconds]
Netlynx has joined #linux-sunxi
Netlynx has joined #linux-sunxi
<ssvb>
atsampson: I remembered why I did not use dcdc3 voltage higher than 1.325V on my cubieboard
<ssvb>
the board just becomes unreliable at 1.35V for some reason
<ssvb>
more specifically, it even often deadlocks in the middle of booting
<atsampson>
ssvb: hm, interesting -- I do wish we had someone from Allwinner to talk to about this stuff!
FreezingAlt has joined #linux-sunxi
domidumont has quit [Read error: Connection reset by peer]
<ssvb>
this does not happen with the cubietruck though, and the a13-olinuxino-micro has this voltage hardcoded at 1.4V (it has no pmic)
<ssvb>
cubieboard is also a bit strange in the sense that the OTG VBUS is directly connected with the 5V barrel plug
FreezingAlt has quit [Remote host closed the connection]
<ssvb>
I don't know, one of the random ideas is that it might be some overcurrent protection kicking in
FreezingCold has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
<wens>
the axp by default does current limiting on the vbus input
konradoo77 has quit [Ping timeout: 264 seconds]
konradoo77 has joined #linux-sunxi
bengal_ has joined #linux-sunxi
bengal_ has quit [Read error: Connection reset by peer]
khuey|away is now known as khuey
bengal has joined #linux-sunxi
bengal has left #linux-sunxi [#linux-sunxi]
bonbons has joined #linux-sunxi
domidumont has joined #linux-sunxi
domidumont has quit [Client Quit]
Dodger78 has quit [Read error: Connection reset by peer]
domidumont has joined #linux-sunxi
awe00 has quit [Ping timeout: 272 seconds]
akaizen has quit []
DagoRed has quit [Read error: Connection reset by peer]
FR^2 has quit [Quit: Connection reset by peer]
konradoo87 has joined #linux-sunxi
diego_r has quit [Ping timeout: 244 seconds]
konradoo77 has quit [Ping timeout: 255 seconds]
pirea has joined #linux-sunxi
Andy-D has joined #linux-sunxi
<pirea>
ssvb mkv don't play smooth even with 576 ram clk, -nosound and VDPAU_OSD=0
maz has joined #linux-sunxi
premoboss has joined #linux-sunxi
ssvb has quit [Ping timeout: 256 seconds]
khuey is now known as khuey|away
Netlynx has quit [Remote host closed the connection]
ricardocrudo has quit [Ping timeout: 252 seconds]
ssvb has joined #linux-sunxi
awe00 has joined #linux-sunxi
konradoo87 has quit [Ping timeout: 264 seconds]
konradoo77 has joined #linux-sunxi
libcg has joined #linux-sunxi
pirea has quit [Quit: pirea]
pirea has joined #linux-sunxi
Froolag has joined #linux-sunxi
froolap has quit [Read error: Connection reset by peer]
rsevero has joined #linux-sunxi
boycottg00gle has joined #linux-sunxi
<rsevero>
Hi, I'm trying to use a mainline kernel on my Banana PI. I've installed my new u-boot-sunxi-with-spl.bin, sun7i-a20-bananapi.dtb, zImage, boot.cmd and created my boot.scr. During boot with my new kernel the boot prcess hangs with "Starting new kernel" for a while and them reboots and repeats the process. Ideas on what could be wrong? How to fix?
<boycottg00gle>
rsevero: maybe your boot.cmd / load addresses (just a wild guess)
<rsevero>
I thought about it.
<rsevero>
I'm using fatload mmc 0 0x46000000 zImage and fatload mmc 0 0x49000000 <board>.dtb that I got from the http://linux-sunxi.org/Mainline_Kernel_Howto page. How can I check if it's really appropriatte for me?
<rsevero>
Also, at the begining of the boot process I have the following error message:
<rsevero>
**** Warning - bad CRC, using default environment
<rsevero>
Is it relevant?
<diego71>
rsevero: no, it's normal :)
<rsevero>
diego71: Thanks.
<rsevero>
Any ideas on other load addresses?
<boycottg00gle>
the one from the wiki should be fine
domidumont has quit [Remote host closed the connection]
khuey|away is now known as khuey
<atsampson>
rsevero: are you using a known (reasonably-)good kernel config, e.g. sun7i_defconfig, and are the kernel parameters correct for you to be able to see the serial console output? (I guess you could see the output you're getting if it's booting without kernel messages and it fails to mount the root fs, for example...)
konradoo77 has quit [Ping timeout: 264 seconds]
domidumont has joined #linux-sunxi
pmattern has joined #linux-sunxi
jinzo has quit [Ping timeout: 246 seconds]
nove has quit [Quit: nove]
domidumont has quit [Ping timeout: 246 seconds]
mmarker has quit [Read error: Connection reset by peer]
<rsevero>
atsampson: I'm using sun7i_defconfig and I'm seeing boot messages in my monitor (HDMI port). Serial port would give me more messages?
mmarker has joined #linux-sunxi
<rsevero>
boycottg00gle: That's what I'm using. Ideias?
<atsampson>
rsevero: are you seeing messages *from the kernel* on your monitor?
jinzo has joined #linux-sunxi
<rsevero>
atsampson: I don't think so. The last message I sse is "Starting the new kernel". Then it hangs for some time and reboots.
konradoo77 has joined #linux-sunxi
<atsampson>
rsevero: do you have CONFIG_FB, CONFIG_FB_SIMPLE, CONFIG_FRAMEBUFFER_CONSOLE turned on in your kernel config? (have a look at .config)
<atsampson>
I don't think sun7i_defconfig enables those, so if you're trying to get output from the kernel via HDMI then I'd check they're turned on
<rsevero>
atsampson: I don't have CONFIG_FRAMEBUFFER_CONSOLE. The others I have. I will recompile the kernel and test.
<atsampson>
rsevero: if you've got a serial cable then that may also be worth a try
ricardocrudo has joined #linux-sunxi
<rsevero>
atsampson: I will try CONFIG_FRAMEBUFFER_CONSOLE first as it's way easier ;)
<atsampson>
:)
<rsevero>
atsampson: Humm, now the message "Starting kernel..." stays for a second and the screen goes blank for a while until the computer reboots.
<rsevero>
Is it time for me to make a serial cable?
<atsampson>
aha, that sounds hopeful :) try adding console=tty1 to your kernel args?
<rsevero>
With the serial cable or now?
<atsampson>
now -- if it's going blank then that means the kernel's initialising the framebuffer console, but it's not printing anything to it
<atsampson>
so I guess you've got console=ttyS0,115200 or similar in your kernel args?
<rsevero>
Yes, that's what I ahve.
<atsampson>
(indeed, if I recall correctly, you can actually say "console=ttyS0,115200 console=tty1" in bootargs and it'll print to both...)
<rsevero>
Should I change for tty1?
<atsampson>
yep
<rsevero>
Great.
<rsevero>
atsampson: It worked. I'm seeing the boot messages on the monitor.
<rsevero>
Kernel panic, no init found.
<atsampson>
excellent -- now you should be able to tell why it's not happy
<rsevero>
atsampson: Great. My root= setting was wrong. THANKS!!
<atsampson>
:)
gianMOD has joined #linux-sunxi
boycottg00gle has quit [Remote host closed the connection]
Black_Horseman has joined #linux-sunxi
meow` has quit [Ping timeout: 264 seconds]
pmattern has quit [Ping timeout: 255 seconds]
RSpliet has quit [Read error: Connection reset by peer]
RSpliet has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
bonbons has quit [Quit: Leaving]
konradoo77 has quit [Ping timeout: 246 seconds]
cubeast has quit [Quit: Leaving]
meow` has joined #linux-sunxi
jinzo has quit [Quit: Leaving]
konradoo77 has joined #linux-sunxi
meow` has quit [Ping timeout: 255 seconds]
konradoo77 has quit [Ping timeout: 272 seconds]
meow` has joined #linux-sunxi
lerc has joined #linux-sunxi
libcg has quit [Quit: libcg]
paulk-collins has quit [Quit: Quitte]
gianMOD has quit [Remote host closed the connection]