hno changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See | | Logs at
<Turl> leowt: try rebooting the tablet after enablingit
<leowt> Turl: already tried
<leowt> tomorrow i will open it up to see if i can locate uart
leowt has quit [Quit: leowt]
\\Mr_C\\ has joined #linux-sunxi
_BJfreeman has joined #linux-sunxi
BJfreeman is now known as Guest41456
_BJfreeman is now known as BJfreeman
rzk has joined #linux-sunxi
Guest41456 has quit [Ping timeout: 252 seconds]
rz2k has quit [Ping timeout: 264 seconds]
BJfreeman has quit [Quit: had a good time]
tinti has quit [Quit: Leaving]
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
rzk has quit [Read error: Connection reset by peer]
<piyushverma> any idea in uboot where can modify DRAM parameter in UBOOT branch lichee-dev
<piyushverma> lichee-dev because I am building for nand-flash
n01|away is now known as n01
<hno> piyushverma, lichee-dev u-boot do not touch DRAM parameters. It's all sett by boot0/boot1 based on the parameters set in the fex file when you prepare the image.
<hno> + autodetect by livesuit for parameters which are left blank.
<piyushverma> hno: thanks
<piyushverma> I am not using livesuite
<piyushverma> I was trying to flash manually
<piyushverma> it have early android then follow
<piyushverma> Installing to nand section
<piyushverma> I also update script.bin file but changes in script.bin have no effect
<piyushverma> so where does boot0/boot1 reside
<piyushverma> and how to update is for NAND
<hno> only reliable method for updating boot0/boot1 is using livesuit.
<hno> there is MTD support coming which will replace boot0/boot1 by u-boot SPL on nand as well, but it is not 100% ready yet.
<piyushverma> ok so must to make livesuite image
<hno> for updating boot0/boot1 yes. Then you can use Linux to rewrite all the rest as you please. Livesuit is not so good at flashing Linux images (stupid partition size limitation)
<piyushverma> right partition issue
<piyushverma> one idea if we flash android and take backup of nand with dd if=/dev/nand of=nandbak bs=1024K count=16*1024
<piyushverma> should copy all boot0/boot1 value
<hno> boot0/boot1 is in raw nand, outside what you can access via the virtual /dev/nand block device.
<oliv3r> mornin' yall
<hno> morning oliv3r
<piyushverma> hacking nand driver wont be easy ?
<piyushverma> create some another node like nandraw in dev
eebrah|away is now known as eebrah
rellla has joined #linux-sunxi
gzamboni has joined #linux-sunxi
cnf has joined #linux-sunxi
<rm> 1366 x 768 13.3 inch 6000mAH
<piyushverma> hno: Interesting
<piyushverma> I flash Android 4 where it show 1GB RAM
<piyushverma> then replay uboot and kernel and rootfs it change to 512MB
<piyushverma> so it must be in UBOOT
<piyushverma> how come it change from 1GB to 512MB ?
<piyushverma> rm: it would be batter if A20 or A31
<hno> piyushverma, Allwinner u-boot always says 512MB. You should looks at what the kernel says.
<hno> the output from boot1 is also reliable.
<piyushverma> I use free function to test after boot
<hno> what Android 4 image did you flash?
<piyushverma> from hackberry
<piyushverma> and tested before flashing
<piyushverma> using RS232 busybox top
<piyushverma> it show 800 something mb
<hno> I would guess that image is for 512MB. Check the script.bin.
<hno> Note: does not help to just update script.bin and repack. The boo0 & boot1 headers also need updating.
<oliv3r> bah, was so busy with 'life' stuff yesterday, I forgot all i wanted todo wednesday/today :S
Guest99492 is now known as zumbi
<oliv3r> submit patch was #1; but after that things got blurry
<hno> heh, had a good day yesterday?
<piyushverma> hno: I will flash android 4 again and chk
<piyushverma> give me 5 min
<oliv3r> hno: just busy, grocery shopping, getting stuff done, couldn't mow the lawn, it started to rain
<oliv3r> just 'stuff' :)
<oliv3r> i know i wanted to do something u-boot-y
<oliv3r> oh yeah, fixup patch
<oliv3r> and cleanup patch
* hno is attempting to use the marvell i2c driver.. hangs nicely so far.
<oliv3r> in u-boot?
<oliv3r> or kernel one
<piyushverma> you are right
<piyushverma> hno: script.bin say 512 ram
<piyushverma> but how android get 1024 ram
<oliv3r> the linux kernel ingnores that and detects it as it should
<oliv3r> script.bin dram_para i think is completly useless
<piyushverma> oliv3r: I want to get 1GB ram with Nand boot
<piyushverma> if I boot though sd then can get 1024 but same can't do with nand
<piyushverma> to build uboot for nand I use lichee-dev branch to build uboot for sd I use sunxi branch
paulk-desktop has joined #linux-sunxi
<piyushverma> any suggestion how to get that ?
<piyushverma> by the way rootfs is debian
<oliv3r> piyushverma: kernel will always detect the correct size
<oliv3r> ignore what boot0/1/u-boot say
<oliv3r> unless t hey pass the mem= parameter, linux should try to correctly determine the amount of ram
<oliv3r> otherwise, try to pass mem=1024
<piyushverma> oliv3r: but after boot debian show only 512 mb ram
<oliv3r> what does /proc/cmdline say
<hno> piyushverma, you NEED to use the right script.bin when building the Android image.
<oliv3r> hno: does the kernel not detect the correct memory size?
<hno> oliv3r, the kernel relies on the bootloader to configure DRAM controller correctly.
<hno> it then detects how much DRAM the DRAM controller is configured to access.
<oliv3r> hno: ah, didn't know that. probably because on x86 it usually just works :)
<oliv3r> ah, so it does work, but if the dram controller is setup wrong (size) then the kernel will find that size
<oliv3r> makes sense
<hno> oliv3r, you have a gigantic SPL called BIOS.
<hno> on x86.
<piyushverma> hno: I did not build android
<piyushverma> it's official hackberry image
<piyushverma> which when I flash it get 1024 RAM in android
<piyushverma> but script.bin show only 512
Quarx has joined #linux-sunxi
<piyushverma> so it not reply on script.bin as oliv3r said
<piyushverma> but on same installation
<piyushverma> I update uboot and kernel
<piyushverma> repartition nand to only 2 partetion using nandpart
<piyushverma> and flash deb rootfs
<oliv3r> piyushverma: the KERNEL will detect the ram correctly from the dram controller. But if your dram controller is setup incorrectly, the kernel will detect that
<piyushverma> all work as documented
<oliv3r> so it looks like your dram controller is not setup correctly
<piyushverma> but ram only 512
<hno> piyushverma, can't explain why that android works. Maybe someone replaced script.bin after the image was built.
<oliv3r> hno: quite common for android magicitians to mess around with things
<hno> yes
<piyushverma> hno: as boot0,boot1 reside out of virtual nand
<piyushverma> so it's same
<hno> true
<piyushverma> but after boot 2 os different
<piyushverma> can we force it some where in kernel
<oliv3r> piyushverma: double check your script.bin?
<piyushverma> yes already did
<hno> piyushverma, what memory size do boot1 report?
<piyushverma> hno : how to chk
<oliv3r> piyushverma: serial console
<piyushverma> aah u mean while booting
<oliv3r> piyushverma: yeah
<hno> meant boot0 actually.. third line of output after poweron.
<hno> HELLO! BOOT0 is starting!
<hno> boot0 version : 1.5.0
<hno> dram size =1024
<hno> is what it should say on a 1GB board.
<piyushverma> hno: 1 min
<piyushverma> wonder dram size = 512
<piyushverma> hello! boot0 is starting
<piyushverma> boot0 version: .2.2
<oliv3r> hno: the 'asm/io.h use linux/io.h' warning can be ignored for u-boot right? or does u-boot have a generic io to include?
<rellla> oliv3r: you got right btw :( no answer from aw since a month. wrote another last request ...
<oliv3r> rellla: hahah; sucks to be right
<rellla> *last* btw ;)
<oliv3r> rellla: but lkcl has been busy in that regard too, maybe he can pry some stuff out
<oliv3r> rellla: dunno if you read any mailing lists (arm-netbook)
<hno> oliv3r, u-boot uses asm/io.h
<rellla> lkcl is kind of more "aggressive" with them ;)
<oliv3r> hno: just double checking
<oliv3r> rellla: nah, he is aggressive to his 'associates'
<hno> I think he is quite aggressive to AW too.. but it's not him talking to the board of directors.
<rellla> oliv3r: yes i read it, is it the getting AW SoC upstream discussion? i did not completely backread it, because i was away a few days...
<hno> Aha.. i2c_init_board is not at all supposed to do what the name suggests... not even called. No wonder it doesn't work.
<piyushverma> so is there any way to force kernle to take 1024 Ram ?
<piyushverma> or access those restricted area with sepcial nand driver
<piyushverma> it's porblem of all linux and really big issue
<hno> piyushverma, making the kernel assume 1024MB of ram with the DRAM controller configured to manage 512MB isn't very wise.
<piyushverma> might be parameterise it
<piyushverma> with bootargs uboot or bootcmd
<hno> The kernel do not reconfigure the controller.
<hno> You can safely do the other way around, forcing the kernel to use less memory than the DRAM Controller is configured to manage.
vicenteH has joined #linux-sunxi
<hno> as oliv3r said, you override the detected memory size by using mem= kernel command line option, but using it with a larger size than the hardware is configured for is not a supported usage.
<hno> make yourself a image with proper DRAM configuration to flash to NAND. It's as simple as not specifying the size at all and let livesuit detect what ram you have.
<hno> no size, no density, etc...
<piyushverma> ok
<piyushverma> last time I try livesuit but also have issue it did not work for me.
<oliv3r> rellla: that discussion was stupid and pointless. we have upstream support, luke didn't know about it, he made a donkey out of himself :) but what came from it is good. luke is rounding up information what we want/need from AW. Documentation, source for the kernel (the missing bits) and source for cedarX stood high on the list
<piyushverma> any way will try again
<oliv3r> piyushverma: something or someone broke your boot0/1 it seems, so you have to fix it unfortunatly
<piyushverma> oliv3r: yes that can fix by reflashing
<piyushverma> I am doing some more testing latter will come up with results
_BJFreeman has joined #linux-sunxi
notmart has joined #linux-sunxi
notmart has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
Quarx has quit []
hansg has joined #linux-sunxi
_BJFreeman has joined #linux-sunxi
eebrah is now known as eebrah|away
BJfreeman is now known as Guest531
_BJFreeman is now known as BJfreeman
Guest531 has quit [Ping timeout: 252 seconds]
<hno> mripard, looking at u-boot i2c I find more small differences from mwtwsi. reset needs to be set high and wait until low.
hansg has quit [Quit: Leaving]
<oliv3r> hno: because according to the usermanual, bit 2 is 'reserved'
<oliv3r> well a10 manual; checking a13 right now
JCQ_W has quit [Read error: Operation timed out]
<rellla> oliv3r: thanks for the summary! interesting ...
<mripard> hno: ah, right.
<mripard> I'll try to find a marvell datasheet next week at the office to try to catch all differences
<oliv3r> mripard: i think there was some thought that it was 'some other IP'; check irclog for 'pdf'
<oliv3r> hno: could it be that that 2 should be a 3?
<mripard> oliv3r: yes, inventra mi2c from mentor
<oliv3r> nono
<mripard> the shibridge thing?
<oliv3r> yeha
<oliv3r> that's the one
<oliv3r> was trying to find it again, but can't search for 2 letters :S
<mripard> yes, given that it's indian based, and that their product datasheet is the exact same one that the one from mentor, except for the footer and header, I guess one is a copy of the other
<oliv3r> sibridge* :)
<oliv3r> yeah; guess we'll never find out who wrote what
<oliv3r> :D
<oliv3r> this only shows the need for more vhdl designs on opencores
<oliv3r> but that battle is for when we won the software side of things :)
BJfreeman has quit [Quit: had a good time]
<oliv3r> bah, i broke my u-boot build
<oliv3r> and I might have possibly pushed it to hno
<oliv3r> uh oh
<oliv3r> hno: I did, i broke the build. I commit it with my fix patch
focus has quit [Remote host closed the connection]
focus has joined #linux-sunxi
ssvb_ has quit [Ping timeout: 256 seconds]
Yaku321 has joined #linux-sunxi
n01 has quit [Ping timeout: 248 seconds]
ssvb_ has joined #linux-sunxi
<oliv3r> hno: omg why is the netblock camelcased :S
\\Mr_C\\ has quit []
rellla has quit [Quit: Nettalk6 -]
<hno> oliv3r, I haven't merged your changes yet.
<hno> oliv3r, A10 watchdog manual is incomplete and full or errors.
<oliv3r> hno: well a10 and a13 both list bit 2 to be 'reserved' bits 3:6 are specifically for setting the interval
ganbold_ has joined #linux-sunxi
<oliv3r> which are 4 bits, and that matches the table from both manuals and what carlo did
<oliv3r> hno: you merged my a20 v2 patch; which breaks a10 mmc :)
<oliv3r> i fixed it locally allready
<oliv3r> i'll push a set soon
<hno> Ok, that's in the A20 tree only so no worries yet :)
<oliv3r> yeah i'll undo it
<oliv3r> will you 'squash' any of those btw before merging?
<hno> Ok, I see what you mean wrt the watchdog. I include bit #2 in the watchdog value but don't know if that is correct. Was written before we had the user manual.
<oliv3r> ok i changed it allready
<oliv3r> with a small wdt patch
<oliv3r> expect about 4 patches or so in an hour or two
<hno> what do the A10 manual say?
<hno> err, A13.
<oliv3r> both the same
<oliv3r> bit 2 is reserved; bit 3:6 is for the interval value
<hno> Annoying... mvtwi.c do work, but only when I have added debugging that printf every readl/writel call (a #define to redefine __arch_getl/putl). Without it it hangs.. and there is no unbounded loops in that code anywhere.
<oliv3r> :S
<hno> Some odd timinig issue I think.
<oliv3r> yeah must be
<oliv3r> hno: why did you do this: if (interval > (1 << 6) - 1)
<oliv3r> you only check the biggest counter bit
<oliv3r> if it where 0b1111 << 6 I'd understand your checkinf for overflow
<hno> where?
<hno> And it is if interval > 0b11111
<hno> (1 << 6) - 1 == 0b11111
<oliv3r> a -1 yeah
<oliv3r> aynway, the highest wdt value is either 0b1111 or 0b1011 actually
<oliv3r> 0b1011 is 16 seconds; after that is undefined
<hno> that code uses 5 bits for the interval (see above)
<oliv3r> so if time > 16 secs; time = 16 secs;
<oliv3r> ok if I change that too?
<hno> If you change the width of the interval field then that condiiton also needs changing.
<oliv3r> well it is a little more subtle
<oliv3r> we have 4 bits for the interval
<hno> should perhaps add a tanle with actual times..
<oliv3r> but the interval value maxes out at 0b1011
<oliv3r> i'll borrow the table for carlo's work
<hno> I know. As I said this code was written without access to the user manual, only based on the reset code and experiments.
<oliv3r> oki; i'll try to fix it up then :)
vicenteH has quit [Ping timeout: 240 seconds]
n01 has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
tinti has joined #linux-sunxi
<oliv3r> hno: did do_sunxi_watchdog_timer() work?
<oliv3r> it writes 0 to the entire watchdog, interval is reset to 0 (ok no problem), the reset is disabled (not good I think?)
<oliv3r> well in the write after you re-enable everything again; so it's ok i guess
<oliv3r> nvm then :)
dl9pf has quit [Read error: Operation timed out]
dl9pf has joined #linux-sunxi
dl9pf has joined #linux-sunxi
<oliv3r> hmm, trying to write the wdt registers has no effect, it doesn't restart :(
<oliv3r> (on my cubie a10)
<oliv3r> ah works if i 'arm'it
<oliv3r> so it looks like you have to 'reset' (e.g. ping) the wdt atleast once for it to activate
<oliv3r> so setting up a wdt without actually 'pinging' it doesn't do anything :)
<oliv3r> kinda makes sense
<oliv3r> you dn't want a reboot loop just because your system hasn't started the software side of things yet
rellla has joined #linux-sunxi
vicenteH has joined #linux-sunxi
<Turl> woot, I got my A10S :)
<hno> Turl, nice
<Turl> hno: what's the difference between boot/rec button and uboot/rec jumper?
<hno> oliv3r, that code is from before we knew how to use the control register. So it disables the watchdog then enables it again. But it does not work. Should really use the watchdog functions.
<hno> haven't looked at that since I have no plans on submitting it upstream in that form.
<hno> Turl, the jumper selects the function of the button.
<hno> don't remember how the recovery function is wired. See schematics.
<Turl> hno: rec means FEL right?
rellla has quit [Remote host closed the connection]
rellla has joined #linux-sunxi
<hno> UBOOT means FEL.
<hno> USB-BOOT
<hno> the Allwinner pin name is UBOOT
<hno> Can't find what the recovery mode is wired to.
<hno> Found it. GPIO PG2.
<hno> Hm.. chip pin names mentions GPS signals on those pins. Do the A10S have the GPS baseband like A10?
rellla has quit [Remote host closed the connection]
rellla has joined #linux-sunxi
<hno> Turl, UBOOT is FEL mode. RECOVERY is GPIO on PG2.
Yaku321 has quit [Disconnected by services]
Yaku-noob has joined #linux-sunxi
<Turl> hno: hm, ok
rellla has quit [Ping timeout: 264 seconds]
<hno> Turl, there is also a solder jumper to enable FEL mode booting on the LRADC keys at the edge.
<Turl> hno: do you know the uart pin order so I don't have to go trial and error?
rellla has joined #linux-sunxi
<hno> It's printed on the PCB. See backside.
<Turl> oh, great
<hno> The A10s is one of the most friendly boards. Only missing a zener diode on UART0 RX pin....
<oliv3r> Turl: nice one! now a20 :)
<hno> oliv3r, probabl some old experiment to try to figure out why writing to the watchdog mode register seemuingly have no effect...
<oliv3r> a20 has it printed from AND back
<oliv3r> ok i'll delete it then
<Turl> hno: hm, I get garbage on 115200bps
<hno> just ignore cmd_watchdog. Should just be a call to watchdog_set(timeout)
<oliv3r> hno: allready did that :)
<oliv3r> hno: atm just not sure if watchdog_reset(); should be called at the end of watchdog_set()
<oliv3r> i'll leave it for now
<hno> It should. It is what activates the new timeout.
<oliv3r> well the 'reset' also 'pings' the wdt; how does u-boot handle that? resetting periodically i mean
<oliv3r> i see some references to hw_wdt_reset();
<Turl> hm, green is not ground
<Turl> confusing cable coloring
<oliv3r> did you get a cable with yours?
<oliv3r> i only have 1 to share with cubie/a20
<hno> oliv3r, rename it to watchdog_ping() / reload /rearm /whatever and code makes more sense.
<Turl> oliv3r: yes, I asked for it when tsvetan said if I needed anything else :)
<oliv3r> hno rearm i like petter, ping is what we use in upstream
<oliv3r> Turl: lucky you
<hno> oliv3r, right.. now I remember why it's watchdog_reset. u-boot periodically calls this is watchdog is enabled.
<hno> If you rename it then you also need to define WATCHDOG_RESET to the new name.
<oliv3r> ah, captial
<oliv3r> though I think we don't use that yet
<hno> but you'll notice that when trying to compile after rename...
<hno> u-boot uses WATCHDOG_RESET at a number of critical places.
<hno> command promt, file I/O, and a some places more.
<oliv3r> okay
<oliv3r> i also see they call hw_watchdog_init(); and hw_watchdog_reset();
<oliv3r> so probably it has to be packed into that; i'll read more into it
<oliv3r> means i'll send those patches I promissed earlier later :)
<oliv3r> since this costs more work then I anticipated :)
<hno> No hurry.
<oliv3r> oh there's also a 'new approach
<oliv3r> using watchdog_register();
<oliv3r> i'll use that
<oliv3r> i'll add watchdog.c for it then
<hno> You better leave it as watchdog_reset(). Renaming it is non-trivial, needs both C and assembly versions of the #define.
<hno> and not done by a single other board.
<oliv3r> yeah i agree
<Turl> hm, I somehow forgot I needed an USB cable for FEL
<oliv3r> but i think it'll be completly rewritten as it'll move to drivers/watchdog/sunxi_wdt.c
<hno> Turl, done the same a couple of times.. very confusing.
<oliv3r> Turl: make sure you don't use a broken cable :p
<hno> oliv3r, had it in drivers/ for a while, but moved back as CPU reset code depends on it.
<n01> uhm, rewriting my wdt driver?
<oliv3r> n01: you wrote a u-boot wdt?
<hno> n01, no, my old one in u-boot.
<n01> ohhh u-boot
<n01> sorry :/
<oliv3r> hno: hmm, that's a fair reason to keep it in arch then
<oliv3r> since we can't call drivers from arch?
<oliv3r> i wonder how the new framework deals with setup of the wdt
<oliv3r> since they only have init(void) and reset(void)
<oliv3r> gotta do some reading then :)
<Turl> hno, oliv3r
<oliv3r> ok absolutly nobody uses the new driver model yet
<oliv3r> challange accepted
<oliv3r> slapin_n1: that's not mtd hacking! :p jk jk looks awesome
<Turl> slapin_n1: nice!
<oliv3r> Turl: mmc rescan
<oliv3r> :p
<Turl> oliv3r: I need to buy a new SD
<hno> Turl, nand u-boot needs "mmc rescan" before it can access the SD card. Haven't looked into why yet.
<hno> same when you SPL boot via NAND boot1.
<hno> same when you SPL boot via NAND boot1.
<Turl> hno: yeah but I didn't have any sd in there, so the error would be expected
\\Mr_C\\ has quit []
tzafrir has quit [Ping timeout: 260 seconds]
uwe_ has joined #linux-sunxi
tzafrir has joined #linux-sunxi
<Turl> mripard: ping
<mripard> Turl: pong
<Turl> mripard: I'm having trouble building the pinctrl irq stuff, I suspect mismerge, possibly on my side
<Turl> SUNXI_FUNCTION_IRQ is not defined anywhere
<mripard> it's defined in patch 2/4
<mripard> well, at least, it's supposed to :)
<Turl> yeah mine doesn't have it
bfree has quit [Quit: Konversation terminated!]
focus has quit [Remote host closed the connection]
bfree has joined #linux-sunxi
<mripard> Turl: it's in my sunxi-next branch if you want
<Turl> mripard: patch -p1 happily forgets about it or something
\\Mr_C\\ has joined #linux-sunxi
<Turl> and git am clashes with something else and doesn't want to apply it
<mripard> git am -3 ?
<Turl> mripard: doesn't work either
<mripard> yeah, but you should have the conflicting areas at least
<Turl> dev_err(&pdev->dev, "failed to remove gpio chip\n");
<Turl> =======
<Turl> dev_err(&pdev->dev, "Couldn't remove gpiochip\n");
<Turl> that's the conflict
<Turl> I never found out where it originated
<mripard> weird
<mripard> I add no problems applying them here
FunkyPenguin has quit [Ping timeout: 256 seconds]
_whitelogger_ has joined #linux-sunxi
FunkyPenguin has joined #linux-sunxi
Turl has joined #linux-sunxi
Turl has quit [Changing host]
Turl has joined #linux-sunxi
rellla has quit [Quit: Nettalk6 -]
libv has quit [Write error: Broken pipe]
<Turl> my connection to freenode broke
<Turl> mripard: :)
<mripard> aaah, damn
<mripard> I *always* forget this Makefile :)
<mripard> anyway, they've not been merged yet, so feel free to reply to the patches
<Turl> I need to boot my A10S first
mdp has quit [Excess Flood]
<Turl> mripard: so far not much luck
mdp has joined #linux-sunxi
wingrime has joined #linux-sunxi
<Turl> ok, I was loading to the wrong place :)
<Turl> works now
libv has joined #linux-sunxi
rm has joined #linux-sunxi
<Turl> mripard: what about naming the led something other than 'power'?
<Turl> it confused me at first, I thought it was the red one
derethor has joined #linux-sunxi
<derethor> hello
<derethor> i am thinking in a new devel board
<derethor> connecting a FPGA to the A13
<derethor> and I am thinking about mapping the sdram bank to the FPGA
<derethor> and then, using /dev/mem to access the FPGA
<derethor> but I am looking how to mark the ram block as a device on the linux kernel
<mripard> Turl: how would you name it?
<derethor> could anyone help me with this? which files shuld I read?
<Turl> mripard: I would go with "green" as on cubieboard
<Turl> mripard: and maybe make it heartbeat to keep consistency :)
<mripard> derethor: I'm not much into all this FPGA things, but you'll need a different driver for your FPGA I think. And then, you can allocate the memory you need with CMA, and use mmap from userspace to access it
<mripard> I know some people use uio as well
_BJFreeman has joined #linux-sunxi
<mripard> Turl: consistent with what?
_BJFreeman is now known as BJfreeman
<Turl> mripard: cubieboard's green led heartbeats
<Turl> mripard: personal preference though, we already have a red led that indicates power on, I find it more useful if it heartbeats so I know if it is working or it crashed or something
<Turl> don't worry much about it if you don't like heartbeating leds :)
<mripard> hmmmm, I don't care about heartbeating LED, what I don't really like though is having the trigger in the DT
<mripard> the label isn't quite great either
<hno> derethor, so you plan on adding an SDRAM DDR2 interface to your FPGA design making it emulate an SDRAM DDR2 chip?
<Turl> mripard: yeah, but so is default-state if you think of it
<mripard> Turl: not really
<mripard> default-state is the state of the LED before Linux starts
<Turl> mripard: does uboot turn it on? I haven't paid attention
<hno> have been adding LED support to many boards.
<Turl> oh, it does
<Turl> hno: :)
<derethor> hno: yes
<derethor> something like that
<derethor> like a very fast bus
<derethor> where is the sdram controller in the kernel source?
<derethor> well, i am only researching the idea...
<mripard> Turl: so yeah, default-state is still some kind of hardware state, while the chosen for a LED is really a configuration decision
<Turl> mripard: yeah, let's change just the name then :)
<hno> derethor, the kernel don't know a shit about the SDRAM controller. It just accesses the SDRAM.
<hno> derethor, have you done any DDR SDRAM stuff before?
n01 is now known as n01|away
<hno> And do you plan on having any actual SDRAM at the same time, or everything via the FPGA?
<hno> because the A13 is quite limited in what SDRAM configurations it can support...
<derethor> it did only things with the FPGA itself.. the spartan6 has a sdram chip
<derethor> i meant, a sdram itnerface
<hno> to act as an sdram controller or an sdram chip?
<derethor> the thing is, I can connect the fpga to the sdram bank of the A13
<derethor> and I know the base address
<derethor> but, how can I prevent process to do not use that range of memory?
<hno> That's easy. Just tell u-boot and the kernel not to.
<derethor> my idea is to declare that range as a device , maybe, in arch/arm/plat-sunxi/devices.c
<derethor> oh, the uboot, didnt think about it
<hno> I am not so worried about the software side of things. That will work if you manage to get the elecrtical side working right.
<derethor> it will be fun to implement :)
<hno> and I have to say that I am a bit worried if you plan on having the FPGA and actual SDRAM chips on the same bus. Maybe not so worried if you plan on routing actual SDRAM access via the FPGA.
<derethor> AFAIK, the a13 has two sdram banks
<derethor> so, one will be for the ddr chiop, and the other for the fpga
<derethor> so, the A13 will have 256mb of usable memory
<derethor> this is my theory, at the moment... i am rearching all of this
<derethor> where can I tell the kernl to do not use a range of memory? it is a kernel boot parameter?
<hno> They are both on the same bus.
<derethor> the A13 will interact with the FPGA lilke another sdram chip... sending address and reading data with the standard control signals... i guess that it is not a problem. it will be slower, that is for sure, and maybe there are some clocking issues
<derethor> so, the ddr range is DDR-II/DDR-III 0x4000 0000---0xBFFF FFFF
<derethor> do you know the kernel parameters to mark a region as not usable or to become a device? maybe some docs?
mdp is now known as mdp__
Yaku-noob has quit [Read error: Connection reset by peer]
mdp__ is now known as mdp
<hno> derethor, mem=
<hno> derethor, A13 only have a single set of SDRAM timing parameters
<derethor> mripard: thank you for the hint with the CMA... i found the patch, and will read linux/arch/arm/mm/init.c more carefully
<derethor> hno: oh, didnt know that, I will read more on that, maybe it is not compatible or something :/
<derethor> hno: thank you, there is also a memmap= parameter (i didnt know that)
<hno> derethor, I am not very worried about the memory region reservation. That's utterly trivial compared to getting the DDR2/DDR3 signal routing correct.
<hno> If you plan on running the SDRAM bus at normal speed then we talk about 400MHz signals.
<hno> But I guess you could clock things down considerably.
<derethor> there are 3 banks, not 2
<derethor> where are those banks assigned? how can I say to the kernel that one range of memory will go to one bank or to another? or that is "automatic" ?
<hno> derethor, there is two SDRAM CE lines. And 3 bits bank-select within the selected chip.
<hno> not sure what you mean by 3 banks.
<hno> two SDRAM CS lines I meant.
lkcl has quit [Ping timeout: 256 seconds]
<derethor> right, two chip select
<derethor> i guess, ddr3_dm0/1
<derethor> but docs are not very clear
<derethor> i will check the cubieboard and olinuxino schematics
<hno> aha... seems SPL initializaiton order is wrong.. udelay() hangs.
tavish has left #linux-sunxi ["Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is"]
<oliv3r> hno: you found a bug where
rz2k has joined #linux-sunxi
<hno> oliv3r, our u-boot SPL. Need to initialise the timers much earlier so drivers can use udelay().
<hno> hmm.. wonder if it's initialized at all in SPL....
<oliv3r> good question :D
<hno> seems not.
<oliv3r> hno: does _any_ driver that you know of use the new _device_register scheme of u-boot?
<oliv3r> i only find info in the UDM_ docs
<oliv3r> i odn't even see the actual framework implemented yet :S
<hno> I don't think it is..
<oliv3r> me neither
<hno> Works!
<oliv3r> yay! what works? :p
<oliv3r> i2c or spl boot
<hno> SPL with mvtwsi.c instead of my sunxi-i2c driver.
<oliv3r> ah the timing issue you had
<hno> yes
<oliv3r> because timers weren't init at all
<hno> yes, as soon as it tried to be kind and sleep a little with udelay() it hang. With the low level debug output it the controller could always catch up first so driver never slept..
<oliv3r> btw, watchdog_reset and watchdog_init where wrong names; that inidicates software watchdog, should have been hw_watchdog_reset i think
<oliv3r> ah, ok that's a lucky catch then
<hno> Implementations is not consistent on watchdog_.. or hw_watchdog_. not even sure why there is a separation as you can only have one.
<oliv3r> the doc says, hw_watchdog is a hardware watchdog; watchdog_ should be a sw one
<oliv3r> i guess if the hardware doesn't actually have one and you fake it with timers or nearly purely in software
<hno> When using a watchdog circuitry external to the used
<hno> specific code for the "hw_watchdog_reset" function.
<hno> SoC, then define this variable and provide board
<oliv3r> hmm
<hno> and lots of talk about SoC specific code in CONFIG_WATCHDOG.
<oliv3r> U-Boot currently implements an API for HW watchdog devices as explicit drivers
<oliv3r> in drivers/watchdog directory. There are also drivers for both hardware and
<oliv3r> software watchdog on particular CPUs implemented in arch/*/cpu/*/cpu.c. There
<oliv3r> are macros in include/watchdog.h that selects between SW and HW watchdog and
<oliv3r> assembly SW implementation.
<oliv3r> it's a bit of a mess, because the blackfin and imx watchdogs live in drivers/* as hw_watchdogs
n01 has joined #linux-sunxi
<hno> oliv3r, and there really is no difference in API between the two. Just a bunch of defines that select hw_ or no hw_...
<hno> and you can't have both.
<oliv3r> yeah
<oliv3r> strange still
<oliv3r> in the makefile, I put anything we need in CONFIG_SPL_BUILD; otherwise just above, correct? Since I don't want the wdt in SPL (do we want it in spl?) we put it above?
<hno> Not entirely sure why we want wdt support in u-boot to be honest.
<oliv3r> reset the cpu?
<hno> yes, but apart from that.
<oliv3r> feature completness :)
<oliv3r> you don't know the industrial requirements for some though
<oliv3r> u-boot supports it, so having it just to be feature complete isn't a bad thing (tm)
<hno> to be useful we really need some mechanism to detect that the wdt have fired.
<oliv3r> you mean after reboot?
<hno> Yes.
<oliv3r> the sid would have been usefull for that :D
<oliv3r> but we don't have any nvram or anything for it
<hno> there is registers both in the RTC and in AXP that can be used for that.
<oliv3r> ah yeah
<oliv3r> well we don't always have AXP
<oliv3r> so RTC would be the one
<Turl> oliv3r: can't you use normal ram?
<oliv3r> Turl: what do you mean/
<Turl> sun5i doesn't have rtc though
<Turl> oliv3r: keep a bit on memory stuffed with 0xdeadbeef
<oliv3r> Turl: so what happens after reboot?
<Turl> oliv3r: so if you boot and it's there it means it's a hot boot, and if you combine that with clearing it on normal reboot you can detect watchdog reboot
<oliv3r> Turl: how does the memory survive reboot?
<Turl> oliv3r: as long as you don't reclock it it will survive, won't it?
<oliv3r> Turl: i don't think so
<oliv3r> Turl: a) you always clock it
<Turl> well, let's try
<oliv3r> lol
<Turl> oliv3r: what's the tool to write memory on uboot?
<oliv3r> well pretty easy test, check memory after reboot
<oliv3r> mw
<oliv3r> and display is md
<oliv3r> so anything you write to 0x40000000 should survive
<oliv3r> but that's a big guess imo
<oliv3r> risk*
* rz2k got A20-olinuxino
<derethor> there are some refresh things, right? maybe the reboot will turn off the sdram
<Turl> hm where's the watchdog command
<rz2k> what u-boot/kernel I should use to get linaro around?
<Turl> hno: did it get removed?
<rz2k> (if thats possible :p)
<oliv3r> rz2k: there's a working cubieboard image available
<oliv3r> Turl: 'reset'
<oliv3r> Turl: it's broken, that's why i'm fixing it
<Turl> oliv3r: on my ancient uboot I can 'watchdog N' and it works
<oliv3r> Turl: i think it got removed because it was broken
<oliv3r> hno told me earlier that it was written ebfore we had docs, so there's some errors in it
<hno> oliv3r, A13 do not have an RTC...
<oliv3r> hno: yeah :p
jabjoe1 has joined #linux-sunxi
<hno> SDRAM do not surive reboot in a healthy state.
<Turl> hno: ^
<oliv3r> you are playing with fire.
<hno> Turl, yes, but if you look over a larger area you'll notice it's not healthy.
<Turl> hno: how large?
<hno> I don't remember. I looked into trying to recover console crash logs some year ago, but had to drop it as there was too much dataloss.
<hno> kernel crash logs.
<derethor> i read a paper on security, that they can get your memory rebooting computers almost frozen (i mean, below zero dree celsius), so, memory stays,and they can boot again, and read the chip
<hno> It's probably also dependent on the refresh timing requirements of the SDRAM chips. The SDRAM controller stops at reset, and then again during SDRAM configuration.
<Turl> look healthy to me
<derethor> so, i guess, it is not safe to consider that sdram wont be corrupted after a reboot
<derethor> it would be a big security hole (just reboot, and read the user space memory?)
<hno> derethor, in this case we are looking for a reliable place to keep data during reboot, so the opposite.
<Turl> hno: android ramconsole works similar to what I am proposing btw
<Turl> (and it works on sun4i at least, it's supported on linux-sunxi)
<oliv3r> would you concider that reliable?
<oliv3r> consider*
<hno> Turl, my tests was on A10.
<oliv3r> those ramdumps are 'ok' if you want to try to debug stuff etc
<oliv3r> but lets just assume worst case scenario
<oliv3r> industrial setting, critcal equipment
<oliv3r> fluctionating temperatures
<Turl> oliv3r: worst case you miss a wdog reboot alert
<Turl> which is better than 0% chance of being alerted now :P
<oliv3r> for some reason your wdt tripped; can you guarantee that your memory will be reliable enough to store that?
<oliv3r> anyhow, how do we detect the wdt was triggererd?
<hno> Hm.. but maybe you are right. That test might have been using the reset via AXP method, not the watchdog. AXP reset is far more intrusive on the system.
<oliv3r> i mean, when the wdt runs out; it simply resets, you don't have 'time' to write stuff, do you?
<hno> oliv3r, correct.
<hno> oliv3r, so you write a status flag "watchdog is running" and then remember to clear that in normal shutdowns.
<oliv3r> ah, sure of course
<oliv3r> i was thinking the opposite
<oliv3r> write on failure
<Turl> oliv3r: there's no callback on failure
<oliv3r> yeah :)
<Turl> at least on the reboot option
<oliv3r> but hno solved it :)
<Turl> iirc it also supports launching an interrupt
<Turl> which you could handle
<hno> Many watchdogs do have a persistent "watchdog have fired" flag, but not here..
<oliv3r> linux always reserves the first 4k of RAM for the 'bios' doesn't it; 4k or more
<oliv3r> or ist hat only on x86
<hno> Turl, yes, but you then have to rely on the interrupt handler to actually work. It's only reliable to use that scheme in two-stage watchdogs that will also fire the reset line after a while longer.
lkcl has joined #linux-sunxi
<Turl> yes, it's not very useful if you need it to reboot the device
<oliv3r> hey luke
<hno> oliv3r, mripard pushed u-boot mvtwsi drier changes to sunxi-current.
<hno> I pushed..
<oliv3r> hno: that's fast ok i'll pull and see if i notice any awkwardness
<Turl> hno: axp works over it? nice
<oliv3r> i wanna test i2c on a20 anyway for some things
<hno> yes.
<rz2k> so another used IP core in Axx...
<oliv3r> rz2k: yeah
<rz2k> how many more is there?
<oliv3r> probably tons
<oliv3r> hno: cmd_watchdog is not a generic u-boot command, right? (i changed it to make it work of course)
<hno> gps, i2c, usb, musb, sata, ide, mmc identified so far with varying degrees of modifications. I would guess nand, memorystuck, eMMC, CE-ATA, ATA, and several I have forgotten.
<hno> oliv3r, correct. It's a big hack.
<oliv3r> how are commands usually handled?
<oliv3r> i kinda liked it :p
<hno> there is no u-boot API for setting watchdog parameters.
<oliv3r> :(
<hno> commands go into common/cmd_<name>.c
<rz2k> shouldnt we document this somewhere at like " IP Cores"? :p
<oliv3r> rz2k: thanks for vaulentering :)
<rz2k> also about nand, I think we can easily identify it by the two RAM banks and read/write size equal to 1024 bytes only
<jabjoe1> anyone free and able to talk about fex? I want to talk about [autotp<X>] bit and my touch screen.
notmart has quit [Quit: notmart terminated!]
<rz2k> (though reading couple of NAND drivers in mainline, I didnt identify it)
<rz2k> jabjoe1: just ask and maybe someone will answer you
<jabjoe1> Ok, I don't quite understand where my touch screen setting are coming from. The only mention in the fex for my touch screen in a autotp section.
<derethor> btw, is there any reference for fex files? i guess i can setup the sdram moduel there
<jabjoe1> but that section doesn't have all the details that are coming across in dmesg.
<jabjoe1> it's the script.bin/script0.bin from my boot partition. Is there anywhere else used?
<rz2k> derethor: jabjoe1:
<jabjoe1> yer, it doesn't help.
<rz2k> if it isnt there, then it is something new introduced in one of versions we dont know about
<rz2k> probably :p
<derethor> thanks!!
<jabjoe1> From the dmesg it's like the touch screen is getting a mix from [ctp_para] and [autotp5], and somewhere else.
<jabjoe1> But I can't find anything about autotp sections.
<oliv3r> jabjoe1: check the source. the wiki (on fex) might be wrong
<oliv3r> jabjoe1: you can always (git) grep :)
<jabjoe1> oliv3r: yer, that was my next port, but I'd see if anyone knows anything relevant not in the wiki first.
<hno> rz2k, I do not think it's a controller found mainline. But I aslo do not think Allwinner did implement it themselves.
<hno> it's too wacky interfaced to the CPU for being their own.
<hno> jabjoe1, we try to dump stuff in the wiki.. minds bitrots too fast.
<hno> oliv3r, any luck with sending that patch fixing sun4i in wip/a20 branch?
<oliv3r> hno: wdt should be done after this compile issue; then i'll send the whole shebang
<hno> ok.. and my brain is starting to shut down..
<oliv3r> hno: do i need to do anything after adding a header file to arch/arm/include/asm-sunxi/watchdog.h ?
<hno> what do you mean?
<oliv3r> i added that header, and included it as <asm/arch/watchdog.h>
<oliv3r> but board.c complains about not able to find the function
<hno> and you have correct #indef guards not accidently copying some other header?
<jabjoe1> hno: I'll share anything I find then.
<oliv3r> hno: ohhh good point
<hno> There probably is an up to date fex guide in Allwinner Android-2.2 release somewhere.
<oliv3r> good catch :)
<hno> oliv3r, been there done that :)
<hno> more than once...
edeloget has joined #linux-sunxi
<jabjoe1> hno: Can you point where to find that?
<oliv3r> hno: where I best put CONFIG_CMD_WATCHDOG for a test build?
<oliv3r> rz2k: awesome
<rz2k> pls fix it if I goofed something up
<oliv3r> jabjoe1: you can check the linux-sunxi github, if your touchscreen driver is not there, allwinner hasn't released source for it; so you can always try to ask
<rz2k> is our G2D copypaste from exynos?
<oliv3r> hno: to enable it :p I'm grepping right now, wanna test this build quick
<jabjoe1> oliv3r: Oh I checked, it's not arround. BUT, I've got a non-allwinnered version. I plan to try and make one, if I can find the time and information.
<oliv3r> jabjoe1: well the only difference is, the addition to 'fex' (script parser) sections :)
<hno> oliv3r, include/configs/sunxi-common.h have it commented already.
<jabjoe1> oliv3r: Well not quite, the GPIO arrangement is different. On the one I have, it must have two. But I can see from the dmesg in android there is only one, and the driver it has, support only having one.
<oliv3r> hno: is it as simple as adding CMD_WATCHDOG to the boards.cfg?
<hno> oliv3r, that also works.
<oliv3r> sunxi-common.h looks 'ok'
<oliv3r> but guarded by #ifdef CONFIG_CMD_WATCHDOG
<oliv3r> so boards.cfg it is
<hno> Err, you need CMD_WATCHDOG,WATCHDOG
<oliv3r> both? ah ok
<hno> and the commented part in sunxi-common.h do not work, too late.
<oliv3r> ah the #if 0 bit, found it now
<hno> wonder when it got moved down.. worked in the past.
<hno> hmm. can't have worked. Maybe I had CONFIG_CMD_WATCHDOG somewher eelse when doing the env part.
<oliv3r> lol
<oliv3r> what could be wrong if a10 decides to ignore spl on mmc
<oliv3r> i need sunxi-spl.bin not u-boot duh
<oliv3r> ok no watchdog cmd
<oliv3r> but it gave a warning, so it must be there
<oliv3r> a warning on U_BOOT_CMD(
<edeloget> Hello ; I'm about to receive an Olimex A10S in order to check some possibilities of this CPU (and then mayboe to integrate it in a project of mine). Do you have a few pointers that would help me to start rapidly ?
<WarheadsSE> edeloget: which OS, if linux, which variants are you most comfortable with
<oliv3r> edeloget: turl just got his too :)
<WarheadsSE> I've had mine since last thursday
<WarheadsSE> kinda frustrated i've been too busy to even try
<wingrime> oliv3r: we have sony mem stick support but have no driver?
<WarheadsSE> but hans has been busy committing like afiend
<edeloget> WarheadsSE: linux of course, and preferably bare ones (I'm used to work with OpenWRT on several other systems)
<WarheadsSE> edeloget: okay.. debian, arch, gentoo, ?
<WarheadsSE> could probably adapt and LFS
<Turl> buildroot :)
<edeloget> WarheadsSE: if I can avoid any of these that would be fine. Embedded and debian/fedora don't mix very well, and I don't know arch very well.
<Turl> wingrime: supposedly, I've seen "MS" in a lot of places
<edeloget> Turl: buildroot is fine
<oliv3r> wingrime: very likly :)
<WarheadsSE> edeloget: arch isn't hard to get used to
<WarheadsSE> very much, "welcome to linux, here's a wrench"
<Turl> edeloget: well, in any case, the procedure is mostly the same, you just need to build kernel, uboot, prepare your card and then you can put whatever rootfs you like
<oliv3r> hno: let me find your disable patch; since it compiles it, but the command isn't available
<WarheadsSE> ^
<oliv3r> hramrach_: with ubuntu lxc; it builds in one go
<mripard> hno: great, I'll have a look at it
<edeloget> Turl: sounds easy :) yet I suppose that an upstream kernel is not the best solution :)
<edeloget> (I mean one from
<Turl> indeed edeloget, use linux-sunxi one
<WarheadsSE> ^^
<Turl> edeloget: unless you want to just gpio or i2c with a couple of patches
<WarheadsSE> very important at this point in time
<edeloget> Turl: well, I need an access to the HDMI port, to the USB ports and I need to get weston running with OpenGL ES (I understand that the lima drivers are not production ready)
<WarheadsSE> well weston's pretty bleeding
<edeloget> WarheadsSE: I have no experience with weston, unfortunately. But then that's the whole point of the project : I want to be able to build something cool that would (perhaps) benefit the community.
jabjoe1 has left #linux-sunxi [#linux-sunxi]
<WarheadsSE> ah
* hno isn't even aware of what weston is.
<WarheadsSE> Wayland + Weston
<oliv3r> hno: at what point did sunxi-current and sunxi diverge? trying to find why watchdog command doesn't work
<edeloget> hno: that's wayland reference compositor
<hno> oliv3r, way too long ago.
<hno> and watchdog command did work not too long ago.
<oliv3r> hno: ok i'll start diffing some files then
<oliv3r> it must compile, but it doesn't show in help, nor does it work
<hno> if it does not show in help then it's not compiled into the binary.
<hno> unless you completely have messed up the command definition.
<oliv3r> but the build gives a warning
<hno> do you see it in the link map?
<oliv3r> U_BOOT_CMD( watchdog, 2, 1, do_sunxi_watchdog, "Set watchdog. 0 disables", ""
<oliv3r> );let me check
<oliv3r> anyway, it gave a warning on the 'cmd' macro
<hno> What warning?
<edeloget> WarheadsSE: by the way, are there any OpenGL ES binary blobs that require neither X nor the android (bionic-based) binaries ? i.e. binary blobs that would allow me to at least port Wayland on this platform (if it' s not done already)
<oliv3r> cmd_watchdog.c:38:1: warning: initialization from incompatible pointer type [enabled by default]
<oliv3r> so looking now
<Turl> edeloget: there's some to be used against a framebuffer iirc
<oliv3r> thought it gave a diff warning before, about wrong arguments etc
<oliv3r> command.h is not included
<WarheadsSE> edeloget: what turl said, but there are no oglES binaries that are significant usefulness at this point
<WarheadsSE> they do exist, but I work with Arch, so they don't tend to like Xorg > 1.12 & I have 1.14
<WarheadsSE> 1.13 abi broke that pretty nasty
<oliv3r> #include <asm/armv7.h>
<oliv3r> is that needed for it?
<oliv3r> nope not either, wtf
<oliv3r> i didn'te ven change anything with regards to that bit
<edeloget> I'm trying to figure out the current state of lima ; it's going to be tough.
<Turl> libv: ^^
<edeloget> Turl: just saw he was here too
<oliv3r> reset works, so the code is working :)
<Turl> oliv3r: get me my watchdog 1 back! :p
<oliv3r> Turl: this one will have watchdog 0 (for 0.5)
<Turl> :)
<hno> Hm.... why can't I fel boot u-boot on my cubie any more... resets when I start main u-boot...
<Turl> ethernet works just fine on my olinuxino in mainline :)
<hno> Turl, kernel?
wingrime has quit [Ping timeout: 240 seconds]
<Turl> hno: torvalds/master + misc patches for A10S, emac etc
ZaEarl has joined #linux-sunxi
ZaEarl has quit [Client Quit]
<oliv3r> Turl: hopefully you get a20 soon too :)
<Turl> oliv3r: did anyone get their a20 cubie yet?
<oliv3r> Turl: haven't heard anyone
<hno> Neither have I.
<hno> other than Cubie himself..
<edeloget> damned. I lost the linux-sunxi tree again...
<Turl> how big is the non micro olinuxino?
<oliv3r> Turl: why does --annotate --cover-letter always bring up my editor twice
<oliv3r> hno: check your mail :)
<lkcl> i'm looking through the logs here, i see rellla made a request for GPL compliance to allwinner
<hno> oliv3r, I will, but your breakage is only in wip/a20, right?
<oliv3r> lkcl: about 2-3 weeks ago
<lkcl> could people please not do that, and follow the advice on
<oliv3r> hno: yes; and fix is supplied as single patch in the set
<lkcl> i seem to be able to get through to them
<oliv3r> lkcl: erm that was BEFORE all of that
<lkcl> and to have several people... oh ok
<oliv3r> let me check my mail for the date
<edeloget> found it again. github tells me that "something went wrong" on the driver/ directory.
<oliv3r> buit yes, it should be noted that we shouldn't contact allwinner on gpl issues
<lkcl> oliv3r: no need - if you see him could you ask him to send me the information and i'll ask on his behalf
<Turl> oliv3r: twice? for the same file?
<lkcl> or, mail me cc him... ah?
<lkcl> Turl: yes, if it was the same file(s) that's what we want to avoid happening
<oliv3r> lkcl: will try to remember
<lkcl> oliv3r: ack. or ask rellla if you see him around.
<Turl> lkcl: hm? are we talking about the same thing?
<oliv3r> Turl: i get the 0/4 message, edit it; save + exit; it comes up again, save + exit again, then the mail cli stuff comes
<lkcl> Turl: probably not, if oliv3r is on two conversations at once :)
<oliv3r> lkcl: i'll tell him to fwd/cc you on stuff
<lkcl> oliv3r: ack dude
<oliv3r> rellla: ping ^ :p
<Turl> lkcl: I'm answering re. --annotate --cover-letter :)
<oliv3r> i try to have 2 conversations; 3 probably
<oliv3r> lkcl: rellla's stuff was a) about working up to date armhf cedarX libs mostly however
<oliv3r> i'll fwd the mail just in case
<Turl> oliv3r: looking at your first patch,
<Turl> why multiple spaces? :P
<oliv3r> dno't ask me
<oliv3r> i changed it to have 1 space
<oliv3r> saw that the entire repository had two
<oliv3r> checked on
<oliv3r> 2
<oliv3r> some sections start with 2, but not everywhere
<oliv3r> so i stuck with it
<hno> oliv3r, mripard, something is wrong. have backed out the mvtswi driver from sunxi-current for now. It's in my wip/i2c branch until I understand what goes wrong.
<oliv3r> but the tab was horrible
<hno> the MMC suddently fails.
<oliv3r> hno i broke mmc :p
<hno> oliv3r, not in sunxi-current.
* edeloget is cloning linux-sunxi...
<Turl> -while (readl(&dram->ccr) & (0x1U << 31));
<Turl> +while
<Turl> +(readl(&dram->ccr) & (0x1 << 31));
<Turl> oliv3r: ^ ? :P
<oliv3r> checkpatch complains about the statement
<oliv3r> 0x1U is inconsistant how we do things throughout
<Turl> oliv3r: yeah but why the extra newline and indentation?
<oliv3r> to be fair, should be updated and BIT(); should be used so all gets turned into 0x1ul
<oliv3r> which reads as lul in dutch which is a penis
soul has joined #linux-sunxi
<Turl> lol
<oliv3r> Turl: checkpatch doesn't want a 'while (1); with long things in it on a single page
<oliv3r> line*
<Turl> ok then :)
<oliv3r> these are like hardcore kernel devs; they know what they are doign (tm)
<oliv3r> though i dissagree with some of their choices
<hno> I think checkpatch do not want empty while(); loops.
<oliv3r> (i'm a sucker for 1TBS)
<Turl> oliv3r: why turning some hex to lowercase?
<oliv3r> Turl: concistancy
<oliv3r> Turl: unless i overlooked some of course
<Turl> oliv3r: yes you did :)
<oliv3r> Turl: crap :(
<Turl> I thought they were all in caps
<jelly-home> but that line is not a while(1), and is logically a single busy-waiting command
<oliv3r> but hno was asking me to do more
<oliv3r> to do more == to submit it :p
<Turl> oliv3r: arch/arm/include/asm/arch-sunxi/i2c.h TWI_CLK_DIV(N, M) one
<oliv3r> Turl: to me, 0x is lowercase, without 0x is upper :)
<hno> jelly-home, it an empty while body, and is what confuses checkpatch.
<hno> oliv3r, that while should be in one line even if checkpatch complains.
<oliv3r> hno you dare to dissagree with checkpatch?!
<Turl> oliv3r: #define TWI_CLK_DIV(N, M)((((N) & 0xF) << 3) | (((M) & 0x7) << 0))
<jelly-home> maybe checkpatch needs to be "fixed"
<oliv3r> Turl: i'll fix that with the while fix
<hno> oliv3r, yes in that case.
<hno> the newline is just confusing.
<oliv3r> i agree; you fix checkpatch; i fix patch :D
<hno> and the same construct is relatively common in u-boot, and checkpatch complains on them everywhere.
<hno> there is a u-boot coding rule to disagree with checkpatch when common sense says checkpatch is wrong.
<oliv3r> ok rebaseing and fixing
<oliv3r> sec
<edeloget> hno the same rule apply for the kernel
<edeloget> by the way, which kernel (branch) in the linux-sunxi git should I use ?
<oliv3r> maybe rewrite it to do while ();?
<oliv3r> Turl: anything else i need to fix?
<Turl> oliv3r: not that I noticed on a quick look; I didn't actually test it so can't comment on that though
<oliv3r> test the wdt :p
<oliv3r> anyway, i got the entire set fixed and ready to resend unless there's other issues
<Turl> oliv3r: testing involves shutting down my mele to use its uSD->SD thing to use my card reader :P
<oliv3r> :p
<oliv3r> get more uSD
<oliv3r> i have .. 8 or so
<oliv3r> from work, 128-2G
<Turl> oliv3r: yeah, I need more
<Turl> I'm actually using the one from my phone
<Turl> which coincidentally had a couple of MB free on the front of the card
<hno> Hmm.. when I think of it I never tested mvtwsi in full u-boot.. seems it is doing smething that crashes relocation.
<hno> it's not the MMC that fails.
<oliv3r> that's good thuogh rather
<oliv3r> hno: you testing on a10 or a20
<Turl> I see buildroot got support for nand-part, sunxi-tools and some script.bin thing
<hno> oliv3r, A10.
<hno> confirmed. If I move i2c initialisation to after u-boot have been relocated then mvtwsi do work.
<hno> odd.
<hno> how can mvtwi make relocation fail if initialized prior to relocation.. and why on sunxi and not the marvell boards using it?
<oliv3r> very strange indeed; something fishy is going on
edeloget has quit [Ping timeout: 250 seconds]
<Turl> hno: the olinuxino uart doesn't seem to leech power like the cubie one
<Turl> either that or this usb-uart cable I got with it is better in that regard
paulk-desktop has quit [Quit: Ex-Chat]
<oliv3r> Turl: what makes you say that, i never connect the power wire
<Turl> oliv3r: on the cubie if I power off the board via button or unplugging power it still remains 'half on' and if you boot it after that it always boots from nand
<oliv3r> yeah
<oliv3r> i have that too
<oliv3r> but only 'sometimes'
<Turl> I have it all the times
<Turl> and having to unplug the uart is tiresome
<oliv3r> when I remove all wires, and only plugin rs232; it doesn't light up
<Turl> the olinuxino just works (tm)
<hno> Turl, only the A20 board is fixed to not leak..
<Turl> hno: it might be the better looking uart cable then
<Turl> this one has long uart lines and short usb ones
<Turl> my other one has short uart lines and long usb ones
<hno> What matters is what is between the wires..
<hno> what drive current it has on the TX wire.
<hno> serial is active low, so idle state is 3.3V.
<rz2k> where did olinuxino-a20 go from wip/a20 :p
<Turl> lsusb says PL2303 fwiw
<hno> what?
<rz2k> there were commit on top of lkcl's
<rz2k> from oliver
<hno> and me...
<hno> hmm...
<oliv3r> hno: want me to resend only the fixed patch, or the entire set?
<oliv3r> rz2k: confirmed
<hno> seems a rebase gone wrong. fixing up.
<hno> Think I found the right git reference again.
<hno> oliv3r, what do you mean?
<oliv3r> hno: doesn't matter; i've resent it as a v2 :)
n01 has quit [Ping timeout: 252 seconds]
<hno> Hm... git am dislikes Overal codebase cleanup.
<hno> did I get lost in my git references?
<oliv3r> erm
<oliv3r> i sent the patch-set with git send-email :(
<hno> and I lost my wip/a20 branch head reference...
<oliv3r> you broke it!
<oliv3r> let me push mine to github
<hno> I think I found it again, but...
<oliv3r> hmm, i may have done some work on the wrong branch, you won't notice i'm sure :p
<hno> what git reference do you have for my wip/a20?
<oliv3r> commit 66793b53fd813691976e42dedc38ae882b028861
<oliv3r> sunxi: Add status led to A20-OLinuXino board
<oliv3r> Date: Mon Jun 10 11:45:36 2013 +0200
<oliv3r> Author: Henrik Nordstrom <>
<oliv3r> is your last commit to that
<Turl> hno: git reflog?
<hno> Turl, used that.. but been jumping between branches a lot.
<hno> and there was a forgotten rebase somewhere in the middle that crashed things
<oliv3r> Turl: top of your head; where ist he nand module version stored?
<Turl> oliv3r: somewhere? :P dunno
<Turl> oliv3r: if I were guessing I'd go with a header
<hno> oliv3r, it's in the header of the logical nand section if I remember correctly.
mdfe has joined #linux-sunxi
<hno> oliv3r, why do you ask about the nand module version?
<oliv3r> someone on the ML is complaining
<oliv3r> so wanted to check it
<oliv3r> but nand is ... confusing
<Turl> oliv3r: btw, you got a typo on patch subject :p overall takes two L
<oliv3r> Turl: this is european-english
<oliv3r> it's different
<oliv3r> :p
<Turl> oliv3r: you mean UK? ;)
<oliv3r> nono, Netherenglish
<Turl> :)
<hno> oliv3r, I have the same, but another version of "Add A20 support to u-boot v2" ontop of that.
<oliv3r> well you can always merge-reapply my patches; i might have messed up my repo's to be fair :p
<hno> did you push the new patches as well?
<oliv3r> only the A20 ones
<oliv3r> there's 2 patches ontop of that
<oliv3r> 1 that you had, one that you didn't
<oliv3r> most top one you is only on ML
<oliv3r> it fixes that commit before that
<hno> you mailed 4.
<hno> which ref is your new patch set based on?
<hno> Hm.. no the "Add A20 support to u-boot v2 " is the same in your branch as mine.
ssvb_ has quit [Ping timeout: 264 seconds]
<hno> something is fishy...
<oliv3r> *smells armpits*
<oliv3r> sorry
<hno> Odd.. worked cleanly now after I fetched your tree.
<oliv3r> pfew
<oliv3r> so nothing lost?
<hno> I don't think so. refs do match up fully.
tinti has quit [Read error: Connection reset by peer]
<hno> oliv3r, indentation looks odd in sunxi/Makefile in the watrchdog patch.
<oliv3r> not sure if I touched that
<hno> and should also fix the default environment..
<oliv3r> lemme check
<hno> you added watchdog.o
<oliv3r> ohh duh
<oliv3r> looks 'perfect' on my screen
<oliv3r> but that's cause everything above uses 2 or 3 spaces
<hno> thinks it's a tabs / spaces thing. Probably aligned right.
<oliv3r> i just copied pinmux 1 line down and renamed it
<oliv3r> hmm
<hno> reading the patch.
<oliv3r> ah see, that's why I should enable 'list' by default on my desktop
<oliv3r> only have it on my server on by default
<oliv3r> yeah it's a tab that's wrong
<oliv3r> i used 3 spaces but shoudl have been tab
<oliv3r> but i copy pasted :(
<oliv3r> btw, cmd_watchdog has the same problem
<hno> probably is more of those.
<oliv3r> i copy/pasted cmd_watchdog, that's why
<oliv3r> i'll fix both up
<hno> send an incremental patch. Already merged and reshuffled.
<oliv3r> ok
<oliv3r> :p
<oliv3r> ah, nvm thought I was on the wrong branch
<oliv3r> i'll mail
<oliv3r> sent
<Turl> [ 16.842966] pcf8563 1-0051: pcf8563_set_datetime: err=-70 addr=03, data=00
<Turl> [ 16.842975] alarm_set_rtc: Failed to set RTC, time will be lost on reboot
<Turl> (that's the default android on the olinuxino)
<Turl> preceded by [ 16.842940] [i2c1] incomplete xfer (0x20)
<hno> oliv3r, patches resplit to sunxi-current & squashed to wip/a20
<Turl> I need a usb keyboard to use this hm
<oliv3r> hno: awesome thanks
<Turl> cool, the default android firmware has dlna :P
<Turl> I can now throw stuff from my phone to the tv haha
tinti has joined #linux-sunxi
mdfe has quit [Remote host closed the connection]
soul has quit [Read error: Operation timed out]
soul has joined #linux-sunxi