<wingrime>
thay replace gtalk from andoid with Hangout
<wingrime>
that realy non XMPP
<wingrime>
anyway I want gpg with XMPP
n01|away is now known as n01
<hno>
Tartarus, tried linaro 4.7 & 4.8 2013.04 and it is not set for building -march=armv4, it expects -march=armv4t for any softfloat target. And the board is using a linker script which is not adjusted for build-id.
<hno>
wonder how it manages to build ARMv7 soft-float..
shineworld has quit [Read error: No route to host]
<hno>
odd.
<hno>
it picks the hard-float libraries but do not complain.
<hno>
on ARMv7.
<hno>
aha, misremembered the error seen by techn__. No it's not the same at all Tartarus.
<hno>
presumably it accepts doing that on ARMv7 because hardfloat is mandatory in ARMv7-A
shineworld has joined #linux-sunxi
_BJfreeman has joined #linux-sunxi
_BJfreeman is now known as BJfreeman
vicenteH has joined #linux-sunxi
BJfreeman has quit [Ping timeout: 241 seconds]
orsic has joined #linux-sunxi
LoCoZeNoz_ZUE has joined #linux-sunxi
<oliv3r>
hno: then I haven't looked correctly. here's the strace for both hexdump and cat http://paste.debian.net/4722/
<oliv3r>
i'lll go over it now too
<oliv3r>
wingrime: what do you mean from jabber, they used jabber or xmpp; if they don't use either (wasn't it the same, i forgot), then google has just become a little more evil
<oliv3r>
unless of course they make something better and fully open source it of course
<mripard>
techn__: hi
<mripard>
you added support for the RTCs to the mainlining wiki pages?
<oliv3r>
oh and my driver always crashes the kernel on shutdown/reboot :(
<hno>
oliv3r, yes, returning 0 instead of permission denied at the end of data is more appropriate.
<oliv3r>
hno: sorry, didn't think of that
<oliv3r>
so when done reading, add a \0 and exit
<oliv3r>
makes perfect sense
<oliv3r>
the only issue that remains, is a kernel oops on reboot/shutdown
<oliv3r>
probably on _remove() i suspect
<oliv3r>
so read tries to read 4096 bytes, fails at byte 17 (perm denied) and you get the error; I didn't think of 'read all' :) i always only thought of combinations of reading that 'fit'
shineworld is now known as shine|debug
<LoCoZeNoz_ZUE>
oliv3r, At stage of "Building script.bin" what MAC should i use?
<LoCoZeNoz_ZUE>
The wireless mac?
<LoCoZeNoz_ZUE>
Can i do "spoofing" here?
<LoCoZeNoz_ZUE>
hello?
<LoCoZeNoz_ZUE>
What mac address should i use?
<hno>
oliv3r, return 0 length at end of data. Not a \0.
tinti has joined #linux-sunxi
<hno>
LoCoZeNoz_ZUE, leave it blank. The kernel assigns one random.
<LoCoZeNoz_ZUE>
:3
<LoCoZeNoz_ZUE>
If i had no [dynamic] section, should i add it?
<hno>
to fill it in you need to either fake one or buy one.
<LoCoZeNoz_ZUE>
"buy one"?
<hno>
yes, MAC addresses are bought by the manufacturers.
<LoCoZeNoz_ZUE>
Or spoofed to what ever by me :3
<LoCoZeNoz_ZUE>
nvm, my current mac is "MAC = "00531301dfdf""
<hno>
yes, if you like. But doesn't really matter for most usage.
<LoCoZeNoz_ZUE>
The one i got in android right now
<LoCoZeNoz_ZUE>
It doesnt seem to be checkable by "mac addr bases"
<LoCoZeNoz_ZUE>
nvm, should i add a [dynamic] section at all?
<hno>
If you god one with the device then by all means preserve it.
<LoCoZeNoz_ZUE>
?
<hno>
It might even be a legit MAC address.
<hno>
If your device came configured with a MAC in the NAND then keep it.
<LoCoZeNoz_ZUE>
usualy i always spoofed all my mac addreses for security reasons
<mnemoc>
it's probably random. but to not confuse your DHCP you probably want to make it fixed in script.bin anyway
<LoCoZeNoz_ZUE>
The mac doesnt seem to be "normal"
<LoCoZeNoz_ZUE>
I dont belive in DHCP. I use static setups always
<hno>
is it the same if you reboot?
<LoCoZeNoz_ZUE>
2 sec, gonna reboot
<hno>
What board do you have?
<LoCoZeNoz_ZUE>
inet97f
<LoCoZeNoz_ZUE>
No, MAC is same betwen reboots
<LoCoZeNoz_ZUE>
But no "MAC base" finds it
<LoCoZeNoz_ZUE>
but nvm
<LoCoZeNoz_ZUE>
il use it
<LoCoZeNoz_ZUE>
Should i add a [dynamic] section with mac addr?
<LoCoZeNoz_ZUE>
so.....
<LoCoZeNoz_ZUE>
yes/no?
<mnemoc>
check /proc/cmdline, it can come from there
<mnemoc>
passed by the bootloader
<oliv3r>
hno: set buf[size] = '\0'; AND return 0 :)
<mnemoc>
overflow
<oliv3r>
hno: anyhow, my thinking mistake was, that by setting .size = MAXSIZE i assumed it would only try to read that much, but if I query that block again, with an pos of 1, and size of MAX_SIZE, i'll be to large again, my thinking mistake so I know how to fix it
<oliv3r>
mnemoc: yeah, but i got guards for all situations now i think
<oliv3r>
mnemoc: hmm, then we have to change so that it does :p or atleast fills in stuff
<oliv3r>
mnemoc: i made a 'sunxi-next' branch for the bsp, that takes dtb into account
<mnemoc>
iirc the scripts assume it optional
<oliv3r>
well u-boot needs to pass the dtb along, so 'some' info for it is required, and I don't think we want to name it file.dtb, that's way to generic
<mnemoc>
the kernel can have the .dtb embedded too
<oliv3r>
yeah I tried that, but my u-boot fails to boot it
<oliv3r>
'invalid kernel image'
<mnemoc>
"don't assume too much"
<mnemoc>
ouch
<oliv3r>
i'll try again to be sure of course
<mnemoc>
if our u-boot doesn't support images with embedded dtb that's a bug imo
<LoCoZeNoz_ZUE>
As i told you all yesterday, i lost my MicroSD card adapter. so i am doing everything from android. Can i put script.bin, uImage and boot.cmd in one dir (not on SD) and run mkimage there?
<oliv3r>
well i did use an old u-boot (sunxi-current) and gave up that root
<oliv3r>
LoCoZeNoz_ZUE: thechnically, of course
<LoCoZeNoz_ZUE>
thanks.
<oliv3r>
LoCoZeNoz_ZUE: android is still linux
<oliv3r>
LoCoZeNoz_ZUE: but just run 'make'
<LoCoZeNoz_ZUE>
No, i mean from pc
<oliv3r>
then dd the spl, u-boot binary to your sd card from android
<LoCoZeNoz_ZUE>
Can i put those 3 files on "NON-SD" folder, and run mkimage?
<mnemoc>
don't confuse people, for most "linux" isn't only the kernel but also the kind of userspace :p
<oliv3r>
why do you want to run mkimage
<LoCoZeNoz_ZUE>
oliv3r, Using "manual" way in FirstSteps manual
<LoCoZeNoz_ZUE>
manual way in manual *rolf*
<oliv3r>
LoCoZeNoz_ZUE: all you need to do is run 'make' to build the hwpack
<oliv3r>
once you have the hwpack, you have all the files you need
<oliv3r>
copy those files to 'anywhere' on your android installation
<LoCoZeNoz_ZUE>
oliv3r, I choose another way
<LoCoZeNoz_ZUE>
So can i use mkimage?
<oliv3r>
run dd if=/file/to/u-boot; of=/dev/block/mmc0 or likly
<oliv3r>
but you don't need mkimage
<oliv3r>
you can, but you don't need it
<LoCoZeNoz_ZUE>
*facepalm*
<LoCoZeNoz_ZUE>
*facepalm* *facepalm*
<oliv3r>
if you crosscompile on your PC; 'make' in the bsp runs mkimage and creates spl, u-boot, kernel + modules
<LoCoZeNoz_ZUE>
Total misunderstanding
<oliv3r>
LoCoZeNoz_ZUE: i don't think you have mkimage on your android :)
<LoCoZeNoz_ZUE>
i know
<oliv3r>
mnemoc: kernel + busybox lets you do a lot of things :)
<LoCoZeNoz_ZUE>
*triple facepalm*
<LoCoZeNoz_ZUE>
someone, i need a third hand here XD
<oliv3r>
LoCoZeNoz_ZUE: so what do you need to do?
<mnemoc>
sure, but even a simple busybox-based initramfs is more "linux" than android
<LoCoZeNoz_ZUE>
I have choosen the "The flexible option: manual build and installation" way
<LoCoZeNoz_ZUE>
I dont have mkimage on android
<mnemoc>
oliv3r: regardling available tools and filesystem hierarchy
<LoCoZeNoz_ZUE>
So can i download those 3 files (script.bin uImage and boot.cmd) to my pc, and run mkimage at them there. They will be on folder, not on SD card
<LoCoZeNoz_ZUE>
Does mkimage just generates a file using those 3, or it does something to SD card as well?
<LoCoZeNoz_ZUE>
nvm, il just do it.
<LoCoZeNoz_ZUE>
Is it safe to use ext2 instead of ext3?
<Dreadlish>
ext2 is just ext3 without journaling
<Dreadlish>
and some features
<Dreadlish>
but it's usable
<LoCoZeNoz_ZUE>
:3
<LoCoZeNoz_ZUE>
Will use it
<hno>
uImage is an mkimage generated image. Already done.
<LoCoZeNoz_ZUE>
yeah, but my aim was boot.scr
<LoCoZeNoz_ZUE>
but nvm, finished with that
<hno>
For most uses uEnv.txt is simpler than boot.scr.
<LoCoZeNoz_ZUE>
double nvm, already done = already done not matter how hard it is
<oliv3r>
LoCoZeNoz_ZUE: again,w hy do you need to run mkimage? you have a partition on your SD card, that is fat16, copy script.bin, uImage and boot.cmd there
<oliv3r>
mkimage is either to create a uImage from zImage (the bsp does that for you) or mkbootimg, which creates an android boot.img, which you don't need
<LoCoZeNoz_ZUE>
oliv3r, I was generating boot.scr
<oliv3r>
doesn't the bsp take care of that?
<oliv3r>
not sure, i don't use boot.scr i use uEnv.txt atm
<oliv3r>
but you can generate boot.scr on your pc, and copy that file :p
<oliv3r>
the only thing that needs to be done directly on the SD card (from android) is dd x2, + mkpartition + copy files
<LoCoZeNoz_ZUE>
ok
<LoCoZeNoz_ZUE>
thanks
<LoCoZeNoz_ZUE>
But anyway, i have done with that
<oliv3r>
once you have the spl and u-boot written using dd, you don't even need to do anything in android anymore
<oliv3r>
everything can be done by 'sharing SD via usb'
<oliv3r>
since it's just copying file
<oliv3r>
new kernel? no problem, just copy uImage
<oliv3r>
new rootfs? no problem, just copy the files you wnat to change :)
<LoCoZeNoz_ZUE>
oliv3r, Problem solved, go away
<LoCoZeNoz_ZUE>
Stop solving problems that no longer exist
<oliv3r>
o.O
<oliv3r>
i'll remember that next time you need help :(
<LoCoZeNoz_ZUE>
Can i use the "boot partition" with u-boot and stuff to be the /boot of my gentoo install?
<oliv3r>
LoCoZeNoz_ZUE: you trying to install to nand now?
<LoCoZeNoz_ZUE>
nope
<LoCoZeNoz_ZUE>
At the moment to SD
<LoCoZeNoz_ZUE>
I got 3 partitions
<LoCoZeNoz_ZUE>
1 is extremely small with uImage, boot.cmd, boot.scr and script.bin.
<LoCoZeNoz_ZUE>
Another is 512MB swap
<LoCoZeNoz_ZUE>
and another is ext2 root for my gentoo
<LoCoZeNoz_ZUE>
can i use the first one as /boot?
<oliv3r>
oh i understand, yes you can do mount /dev/mmc0p1 /boot in your gentoo
<libv>
oliv3r: yeah, though i wish i had endless amounts of time, and could go and fix everything, lima is what i really should be focussing on
<LoCoZeNoz_ZUE>
"is it ok to"
<oliv3r>
LoCoZeNoz_ZUE: but not much point in doing so, you won't install grub, you won't install a kernel directly from there, but yes, you can mount it
<LoCoZeNoz_ZUE>
Mount on "constant" basis
<LoCoZeNoz_ZUE>
Like i mount it in normal desktop installs?
<oliv3r>
libv: yeah :( don't we all have that problem :)
<oliv3r>
LoCoZeNoz_ZUE: sure, it's 'just a partition'
<LoCoZeNoz_ZUE>
:3
<mripard>
oliv3r: remove the __initdata for your platform_device structure
<mripard>
*platform_driver
<LoCoZeNoz_ZUE>
I got several folders here. And i dont know what to choose for Inet97f
<ssvb>
I think many /system/lib/* paths are hardcoded (you can see it if you grep the sources), but it may be better to ask in the #libhybris channel
<rellla>
ok. so it was no vecore special thing.
<ssvb>
as for the screen blanking, there is FBIOBLANK ioctl to to control this, for example it is used by X server
<ssvb>
XBMC might need to add some code to prevent screen blanking if it insists on working with the framebuffer without X
vinifm has quit [Quit: Saindo]
<Turl>
mripard: oops
<techn__>
ssvb: what's the problem?
<LoCoZeNoz_ZUE>
damnnn..... why have i done it: Boot, Swap, Root. Now root constantly shows up as either p2 or p3.
<techn__>
screen blanks.. ok.. but why it wont unblank?
<ssvb>
techn__: it's just that XBMC is not quite ready for normal use yet, nothing seems to be wrong with the framebuffer driver so far
<techn__>
imho our current screen blanking implementation is too powerfull.. it disables display controller, which could cause problems if someone uses those registers
<techn__>
usually blanking is done by disbling blank signal or something like that? :/
<techn__>
mripard: did you get answer for your question already?
<mripard>
techn__: yes, I think so :)
<mripard>
I overlooked that there was an RTC in the A10, so I was wondering what RTC you were refering to in the mainlining wiki page
<mripard>
but oliv3r made me notice that it was probably the one embedded in the chip
<techn__>
mripard: also there is some i2c RTC driver stuff.. dunno what is their purpose
<mripard>
well, I know that on the olinuxino, there is an I2C RTC
<mripard>
these RTCs usually drain way less power than their SoC-embedded counterparts
<mripard>
so I guess that's why
<rellla>
techn__: can i disable the blanking at the kernelside?
<LoCoZeNoz_ZUE>
everytime i insert SD while in android. It annoyingly makes a LOST.DIR at my boot partition. How to "fucking disable"?
<techn__>
rellla: who controls blanking when XBMC is started? fbcon does some controlling also :/
<techn__>
rellla: btw. is there still that blinking fbcon cursor problem?
<rellla>
i don't know. but i never had problems with old kernel last year, so believe it has sth to do with the kernel
<rellla>
ah, cursor problem?
<techn__>
yes. atleast couple months ago there was cursor blinking top of framebuffer xbmc
<Turl>
LoCoZeNoz_ZUE: unmount it safely? it's the equivalent of lost+found on extN partitions
<rellla>
i can't remember that i ever noticed this.
<rellla>
btw. if screen is blanked i can switch through the menus, play files, audio is working but all is done blindly ;)
<LoCoZeNoz_ZUE>
Turl, As i remember EXT* got lost+found but not LOST.DIR
<LoCoZeNoz_ZUE>
Turl, I alot of times need to shut down the tablet using "reset hole"
hansg has quit [Remote host closed the connection]
<techn__>
rellla: your github is preferred place to get xbmca10?
<rellla>
techn__: i think so.
<rellla>
no great changes to empat0 but some fixes for dependencies
<mnemoc>
do we want "official" libhybris-cedarx and libhybris-sunxi-mali repos yet?
<hglm>
The linux-sunxi wiki's email confirmation seems to be broken (it says PHP mail error). I wanted to edit a page, but without confirmation I can't.
<mnemoc>
uhm
<mnemoc>
hglm: can you paste me the whole error?
<ssvb>
mnemoc: I would prefer to submit the libhybris patches upstream
<ssvb>
mnemoc: but currently wait for more feedback from the users (to confirm that it is actually useful and has no regressions compared to the linux blob)
<Turl>
LoCoZeNoz_ZUE: that's why I said it's the equivalent of, extN got lost+found, fat has LOST.DIR
<hglm>
Mailer returned: Unknown error in PHP's mail() function.
<Turl>
mnemoc: some other person had issues with wiki mail too the other day
<LoCoZeNoz_ZUE>
oh
ganbold_ has quit [Ping timeout: 256 seconds]
<mnemoc>
hglm: can you try now?
<hglm>
I will.
<hglm>
Still the same error message.
<mnemoc>
hum
<mnemoc>
uhm*
shineworld has quit [Quit: Leaving]
ganbold_ has joined #linux-sunxi
<techn__>
rellla: looks like xbmc wont do fbblank.. atleast by it self
<techn__>
maybe some library which it uses?
<techn__>
or fbcon?
<techn__>
or are you running x on background?
<hno>
LoCoZeNoz_yes. Or if you prefer you can have root on the first partition and a /boot within it.
<hno>
LoCoZeNoz_ZUE ^
<LoCoZeNoz_ZUE>
hno, erm.....
<LoCoZeNoz_ZUE>
I mean the partition with uImage, boot.cmd and stuff
<LoCoZeNoz_ZUE>
1. Is it safe to mount it in gentoo as /boot?
<LoCoZeNoz_ZUE>
2. Is it safe to "move files around" becouse as i know it may damage it
<rellla>
techn__: xbmc is running on framebuffer. no X here.
<hramrach_>
when running xbmc you should run xset -dpms
<hramrach_>
it does not runt without X here
<hramrach_>
it uses X for video output for some reason
<hramrach_>
and draws UI on framebuffer
<rellla>
hramrach_?
<hno>
LoCoZeNoz_ZUE, yes it's safe to have it as /boot. Yes you can move files around as you please as long as you keep the right files there.
<hramrach_>
yes, that's how it works for me
<hramrach_>
maybe depends on some librraies you have when building
<LoCoZeNoz_ZUE>
hno, Becouse i know that if you move bootloader "loader" around it will not boot, as the mbr will point at wrong plae
<hno>
LoCoZeNoz_ZUE, what I meant is that you don't need a separate partition. Works just fine to have your root on the first partition.
<LoCoZeNoz_ZUE>
place
<hramrach_>
does not even start without X server running
<LoCoZeNoz_ZUE>
hno, So like i can have 1 big partition?
<hno>
LoCoZeNoz_ZUE, the bootloader is outside the partiitons, Thats why you dd there.
<rellla>
i have no X server installed or running here.
<hno>
Yes.
<hramrach_>
I cannot run xbmc without X server running here
<LoCoZeNoz_ZUE>
But... what are those boot.cmd, uImage
<rellla>
what is the error message?
<LoCoZeNoz_ZUE>
...
<hramrach_>
cannot open display
<hno>
uImage is the kernel.
<LoCoZeNoz_ZUE>
ok
<LoCoZeNoz_ZUE>
hno, Do you know much about "boot" procces on normal pc?
<Skaag>
oliv3r: yes I know this device was never used by anyone with Linux, thanks for looking up though (I did the same, couldn't find anything). It's a very proprietary device, and very unpopular (it's a cash acceptor)
<rellla>
ssvb: sintel trailer plays without artifacts with libhybris here. but it hangs a bit - every second. like frame drops
<techn__>
rellla: what fbset says?
<LoCoZeNoz_ZUE>
Does anyone know what special can i add in gentoo's make.conf for inet97f?
<techn__>
rellla: khh.. I mean are you using different frequenzy than disp gives to xbmc?
<techn__>
this may fail if you use our "edid support"
<rellla>
i use the edid line
<techn__>
which refresh rate it gives you?
<techn__>
(check via fbset) .. xbmc most likely shows it wrong
<hglm>
I wrote an improved utility to change the display output mode on tablets and other A10 devices: https://github.com/hglm/a10disp Read the README before running it. It has only been tested on one device (my tablet). You can use it to set a lower resolution or 16bpp mode to improve system performance.
vinifm has quit [Read error: Connection timed out]
<rellla>
techn__: fbset says its 1280x720@60Hz
vinifm has joined #linux-sunxi
<rellla>
i'll have to go now, thanks for now. i feel i made a few steps forward today ;)
<techn__>
rellla: great :)
<techn__>
hglm: nice. have you tried to pipe layers? :)
rellla has quit [Remote host closed the connection]
<hglm>
I am not touching the layers except setting the working mode and modifying scaler mode :)
<techn__>
hglm: you should be able to make pipe and use different properties of layers combined. normal->scaler->output
<techn__>
havent tested how it works.. but you seem to have nice tool for testing :p
rz2k has joined #linux-sunxi
<hglm>
I am using it to switch reliably from LCD to HDMI and vice versa, and to set different HDMI modes with 32bpp and 16bpp...I measured how difference it makes in benchmarks (memory bandwidth).
<ssvb>
have you seen any allwinner devices reporting something other than 0x1623 for this register?
<wingrime>
ssvb: I see in libve others
<wingrime>
libve.so support otheres
<ssvb>
who cares?
<wingrime>
same a10 may have differ revisions with differ ve revisions
<ssvb>
or possibly may not
<JonnyH>
Hi all, sorry to but in, but does anyone know what the current status of a31 on linux is?
<ssvb>
wingrime: we need to first find some device which has a different incompatible revision
<wingrime>
agree
<ssvb>
maybe 0x1625 is something like A31
<ssvb>
just a guess
<wingrime>
or just bug fixes in same naming
<wingrime>
like VER_A
<ssvb>
sun6i sources have CHIP_VERSION_F33 define in cedarx code
ganbold_ has quit [Remote host closed the connection]
ganbold_ has joined #linux-sunxi
<ssvb>
if this register is really the version of cedarx hardware, then we want to have a table listing the values of this register for all sunxi devices
<hglm>
JonnyH: I am not an expert, but probably too different from a1x to be supported easily. Probably better chances for the a20.
<wingrime>
ssvb: it still have 0x1623 after using cedarX
<JonnyH>
hglm: I've got the kernel at git.hands.com booting on my a31 tablet but seems to have difficulty loading the root fs off the nand
<wingrime>
>
<wingrime>
?
<ssvb>
wingrime: no, it reverted back to 0x0013
<ssvb>
wingrime: it is only read as 0x1623 when cedarx is actually working
<hglm>
JonnyH: Not sure but maybe try a ramdisk root fs to see if it works?
<wingrime>
ssvb: can you patch driver make it clocked after driver init
<JonnyH>
hglm: It seems to build a binary 'nand.ko' - I guess that needs to be loaded from a ramdisk
<JonnyH>
I'll give that a go...
<ssvb>
wingrime: do I understand it correctly that you just got this value from Iain's logs? have you tried to read it on your own device?
mdp has quit [Read error: Operation timed out]
mdp has joined #linux-sunxi
<wingrime>
ssvb: fist time I find this in libve.so dissassembly
<hno>
1625 is A13. 1623 is A10.
<hno>
those are Allwinner SoC internal identifiers.
<hglm>
JonnyH: Maybe compile nand.ko into the kernel (not module).
<hno>
ssvb & wingrime ^
<ssvb>
wingrime: don't get me wrong, but can't you check all this IOCTL_ENABLE_VE, IOCTL_SET_VE_FREQ, IOCTL_RESET_VE stuff yourself and only bugger me and the other people only to confirm your findings?
<hno>
A31 is 1633
<wingrime>
ssvb: not now
<lkcl>
hno: evnin sah
<wingrime>
ssvb: a13 not nearly
<hno>
hi lkcl
<mripard>
drachensun: ping?
<lkcl>
am just trying out hglm's program to get hdmi up-and-running. fuuuun
<drachensun>
yo
<mripard>
drachensun: hi :)
<wingrime>
huo: 0x1620 are ?
<wingrime>
huo: 0x1619 ?
<hno>
lkcl, I am pretty much done with the board now if someone else needs it.
<mripard>
did you manage to get a Sd card booting on the A31?
<hno>
wingrime, I don't have a complete chip id table.
<drachensun>
mripard: hello, whats up?
<mnemoc>
wingrime: probably from the F serie (arm9)
<lkcl>
hno: star!
<mripard>
drachensun: fine, I'm trying to setup a proper environment to test my kernel patches for the A31 :)
<mripard>
and you?
<drachensun>
mripard: No, though I think my A31 dev kit came with a precompiled mmc for boot0/1
<lkcl>
actually yes. off to aseigo in switzerland.
<drachensun>
which I haven't tested yet
<lkcl>
hno: you'll get one just for you soon enough :)
<drachensun>
mripard: I have managed to run Linux on it
<wingrime>
hno: have you uart now?
<drachensun>
but only by flashing to the nand with phoenix
<hno>
lkcl, Yes, and I have other boards which is easier to work with for most stuff.
<mripard>
drachensun: hmmm, I see
<hno>
wingrime, on the EOMA68 yes.
<mripard>
I'd like to keep the nand as is, but it's an option
<hno>
set that up the first day I think.
<mripard>
how did you do?
<mripard>
drachensun: you nuked the buildroot environment to get it to stop at boot ?
<wingrime>
hno: cool
eebrah_ has joined #linux-sunxi
<drachensun>
mripard: no, I've got the full set of packing tools now, so I can just call './build.sh pack ' and it creates the whole image
<wingrime>
huo can dump from 0x1c0e000 to 0x1c0e100
<JonnyH>
hglm: I wish - it's a non-gpl compliant binary blob libnand.a that's linked into a module so I doubt I can just link it into the kernel
<drachensun>
mripard: it will create a Linux image as well, with the buildroot fs
<hno>
who is huo?
<drachensun>
I haven't managed to convince it to us my linaro rootfs though
vinifm has quit [Ping timeout: 256 seconds]
<lkcl>
hno: *sigh*....
<drachensun>
I think the files are too big once created
<lkcl>
anyone able to help diagnose getting hdmi up and running?
<drachensun>
mripard: what kind of kernel patches have you made?
<drachensun>
mripard: From what I can tell, the kernel is going to take a lot of work
<drachensun>
mripard: I am considering different approaches now, at the moment the stock kernel wont even run a framebuffer console without crashing the LCD driver. It will boot though and I can use it over a serial console
<hglm>
lkcl: my program only works on screen0 at the moment and doesn't support VGA or TV output. Does running a10disp info give any clues?
<lkcl>
ok i changed it to EDID 1920x1080p60
<lkcl>
hglm: it looks good. yes screen0, hdmi fine
<lkcl>
1sec...
<lkcl>
sunxi disp kernel module version is 1.0
<lkcl>
Linux info for screen 0 (/dev/fb0): size 1920 x 1080, 32 bits per pixel.
<lkcl>
Linux info for screen 0 (/dev/fb0): framebuffer size 15.82 MB.
<lkcl>
Linux info for screen 1 (/dev/fb1): size 800 x 480, 32 bits per pixel.
<lkcl>
Linux info for screen 1 (/dev/fb1): framebuffer size 5.86 MB.
<drachensun>
mripard: It seems like that was a problem for the sun4i at first too though
<lkcl>
hglm: ^
<lkcl>
Screen 0:
<lkcl>
Display dimensions are 1920 x 1080.
<lkcl>
Output type is HDMI.
<lkcl>
Framebuffer dimensions are 1920 x 1080 (7.91 MB).
<lkcl>
Framebuffer pixel format = 0x0A (32bpp).
<mripard>
drachensun: I'm far off displaying something on a screen :)
<lkcl>
Layer working mode is NORMAL.
<lkcl>
Layer source window size is 1920 x 1080.
<lkcl>
Screen 1:
<lkcl>
Layer screen window size is 1920 x 1080.
<lkcl>
Supported HDMI modes:
<lkcl>
hmmm, that's interesting - no "supported hdmi modes"....
<mripard>
drachensun: only booting will be a nice achievement for me already :)
<lkcl>
what's _that_ all about??
<drachensun>
mripard: I like the approach you are taking though. My original plan was to just tweak the kernel AW provides. Now I think all the drivers are going to need so much work it will be better to just copy the new parts over into the community 3.4 kernel
<lkcl>
hglm: should there be any "supported" modes? or am i going to need hdmi set (with "force")?
<hglm>
lkcl: Yeah, that should give list of modes supported by the monitor. Means the kernel disp driver doesn't report any mode as supported.
<drachensun>
mripard: So you are trying to integrate it with the community kernel or the latest mainline Linux?
<mripard>
latest mainline
<lkcl>
hglm: hmmm, the monitor keeps switching itself off :)
<drachensun>
wow, well that would be even better
<lkcl>
power-saving mode... 1sec...
<drachensun>
do you have a github account or anything?
<mripard>
drachensun: I have patches, a kernel image that should work, and so on
<mripard>
but I can't get to boot it :)
eebrah is now known as eebrah|away
<lkcl>
nope: still no supported modes....
<drachensun>
I can try your work out I think
<drachensun>
well its tricky
wingrime has quit [Read error: Operation timed out]
<drachensun>
all the scripts are so intertwined with each other
<lkcl>
May 17 18:43:24 localhost kernel: [ 449.200000] ParseEDID
<lkcl>
May 17 18:43:24 localhost kernel: [ 449.210000] i2c i2c-3: unable to read EDID block.
<lkcl>
interesting.....
<mripard>
drachensun: yeah, I have a hard time figuring out how the build system actually works
<mripard>
it goes into buildroot, then steps back
<mripard>
i'm not even sure boot0/boot1 is even compiled at some point
<hno>
drachensun, you need boot0 & boot1 patched with the board parameters from script.bin.
vinifm has joined #linux-sunxi
<oliv3r>
mripard: arnd only had a tiny comment, so that's good so far ;)
<lkcl>
hglm: star
<oliv3r>
mripard: especially concidering i misspelled his e-mail and he had to pick it up frmo the MLsts
<lkcl>
hglm: i have another board, it's got android, and it works fine on HDMI
<lkcl>
so i'm faaairly confident the hardware's ok :)
<hno>
wingrime: There is nothing exiting in that range on EOMA68, it's just an A10. And I don't have anything which uses VE.
<lkcl>
wingrime-android: que?
<hglm>
lkcl: screen0 looks OK, scaler mode is disabled, maybe you try enable that. And not use fb_framebuffer_size=16 in the kernel command line options.
<lkcl>
hno: que?
<lkcl>
hglm: ack
<hno>
what?
<wingrime-android>
heh
<lkcl>
<hno> wingrime: There is nothing exiting in that range on EOMA68, it's just an A10. And I don't have anything which uses VE.
<lkcl>
hno: ^
<drachensun>
hno: Ok, that would make sense, do you know if the headers need to be changed or do you think the build figures it out? There is a config in the build setup
<lkcl>
scalar mode... scalar mode....
<lkcl>
got it
<lkcl>
i'd set it to 32.... ack
<hno>
lkcl, wingrime asked to dump 0x1c0e000 to 0x1c0e100
<lkcl>
hno: ahh yeah i remember now
<lkcl>
hglm: ahh... did you mean sunxi_fb_mem_reserve=32 ?
<lkcl>
remove that, yeah?
<hno>
drachensun, I don't know what they look like on the A31. But in the A10/A13 SDKs there is tools to update the bootloaders from script.bin, run while preparing the livesuit image.
<hglm>
lkcl: yes, I meant that. But if it's 32 it should be normal. You could remove the option because 32 is the default I think.
<drachensun>
hno: Ok, that sounds about the same, I'll dig in the files and see what I can figure out
<lkcl>
hglm: ack
<hno>
drachensun, the known headers for a1x can be found in the bootinfo tool (sunxi-tools)
* lkcl
loves the way it's possible to compile stuff on the box - no more cross-compiling
* hno
don't have patience to natively build the kernel.
<lkcl>
ha ha
<lkcl>
it was fine on a quad-core exynos 4412 (1.7ghz) with 2gb RAM
sanka has joined #linux-sunxi
<hglm>
lkcl: Have you tried changing screen0_output_mode to a lower resolution that your monitor supports?
<lkcl>
hglm: not yet. let's try...
<lkcl>
root@debian:~/a10disp# !478
<lkcl>
./a10disp changehdmimodeforce 5
<lkcl>
Setting console framebuffer resolution to 1280 x 720.
<lkcl>
hglm: do you have a known-good kernel config i can compare against? (stage/sunxi-3.4 preferably)
<lkcl>
anyone else got something kicking about?
<hglm>
lkcl: Have your tried rebooting with script.bin with changed screen0_output_mode?
<hno>
lkcl, do you have any other A10 device with HDMI?
<mripard>
oliv3r: I have some comments :)
<mripard>
which Arnd should have seen
<lkcl>
hno: yes
<lkcl>
hno: sorry
<lkcl>
hglm: yes
<lkcl>
hno: no. ok, i have an identical board, with android (stock install), and that works fine
<mripard>
drachensun: yeah, I figured that out as well (you had to do make in the boot directory to actually build the bootloaders), with the same result (not booting) :)
<oliv3r>
techn__: mripard i think the A13 does not have an RTC, or was it A31? one of those anyway, A10 for sure, hence, they use an i2c device.
<hglm>
lkcl: You have tried wiggling/forcing the HDMI plug? They can be unreliable. For example on my tablet I sometimes have to apply wiggle/apply some force to my miniHDMI plug to get it recognized.
<lkcl>
ok going to try another round of kernel compile options :)
<lkcl>
hglm: eek!
<lkcl>
ok
<lkcl>
i suppose i could just try the sd/mmc card in the other board...
<drachensun>
mripard: Gotcha, I think hno is right, there is a configs directory attached, we might just need to make sure it is building with the right config file
<drachensun>
mripard: So you aren't working on the evb right? Which device do you have?
<mripard>
I am
<drachensun>
oh ok
<drachensun>
well then dont you have the pack tools?
<mripard>
(well, the a31 colombo development kit)
<drachensun>
yeah, thats the same one I have
<mripard>
well, I have already packed binaries
<drachensun>
you should be able to restore the nand easily to default
<mripard>
those binaries for boot0/boot1 start
<mripard>
but apparently, boot0 is checking right at boot for the content
<hno>
there is different boot0/boot1 for NAND or SD.
<hno>
what content?
<drachensun>
I'm just saying though, can't you pack an image with your Linux kernel to test it on nand?
<lkcl>
ok wakey wakey new board, that's up with android.... now FEL mode....
<mripard>
of the 0x1f00108 register
<mripard>
(sorry, hit enter at a very bad time)
<drachensun>
mripard yeah, how do you know boot0 is starting if you don't see any output?
<mripard>
which a general purpose register in the timer IP apparently
<mripard>
(though I have no idea what this is about)
<drachensun>
lol
<lkcl>
shit, shit - ok. that board's fine. it's the other one that has dead HDMI. *sigh*
<lkcl>
ok.
<mripard>
but I can't compile a boot0 without this check
<lkcl>
all good: thanks hglm, thanks hno.
<hglm>
gl
<lkcl>
arse.
<drachensun>
mripard: Ok, some progress at least though
<lkcl>
fucked hdmi. ah well.
<drachensun>
so you did make under boot
<mripard>
yeah
<drachensun>
and you copied the boot0mmc binary to the sd card to the same location as the old SPL went?
<mripard>
yes
<hno>
mripard, why do you need boot0 without this check?
<hno>
and easy to hexedit it away..
<mripard>
hno: I don't know what it is about really, so I just wanted to remove it, since it completely prevents the board from booting.
<mripard>
but yeah, I could go the hard way
<hno>
The only use I know of is asking to reboot into FEL.
<hno>
and there it's a once-only flag.
<hno>
that register is an RTC register and is preserved across reboot.
<hno>
completely powering off should also reset the register to 0.
<mripard>
yeah, but you need to boot using the FEL button on the A31 to boot on the SD Card
tinti has quit [Quit: Leaving]
<mripard>
so it looks pretty circular to me :)
<hno>
you are saying it gets set by using the FEL button as well? I do not think so.
<mripard>
well, I don't know if it's directly or not, but when I hold the FEL button, this register is at the 5aa... value, and when I do not, it's not
<mripard>
and I always cold boot the board, so I guess we can forget about the registers being persistent across reboots
<drachensun>
how are you getting it to try and boot that card?
<drachensun>
did you have to change a jumper or anything?
<mripard>
I hold the FEL button and power up the card
<hno>
mripard, how are you reading the register value?
<mripard>
I'm not, it's printed by boot0
<hno>
ok.
<mripard>
but in the code it's just derefencing a volatile uint pointer set to 0x1f00108
<mripard>
so even the access looks right to me
<drachensun>
hmmm I'm not see any reaction when I try to boot
<drachensun>
pack/chips/sun6i/boot/boot0_sdcard.bin is the file right?
<techn__>
lkcl: are you sure that edid pin is connected correctly?
<mripard>
no, it's the .fex file you should be booting
<drachensun>
ah
<mripard>
I'm not sure it changes anything within the file itself, but the .bin header is not right.
<techn__>
lkcl: oh.. problem solved :p
<drachensun>
mripard: Mines not giving any output when I try to boot that that fex
<mripard>
I have the same problem actually :) It's what I've been struggling with
<mripard>
while tools/pack/out/boot0_sdcard.fex should work
<mripard>
well, at least until the register reading I was mentionning
<drachensun>
I'm not getting that far
<drachensun>
so I just built it with make
<drachensun>
when I tried pack with all the options
<drachensun>
it was throwing errors
<drachensun>
so I went back to just pack
<mripard>
tools/pack/out/boot0_sdcard.fex is generated using ./build.sh pack from the lichee top directory
<mripard>
so, if you ever launched it, it should be there
<drachensun>
I was using the one in the boot directory
<drachensun>
let me try that one
<drachensun>
same thing
<drachensun>
weird
<drachensun>
you aren't on uart 1 or something like that right?
<drachensun>
its bizarre I cant get the same thing to work even to where yours is
BJfreeman has quit [Ping timeout: 256 seconds]
<oliv3r>
mripard: drachensun remember, tom wrote a few bits about A31 boot beings pecial http://linux-sunxi.org/Boot
<oliv3r>
it's not as simple as it used to be
<oliv3r>
wingrime-android: do you know what registers need to be written to to enable the VE? i can then dump those registers for you
<oliv3r>
wingrime-android: 001ce000 - 001ce140 is ALL zero
<oliv3r>
i bet it's like nand, unavailable when not powered
<mripard>
drachensun: i'm on the uart0/com1 port
<techn__>
hno: stdio.h include causes my problems
<mripard>
the closest one of the SD slot
<techn__>
hno: u-boot doesn't use stdio.h :/
<hno>
techn__, ok, makes sense.
<techn__>
hno: but who declares printf for u-boot?
<hno>
stdio.h is a bit of a beast to include.
<drachensun>
mripard: Interesting, I'm using UART0 with the USB adapter that came with the board, I wonder if different stuff would come out of the actual RS-232 port
<drachensun>
mripard: Sorry to be pain, can you paste your command to write the boot0 onto the sd card just to make sure I'm not doing something stupid when copying?
<mripard>
drachensun: I use dd if=boot/pack/out/boot0_sdcard.fex of=/dev/mmcblk0 bs=512 seek=16
<mripard>
n01: hmmm, and what do you have in your u-boot environment?
<n01>
since with 3.9.1 it works I was wandering if there is something that is changed in 3.10-rc1
<mripard>
no, nothing has changed there
<n01>
ook
<oliv3r>
dl.linux-sunxi.org/users/oliver
<n01>
tnx oliv3r
<oliv3r>
the .xz is old
<oliv3r>
the dtb, bin and kernel is what I use
<oliv3r>
so that should atleeast give you something to compare/test against
<oliv3r>
and it's 3.10 iirc
<n01>
oliv3r: yes, your uImage works
<oliv3r>
*flex*
<oliv3r>
gotta fix things though, mripard is very busy reviewing it :D
<n01>
ok there is something wrong with my kernel config
<oliv3r>
i think i have .config enabled
<oliv3r>
so you can use that as a starting point too
<oliv3r>
or compare against
<mripard>
oliv3r: as a matter of fact, I'm currently reviewing your patch :)
<oliv3r>
mripard: :D ty
tinti has quit [Remote host closed the connection]
LoCoZeNoz_ZUE has quit [Ping timeout: 248 seconds]
vinifm has joined #linux-sunxi
paulk-desktop has quit [Quit: Ex-Chat]
shineworld has quit [Quit: Leaving]
<lkcl>
techn_: yep :)
<lkcl>
1 board shagged.... whoops.
LoCoZeNoz_ZUE has joined #linux-sunxi
<oliv3r>
mripard: about the ordering, didn't realize there was any ordering :p
<oliv3r>
mripard: anyway, don't understand the 1k reservation. Because the datasheet says so?
<oliv3r>
mripard: what if the addresslines wrap much before that 1k reservation?
<oliv3r>
anybody here with a31 and uart+uboot?
<techn_>
hno: Now I got cubie to boot via usb.. but it hangs after "DRAM: 1024MB"
<techn_>
also libusb debug says "libusb usb_bulk_send error -1"
n01 has quit [Read error: Connection reset by peer]
rz2k has quit []
LoCoZeNoz_ZUE has quit [Ping timeout: 264 seconds]
sanka has quit [Quit: Leaving]
n01 has joined #linux-sunxi
<oliv3r>
mripard: though you are right about sun6i, A31 doesn't seem to have that register, well the code works differently, but need someone with A31 to confirm
<mripard>
oliv3r: well, you'll map more address space, and that's all
<mripard>
and actually, that won't change anything
<mripard>
since the page size on linux is 4k, and the kernel only maps whole pages
LoCoZeNoz_ZUE has joined #linux-sunxi
<oliv3r>
ok, so map 1k then
<oliv3r>
but where do you obtain this information from?
<mripard>
the user manual
<oliv3r>
hmm
<mripard>
Architecture -> Memory Mapping
<oliv3r>
so we do rely on that bit of the user manual? (which officially we dont' have?)
<mripard>
Page 31 in the A10
<oliv3r>
ok i'll adjust it to that then :p
<mripard>
well, we do have it officially.
<oliv3r>
for A10 i think it still hasn't been approved
<oliv3r>
the A13 one has been 'okayed'
<oliv3r>
but it's changed :)
<mripard>
Allwinner sent me both the A10 and the A13 user manual saying it was ok to share them.
<oliv3r>
ohh, so they both sanctioned; that's really good to know
<mripard>
so, I guess we have them officially :)
<oliv3r>
as for the PAGE_SIZE relation, i think buf passed from .read is always max page_size
<mripard>
citation needed
<mripard>
and still
<mripard>
why would you do an error on that?
<oliv3r>
but does that influence that?
<oliv3r>
i wasn't sure
<mripard>
nope
<mripard>
you can allocate up to 512 pages with the regular kernel allocators.
<oliv3r>
but i think from my first tests today, i noticed the higer level devides it up in chunks that fit anyway
<oliv3r>
so if I request 2x page_size via .read
<mripard>
again, show me the code
<oliv3r>
the layer higher, cuts it up in sizes that fit, so that error can go I thin
<oliv3r>
but i wasn't sure :)
<mripard>
you're still assuming :)
<hno>
techn_, yes I noticed. Fixed now.
<hno>
mripard, which versions of the A10 & A13 manuals do you have?
<oliv3r>
mripard: i was hopping the review would point it out, and i kinda had forgotten abou thtat bit :p