<mripard_>
Pick the one you want depending on wether you want a zImage/uImage, and on what UART you have access to
<hipboi>
mripard_, thanks
<mripard_>
hipboi: I'm not exactly sure it will boot though, it was only blind coding, so it might very well fail with some dumb error :)
<hipboi>
mripard_, :)
wingrime has quit [Ping timeout: 260 seconds]
Undertasker has joined #linux-sunxi
Undertasker has quit [Client Quit]
<rellla>
we probably should do something with the wiki. Turl's question improvement seems to be not enough...
hipboi has quit [Quit: Leaving]
hansg has quit [Remote host closed the connection]
jelly has quit [Remote host closed the connection]
hansg has joined #linux-sunxi
<Turl>
rellla: hm?
<Turl>
still getting spamguys? :/
<rellla>
Turl: yep
<rellla>
more aggressive than the last ones
<Turl>
rellla: jugding by recent changes, they don't seem to be registering massively
<Turl>
so the questions kind of work :)
<rellla>
it's better. maybe the last one was a manual edit...
hansg has quit [Quit: Leaving]
vicenteH has joined #linux-sunxi
Dave77 has joined #linux-sunxi
<slapin_nb>
mripard_: hi
<slapin_nb>
mripard_: any news on upstreaming of A13 stuff? I was so busy with $$$ job that I basically was unable to communicate to outside world
<slapin_nb>
hno: ^
<mripard_>
A13 or A31?
<slapin_nb>
mripard_: A13
<mripard_>
well, we continue to upstream stuff
<mripard_>
we have all the basic blocks except dma
<mripard_>
so gpio, interrupts, clocks are there
<slapin_nb>
mripard_: that is cool, was it boot tested with UART?
<mripard_>
of coures
<mripard_>
UART has been working since day1
<slapin_nb>
mripard_: I make custom board, so I want to use vanilla with it
<mripard_>
hmmm, there's no storage support, no buses support
<mripard_>
I'm not sure it's a wise choice at the moment
<mripard_>
of course, if you want to contribute that support... :)
tinti has joined #linux-sunxi
Dave77 has quit [Ping timeout: 256 seconds]
Undertasker has joined #linux-sunxi
kulya has joined #linux-sunxi
<slapin_nb>
mripard_: of course I do, you make me wonder...
<mripard_>
slapin_nb: I have patches for the wemac, patches that add the EINT support, and I'm working on the I2C currently
<mripard_>
emac and EINTs work, so they should be merged in 3.11 quite easily, if I manage to find some time to post them
<mripard_>
i2c is in progress, I have good hope as well for 3.11
<mripard_>
but other than that, I'm not aware of anyone working on a "major" driver that could be merged for 3.11
<mripard_>
of course, I'd be very happy to be proven wrong :)
<mripard_>
but at the current rate, I don't see a production-ready kernel before 3.13
<mripard_>
I'd very happy to see some real official use of the work we do on mainline, but I prefer to be honest here, just so that you don't end up being screwed :S
Dave77 has joined #linux-sunxi
Dave77 has quit [Client Quit]
<slapin_nb>
mripard_: I think adding the rest of drivers won't be a problem
<lkcl>
the only thing i had to do, really, was add LIBS = "$LIBS -lpthread" to configure.ac
^dst has quit [Ping timeout: 264 seconds]
<libv>
did i recommend that? when?
kulya has quit [Ping timeout: 245 seconds]
vicenteH has quit [Ping timeout: 245 seconds]
<lkcl>
you did :)
<lkcl>
huh. i thought it was you...
<lkcl>
... you didn't :) i can't remember who recommended it to me! oh wait - it was someone on debian-arm mailing list. i must reply to them and say thank you
<lkcl>
sorry libv :)
<libv>
:)
Undertasker has quit [Read error: Connection reset by peer]
Undertasker1 has joined #linux-sunxi
Undertasker has joined #linux-sunxi
Undertasker1 has quit [Ping timeout: 252 seconds]
Undertasker has quit [Ping timeout: 252 seconds]
Undertasker has joined #linux-sunxi
Undertasker1 has joined #linux-sunxi
asdasdad has joined #linux-sunxi
Undertasker has quit [Ping timeout: 264 seconds]
<oliv3r>
n01: why do you name your WatchDogTimer, sunxi_dwt? DogWatchTimer? DigitalWatchTimer?
<oliv3r>
n01: also, personally, I think local capital hexadecimals look better, but the kernel is inconsitent anyway. I think, 0x with lower letters, without 0x caps :)
<n01>
and what do you mean with " local capital hexadecimals" ?
<oliv3r>
n01: i don't think it's a good idea to have min_timeout and timout as magic values, but max_timeout IS defined nicely
asdasdad has quit [Quit: Page closed]
<n01>
timeout is just a dummy value, it is not worthy to make it as define
<n01>
it could be 2,4,7,whatever
<oliv3r>
hipboi|cubie: I don't think mnemoc has deleted anything, it's just not all public. But you say there was accidental openmax/cedar code leaked too? I haven't found it yet ;(
<n01>
oliv3r: hoooo you mean DRV_NAME .... it is just a typo :)
<n01>
I'll wait for some more feedbacks before submitting again with that corrected
<oliv3r>
lkcl: so the sunxi FB driver is the same as on the exynos? Did they 'borrow' the IP?! (don't we have an official exynos FB driver? I thought samsung was pretty ok with their support)
<oliv3r>
n01: first file i open (acquireWDT.c) uses DRV_NAME "acquirewdt" I think you mixed up the dwt and wdt :p
<oliv3r>
n01: and 0xa57 vs 0xA57; personally, i'd use capital A in a hex that doesn't have the 0x prefix :)
<n01>
I think 0xA57 is much more clear since it is well defines where the 0x ends. Yeah I definitely prefer the capital letters for hex numbers
<oliv3r>
I think 75% of the kernel source is small; the rest caps
techn_ has quit [Read error: Connection reset by peer]
techn_ has joined #linux-sunxi
<n01>
dunno actually I'll take a look when I'll be back home
<oliv3r>
but i'm nitpicking :p
<n01>
:D no prob thank you for reviewing it
<oliv3r>
n01: if it's not used, call it TIMEOUT_DUMMY and make it clear that it is a dummy value :p
<oliv3r>
n01: having it as a define, also explains what it does and doesn't leave a random unexplained magic value laying around
^dst has joined #linux-sunxi
<oliv3r>
n01: btw, i'll try to dig into the sun7i's watchdog on the lichee-dev tree's and see if they've defined those '0xa57 unknown' registers so we can name them etc, seems like that default value is a few registers combined
<lkcl>
oliv3r: it's the exact same mali and libUDM libraries. xf86-video-sunxifb is *not* restricted to sunxi, because it's got nothing to do with sunxi, it's to do with Mali. ok if they start putting in links to the 2D GPU *then* it's specific to sunxi :)
<n01>
but it is not an unknown register is just a value to be inserted in WDT_MODE_REG register
<oliv3r>
lkcl: ah, i never looked at the repo, but it made it sound like a 'sunxi framebuffer' driver :)
<oliv3r>
n01: the datasheet doesn't list it :p (well not the A10 when I wrote the wikipage)
<oliv3r>
n01: but it's various bitvalues you change, i don't think it's 1 big register :p
<oliv3r>
n01: it probably touches the first 12 bits or so
<n01>
oliv3r: A10 User Manual V1.20 pg. 99
<n01>
it is all there, it just that it is not 0x333 but 0xA57
<oliv3r>
hmm
<oliv3r>
but look at the wiki
<n01>
or maybe I'm missing your point
<oliv3r>
n01: it says: TMR_WDT_CTRL (bit 0)
<oliv3r>
'reserved 1:12' 0x0a57
<lkcl>
oliv3r: yeah i know - that's the point. it's a bit ineptly named
rz2k has joined #linux-sunxi
<oliv3r>
lkcl: ah okay, should be xf86-video-mali :)
<n01>
oliv3r: the wiki is wrong TMR_WDT_CTRL is the _register_ WDOG_RSTART is the bit 0
<oliv3r>
n01: hmm, yeah I'll fix up the section, cause in the datasheet more bits are defined. Why did I write 'reserved' maybe i had a diff. datasheet at the time?
<oliv3r>
n01: i don't know what I was thinking then :p
<n01>
:)
<oliv3r>
I'll fix it up on the wiki
<oliv3r>
no
<oliv3r>
ugh
<oliv3r>
you confused me
<oliv3r>
the WDOG_MODE_REG is define just fine
<oliv3r>
the 0x333 (incorrectly) is in the WDOG_CTRL_REG
<oliv3r>
it's marked as 'reserved' but I'm not sure i want to belive that, so i'll go look in the sun7i source for starters and see if they defined it there better
<oliv3r>
n01: in the A13 datasheet (not available at the time) it is called 'KEY_FIELD'
<n01>
lol .... I said 17:23 < n01> oliv3r: the wiki is wrong TMR_WDT_CTRL
<n01>
but nevermind
<n01>
It must be some kind of protection key
<oliv3r>
n01: now you confuse me more :p
<oliv3r>
might make sense but protect what?
<oliv3r>
i mean, do you need that key to ARM the watchdog?
<oliv3r>
if that is the case, then yeah, it does make sense. 'will not work until you arm me with the correct key' :)
<ssvb>
lkcl: xf86-video-sunxifb is "xf86-video-fbdev" (works on any hardware) + "ump based mali" (works with any mali400) + "a bit of neon code" (works on any arm neon processor) + "sunxi g2d, hw cursor and layers" (works on sunxi)
<n01>
the opposite, you need the "key" to disarm it. I'm not sure what it is for. It gets cleared every time you reset the wdt
<ssvb>
lkcl: the features get enabled based on what is available
<oliv3r>
n01: so you start with an inactive timer, you can configure and 'start (arm)' it and it'll work just fine
<oliv3r>
but to disarm it (and disable it again) you need the secret key?
<n01>
I'm not saying that it is a "secret key". I have no clue what it is for. Just guessing actually
<oliv3r>
i'll check sun7i :)
<n01>
I just know that if you don't use the correct value the watchdog cannot be restart
<hramrach>
ssvb: I booted kernel with broken modules and gnome+sunxifb would not start
<hramrach>
X would start but gnome woould get stuck
<hramrach>
not current version probably
<ssvb>
hramrach: that's interesting, can you provide more details?
<hramrach>
built new kernel left old modules so none would load.
<hramrach>
have framebuffer abd hdmi built in but mali and ump as module
<hramrach>
rebuilding modules fixed that
<hramrach>
driver 6f708d4 Mar 7
<hramrach>
possibly the enabling features as available gets better with more recent stuff
<hramrach>
or gnome gets stuck in libEGL trying to load the modules, quite possible
<ssvb>
hramrach: I mean, unless loading an incompatible kernel module oopsed the kernel, it should still have handled this error properly
<hramrach>
X did start so it maybe did but could not move mouse cursor
<hramrach>
but maybe just nothing turned it on so it weas not visible
<hramrach>
this X stuff with not showing anything by default sucks for debugging
<hramrach>
hmm. definitely needs more testing to determine what is stuck and where
<n01>
oliv3r: no. It is pretty much the same of mine
NermaN has joined #linux-sunxi
<n01>
but I'll take a look. Maybe I can submit a v2
<oliv3r>
n01: it's based of hno's driver :)
<oliv3r>
mnemoc said that aw based their wdt on hno's
<n01>
also mine is based on hno's
<n01>
but obviously the aw's is better than mine :D
<n01>
ok, it seems that I have to rewrite it basing on aw's version
<n01>
at least is a good exercise :D
<mripard_>
n01: if you resend it, please send it to the rightful maintainers and lists.
<mripard_>
and cc me on this :)
<mripard_>
It's good enough to submit it
<mripard_>
I'd like to avoid doing the reviews twice.
<oliv3r>
n01: I think yours looks much better and much much cleaner
<oliv3r>
n01: but do study theirs, as they have some inside info that they may have used on it
<n01>
oliv3r, mripard_ ok, I'll take a look to the aw's version during the weekend (hopefully). I'll send the new version cc'ing you both (and ml of course)
<oliv3r>
n01: i don't see 0xa57 used anywhere in their code :(
<mripard_>
n01: I meant send it to linux kernel mailing list, to the watchdog maintainer and so on
<n01>
mripard_: yes I got it. But I want to study the aw's version before
<n01>
oliv3r: this is weird
<n01>
could the sun7i be a bit different?
<mripard_>
sun6i is different for the watchdog at least
<n01>
How are you managing these differences in the other drivers?
<n01>
I mean i could write a sun4i-specific driver
<mripard_>
don't worry about that.
<mripard_>
we'll worry about that when we will have hardware and support for that hardware.
<n01>
:D ok
<oliv3r>
n01: it could, let me compare to sun4i lichee branches
<oliv3r>
i guess there will be some special cases for sun6i in the wdt; but i assume that 457 are probably the same
<oliv3r>
n01: 0xa57 is used as a reload key for the sun4i
<oliv3r>
so looks like sun7i is slightly different
<n01>
oliv3r: ok, I'll try merge the sun4i with the aw's driver for sun7i since it seems in better shape than mine :)
<oliv3r>
n01: you think so? Yours is much cleaner
<mripard_>
oliv3r: +1
<oliv3r>
n01: but you'd need hardware/datasheet to see how your driver behaves on sun7i :)
<n01>
They manage the irq, suspend/resume and I don't ... moreover I like their sunxi_watchdog_interv :)) it is less "hackish" than mine
<n01>
no, I'll write a sun4i specific driver
<n01>
(at the moment at least)
<mripard_>
of course they manage they IRQ
<mripard_>
because the watchdog in sun7i can send an interrupt instead of rebooting the system
<mripard_>
the one in sun4i can't
<n01>
oh ok
<mripard_>
It's only what this is about :)
<n01>
:) ok then I'll steal only their sunxi_watchdog_interv ;))
<n01>
(even though my solution is more performant)
<mripard_>
there's one problem with their solution though
<mripard_>
they use floats.
<n01>
that's why I skipped the 0.5 in my driver actually
<n01>
(I assume that the minimum timeout is 1sec not 0.5)
<mripard_>
well, you can always use fixed points numbers
<n01>
yeah but it is worth it?
<n01>
anyway time to go home ... c ya later
n01 is now known as n01|work|afk
<mripard_>
I don't know, it can easily be adressed just by saying for example that the parameter is in milliseconds
<mripard_>
so why not use this, and that's fine
Undertasker1 has quit [Quit: Leaving.]
paulk-desktop has joined #linux-sunxi
<techn_>
hmm
<techn_>
should we remove "You received this message because you are subscribed to the Google Groups "linux-sunxi" group.".. text on our ML mails?
<paulk-desktop>
hi
rellla has joined #linux-sunxi
<paulk-desktop>
I am getting first messages from my ektf2k touschscreen :)
<paulk-desktop>
mainly HELLO_PKT
<paulk-desktop>
which confirms that the driver I found does work
rz2k has quit [Ping timeout: 264 seconds]
<oliv3r>
n01|work|afk: well th emost important part is to properly integrate it into the existing wdt framework
<oliv3r>
n01|work|afk: and the float scan easily be worked around, 0.5s == 500ms :)
<oliv3r>
should all easily fit into an 16bit int
art103 has joined #linux-sunxi
<oliv3r>
n01|work|afk: 500ms vs 1s can make quite the user experience difference imo, so it probably won't be bad to have
torqu3e has quit [Quit: torqu3e]
<oliv3r>
paulk-desktop: sweet
torqu3e has joined #linux-sunxi
<oliv3r>
i'm supprised we don't have a 'touchscreen' framework ontop of the input framework
<oliv3r>
or some common functions
<paulk-desktop>
well we could at least make that CTP code common
Undertasker has joined #linux-sunxi
<techn_>
oliv3r: there is bug.. that isn't really 0.5, it's 1 :)
<techn_>
0.5 to u32
_NermaN has joined #linux-sunxi
tinti_ has joined #linux-sunxi
NermaN has quit [Ping timeout: 245 seconds]
n01 has joined #linux-sunxi
<oliv3r>
techn_: i think datasheet says 0.5 too
<oliv3r>
the driver probably implemented it wrongfully
<n01>
uhm ... we have two setting for 1s then?
<techn_>
yeah. bug :p
<n01>
:D cool
art103 has quit [Ping timeout: 248 seconds]
sanka has joined #linux-sunxi
sanka has quit [Client Quit]
<n01>
mripard_: looking at the User Manual for A10 it seems like we have an interrupt for watchdog
<mripard_>
n01: judging from the interrupt sources?
<mripard_>
what i meant is that, in the sun6i watchdog IP, there's a register that allows to configure the behaviour of the timer, either it will generate an interrupt, either it will reboot the system when it expires
<mripard_>
this is what they configure
<techn_>
maybe same register works with sun4i?
<n01>
In sun4i we have WDOG_IRQ_EN and WDOG_IRQ_PEND and they can be used that way
<n01>
(or at least this is what is written in the user manual)
<mripard_>
which user manual? because I'm looking at it right now and don't see anything.
<_NermaN>
if i want to remove sdcard from cubieboard how to setup right boot configuration in nand?
vinifm has joined #linux-sunxi
<vinifm>
hi, i got these errors...
<vinifm>
include/asm-generic/gpio.h:223:2: error: implicit declaration of function ‘gpio_get_value’ [-Werror=implicit-function-declaration]
<vinifm>
include/asm-generic/gpio.h:229:2: error: implicit declaration of function ‘gpio_set_value’ [-Werror=implicit-function-declaration]
<vinifm>
stage/sunxi-3.0
<vinifm>
and more..
<vinifm>
drivers/spi/spi_sunxi.c:1835:2: error: implicit declaration of function ‘gpio_request’ [-Werror=implicit-function-declaration]
<vinifm>
drivers/spi/spi_sunxi.c:1836:3: error: implicit declaration of function ‘__gpio_to_irq’ [-Werror=implicit-function-declaration]
<vinifm>
I'm trying to compile the kernel
<Turl>
mripard_: ping
<mripard_>
Turl: pong
<Turl>
mripard_: Mike took the unification patches in clk-next, you might want to pick the dt part and submit it before the arm-soc merge closes :)
shineworld has joined #linux-sunxi
<mripard_>
not tonight
torqu3e has quit [Quit: torqu3e]
<Turl>
mripard_: it might need to be reworked though, the dtsi were split
<Turl>
mripard_: let me know if you want me to do it
<oliv3r>
mripard_: n01|work|afk i don't see any interupt section on A10 and A13 timer/wdt section either, just the 2 registers
<n01>
oliv3r mripard_: in the user manual v1.20 and yes we have just those two registers, nothing else
<oliv3r>
n01: but i don't see any interrupt reference there
<n01>
oliv3r: "Watchdog IRQ Pending. Set 1 to the bit will clear it"
<n01>
in WDOG_IRQ_PEND.
eebrah has joined #linux-sunxi
<mripard_>
n01: where is it?
<n01>
p.87
<oliv3r>
checking
<n01>
sec 10.3.2
<oliv3r>
Timer Interrupt Status Register
<oliv3r>
yes!
<n01>
:)
<oliv3r>
bit 8
<n01>
yeah
<oliv3r>
very good spot
<oliv3r>
:D
<n01>
lol .. tnx
<mripard_>
hmmm, true
<Turl>
I suppose you could have it interrupt and watch as linux complains to find the number :P
<n01>
:D I'll try
<oliv3r>
so using this as an example; (and i really have zero clue as how this is implemented, so i may talk senslessly here)
<oliv3r>
how would you tie in a single bit into the dt
<Turl>
a single bit?
<oliv3r>
i mean, you tell the dt that your driver will use address X ranging from this to that
<n01>
I don't know yet but mripard_ is the dt-guru at the moment :)
<Turl>
you would use a byte
<oliv3r>
but now, the Timer Interupt register has a spot for the WDT
<oliv3r>
well the single register (32bits) is shared between the timer and the wdt
<Turl>
there's a separate interrupt driver I think
<oliv3r>
ok, fine, i'm speaking as an example
<oliv3r>
say some other random register is shared with the timer
<Turl>
and then you use of_iomap(np, 0) to get the first and ...,1) for the second
<oliv3r>
Turl: but what about a bit
<Turl>
you cannot address a single bit
<Turl>
the min addressable unit is a byte
<oliv3r>
i know, but there's 2 drivers
<oliv3r>
and they both share the same register?
<Turl>
yeah
<oliv3r>
how do you handle this with dt
<Turl>
it could allow for race conditions now that I think of it
<oliv3r>
can two sections in dts have the same register mapped
<Turl>
oliv3r: you just use the same regs property for both?
<Turl>
yes
<oliv3r>
I guess it's the only way
<oliv3r>
mripard_: can you 'guard' against a racing condition in that case?
<oliv3r>
Turl: ok i am a noob when it comes to virtual memory mapping etc; but with a race, you mean two drivers writing to 1 register at the same time, right?
<Turl>
oliv3r yes
<Turl>
oliv3r: in fact some of the clocks on my driver use the same register to configure stuff
<Turl>
but the driver is serialized with a single lock so no races should occur
<oliv3r>
lock as in a mutex?
<Turl>
yes
<oliv3r>
(i'm a noob in regards to that too)
<oliv3r>
i guess the wdt would require that too then
rellla has quit [Remote host closed the connection]
drachensun has quit [Quit: Leaving]
Tartarus has quit [Excess Flood]
Tartarus has joined #linux-sunxi
drachensun has joined #linux-sunxi
^dst has quit [Ping timeout: 264 seconds]
<n01>
oliv3r: check the latest version of the driver ;)
eebrah has quit [Ping timeout: 240 seconds]
eebrah has joined #linux-sunxi
<oliv3r>
n01: refreshing
<oliv3r>
n01: oh nice!
<oliv3r>
n01: if i may be a nitpicker, WDT_MODE_TIMEOUT(0xf) :p
<oliv3r>
and i think drivername was better with the underscore, it matches the filename then
<oliv3r>
(i'm horrible when it comes to nitpicking to improve consitancy)
<oliv3r>
<- a little obsessive
<n01>
agree :) next step is the IRQ. I'll keep you posted
<oliv3r>
n01: i like your wdt_timeout map
<oliv3r>
i don't understand the assignment though
<oliv3r>
[1]= data
<n01>
yeah at the end like this is much better than the aw's one
<oliv3r>
is that array element 1?
<n01>
yep
<oliv3r>
never seen that in C
<oliv3r>
seen enum's done similarly
<n01>
not very common
<oliv3r>
not sure if checkpatch will like the spaces between .info and = &sunxi_wdt_info
<n01>
I'll check before submitting
<oliv3r>
and since you have a platform_device, maybe dev_info instead of pr_info?
<oliv3r>
n01: oh nice! devm_iounmap is what we should use?
<oliv3r>
n01: i think i have just plain iounmap (don't know which one to use)
<n01>
to unmapping memory. I think devm_* is wrapped for devices
<oliv3r>
i thought it was of_iomem
<oliv3r>
why do you have _exit_P on the .remove assignment?
vinifm has quit [Remote host closed the connection]
<n01>
of_iomem to map, *_iounmap to unmap :)
<n01>
just optimization ... if your driver is never removed than the code can be optimized away
<oliv3r>
well it would have made sense, of_iomem to map, of_iounmap to unmap
torqu3e has joined #linux-sunxi
<oliv3r>
n01: i know, i just find it odd to see at the assignment
<oliv3r>
i would have expected it to be up where all the __init's are
<oliv3r>
and __exit sunxi_wdt_remove is
<n01>
actually I haven't checked if of_iounmap does exist
<oliv3r>
or do you have to do it doubly
<oliv3r>
n01: it doesn't
<n01>
:D ok
<oliv3r>
and mripard_ told me to iounmap
<n01>
yep iounmap or devm_iounmap is pretty much the same
<oliv3r>
well there should be one appropiate, and the other one 'okay enough' :p
<oliv3r>
i think devm_ sounds more reasonable (and it calls iounmap internally eventually)
art103 has joined #linux-sunxi
<oliv3r>
n01: but really, I know nothing of all this, i just spend a lot of time digging through header files and reading ldd3 to figure out what I want/need
<oliv3r>
and still am not clear about a lot of things
<oliv3r>
but as said, i'm obsessive so want it 'perfect'
shineworld has quit [Remote host closed the connection]
eebrah has quit [Quit: Leaving]
<art103>
Hi all, I've just completed a CM10 port for my A13 tablet. It works booting the kernel from SD, then everything else from NAND, but I can not get the stock u-boot to boot my custom kernel. It just hangs after reading it out of NAND. Is this a known issue? Any suggestions?
<hramrach>
did you update script.bin as well?
<oliv3r>
art103: can you read debug from uart?
<art103>
Yes - I have that uart hooked up. There isn't any debug, it extracts the kernel from NAND, then runs boota on it and it hangs.
<art103>
I'm not sure what I'm looking at there... The same zImage and ramdisk (turned into uImage and uRamdisk) booted with an SD u-boot boots ok.
<art103>
It is just the stock u-boot that can't boot using boota (bootm is OK)
<art103>
There are 2 things that stand out when comparing bootm and boota in the stock u-boot source: NAND_Exit() and turning off the UART0 and UART1 clocks.
<n01>
:D ok, it is useless
paulk-desktop has quit [Quit: Ex-Chat]
<art103>
oliv3r, n01: Duh, new to IRC, sorry. Thought that message was to me!
<techn_>
art103: you could use sunxi-bsp:s mk_livesuit_img.sh :p
<art103>
techn_: Would that help me? The u-boot in git doesn't support NAND, so I would still be stuck with an SD card?
<art103>
Only the older ones. This D50W A13 has a later ID, which isn't supported in the lichee-dev u-boot (I tried). I also tried merging the sunxi-linux NAND updates without much luck.
<art103>
I'll take another look to see if it has been merged in.
<techn_>
ok.. then you could try to add your chip to lichee-dev
<techn_>
or try to use CONFIG_SUNXI_IGNORE_ATAG_MEM in kernel
<art103>
Yeah, I tried that. I hadn't realised that lichee-dev was still being updated. I'll take an update and see where it gets me.
<art103>
If I had seen yours earlier, it would have saved me a lot of time. Did you get csi0 working? I spent quite a bit of time merging sun5i_csi and sun4_csi into sunxi_csi.
<techn_>
no I havent got that far.. I have been fixing regression what have been found
<techn_>
but all of that has been in hold for 1-2 weeks.. been ill :(
<art103>
That's not good - I hope you're feeling better!
<techn_>
last two days.. much better :)
<art103>
:)
<art103>
Were you targetting a particular A13_MID?