<wingrime>
cedar2.c can read cedar register and do right IOCTL before
<oliv3r>
oh very neat
<wingrime>
but it so cedar reset every time it called
<wingrime>
so use cedar2.c for first
<wingrime>
it leave cedarx on
<wingrime>
than use devmem2.c
<oliv3r>
hno: YOu say you need sodlering iron, wire and a scalpel. Is it to break the trace between R24's two pads? r23 and r24 are not solderd, r24 has the coppy going between it, shorttening it; r23 is unpopulated
<oliv3r>
ok so we can also do cedar2x on; write registers for idct, read result, check data?
<oliv3r>
hno: also, one of the r23 pads connects to 2.5V
<wingrime>
yes
<wingrime>
oliv3r: but it better if you extend cedar2.c to make it jpeg Poc
<oliv3r>
maybe use cedar2c yeah
<oliv3r>
but i want to use pure libjpeg.so and 'hack in' jpeg poc
<oliv3r>
since allwinner also uses libjpeg; makes it much easier/logical
<oliv3r>
but i want to start by ONLY doing idct
<oliv3r>
idct only is easy and can be followed
<oliv3r>
hno: from the pcb it looks like it's 2.5V -> R23.1 - R23.2 -> R24.1 -> R24.2 -> GND
<oliv3r>
with - meaning open
<oliv3r>
so don't see T9 going anywhere, but my eyes are tired :p
<wingrime>
oliv3r: just include lib jpg
<wingrime>
oliv3r: i realy have no real example only for idct
<wingrime>
oliv3r: it do whole jpeg
<oliv3r>
bah
<oliv3r>
but i'm sure it's possible by the register names
<oliv3r>
i cannot imagine that cedar dus a full frame jpeg
<wingrime>
you just need configure , copy data and press "START"
<oliv3r>
lol
<oliv3r>
yeah
<oliv3r>
and for a start, that's awesome
<oliv3r>
aand I should write that soon :)
<oliv3r>
but
<oliv3r>
sec
<wingrime>
yes . but Mpeg engine clock init / reset still not in wiki
<oliv3r>
anyway, if we have idct only support
<oliv3r>
we can write generic fft using idct if i'm not mistaken
<oliv3r>
if we have generic fft, we can offload audio decoding too :)
<wingrime>
oliv3r: idct only can be done in 200 cup cycles , onlt it will have small impact
<oliv3r>
yeah but it's only as a PoC :)
<oliv3r>
and then there's context switches etc etc, so even offloading that is still nice :p
<wingrime>
olvi3r: I still have no Idea how do idct only (register bits)
n01 has joined #linux-sunxi
piyushverma has joined #linux-sunxi
piyushverma has quit [Ping timeout: 246 seconds]
<oliv3r>
wingrime: i'll try to find time to do full jpeg PoC
<wingrime>
oliv3r: can you upload you trace to cedarx-traces
<wingrime>
for mjpeg
<wingrime>
and mark it as a10
<wingrime>
if can do it on a20
<wingrime>
add a20 trace too
<oliv3r>
wingrime: we have a jpeg trace
<oliv3r>
the other guy made it
<oliv3r>
i haven't been able to make or replay a trace yet
<wingrime>
oliv3r: you upladed to cedar-trace only mjpeg file , nor trace itself
piyushverma has joined #linux-sunxi
leowt has joined #linux-sunxi
<leowt>
hno: it is the memory =P
<hno>
oliv3r, yes, the scalepl is for breaking R24, and the wire is for making a 0R resistor on R23.
<hno>
R35 (next to R23) is also interesting. That's JTAG_SEL.
<hno>
leowt, your speed problems?
<leowt>
hno: yep
<leowt>
MemFree: 2592 kB
<leowt>
doesnt help much
<leowt>
xD
<leowt>
MemTotal: 362044 kB
tzafrir has joined #linux-sunxi
<oliv3r>
ssvb_: funny to see you on phornonix :)
<oliv3r>
leowt: that's more then i have, i think mine is at 315 M normally
<oliv3r>
leowt: but memfree is of course before caches
<ssvb_>
oliv3r: :)
<leowt>
oliv3r, anyways i am good to see that it is not a 2d acell problem
<oliv3r>
and yeah that was me :p but i'm sure you guessed it
<leowt>
=)
<oliv3r>
leowt: the big advantage with 1G is, that you only have to substract the video memory once; so you actually really get 512 additional mb
<oliv3r>
so you'll end up with 700 or 800 free MB which is plenty
<oliv3r>
300 MB is just very tight
<leowt>
yep
<leowt>
i can see that
<leowt>
by the way
<leowt>
is allwinner getting friendly over the work being done over their abandoned kernels?
<leowt>
how is that relationship?
<oliv3r>
that specific one, very bad :0
<oliv3r>
we've done a lot of work on 3.0 and 3.4 kernels
<oliv3r>
tehy didn't use those, they simply continued with their own kernels
<leowt>
or not using at all
<leowt>
xD
<leowt>
u just dont understand
<leowt>
* i just
tinti_ has joined #linux-sunxi
<leowt>
so much dirty work was fixed
<oliv3r>
not using at all; not even patches that fixes horrid bugs
<leowt>
they would only gain
<oliv3r>
on the upside, we now have a20 hardware slowly getting into develoeprs hands
<oliv3r>
so we can backport/merge new drivers
<leowt>
and the vendor relation continues to be the same?
<leowt>
it seems like rockchip is about to take a more friendly approach
<leowt>
well, i mean legal approach
<leowt>
xD
<oliv3r>
leowt: how so?
<oliv3r>
does it have an unsigned bootloader?
<leowt>
dunno yet
<oliv3r>
full GPL sources?
<oliv3r>
GPL video decoder?
<leowt>
but i would only ask for sources
<leowt>
even with blobs
<leowt>
like the other vendors
<oliv3r>
we only currently have 2 blobs with allwinner; mali (duh) cedarx userspace
<leowt>
yeah but we still have to wait until someone release the source
<leowt>
and a unmaintained one
<oliv3r>
leowt: allwinner has released source
<oliv3r>
they gave us their git tree
<oliv3r>
what more could you want?
<oliv3r>
all gpl licensed
<leowt>
wen?
<leowt>
when?
<oliv3r>
so technically; they are quite compliant
<hno>
Allwinner frequently releases full kernel + u-boot sources.
<oliv3r>
a few months ago, march 2nd or so
<hno>
we have A20 sources later than that.
<oliv3r>
it's up on amery's github under the import/lichee-3.3/ bits
<oliv3r>
and that!
<leowt>
because i remember the times
<leowt>
that i was here
<leowt>
a10
<leowt>
there was no official sources
<oliv3r>
the only 'better' thing that could happen with that regard, is give is git fetch access :) (read-only)
<hno>
Allwinner released A10 kernel + u-boot sources before this channel existed.
<leowt>
hmm
<leowt>
so i was confused than
<leowt>
*then
<oliv3r>
Turl: anti-pattern! andy responded what it is, it's instead of: if (statement); if (!statement) (see his respons for details
<lioka>
wrt 8192cu: sunxi-v3.4.43-r0 contains v3.3.2_3192.20120103 version, although v3.4.4_4749.20121105 is available
<lioka>
is there anyplans to update things ?
<oliv3r>
those look really old
<oliv3r>
oh 8192cu
<oliv3r>
erm, what's upstream status for it?
<oliv3r>
does upstream have full 8192cu sources?
<oliv3r>
if so, backport them and submit them to the ML; mnemoc will happily merge them
<lioka>
oliv3r: by upstream you mean ?
<oliv3r>
vanilla linus 3.11 kernel
<oliv3r>
Turl: ping
<rm>
upstream is rtl8192cu
<lioka>
oliv3r: it is full-sized rtlwifi there, i doubt it is doable honestly
<rm>
linux-sunxi has both rtl8192cu and 8192cu
paulk-desktop has joined #linux-sunxi
<rm>
the latter is directly from Realtek, I assume
<oliv3r>
lioka: well feel free to submit a patch porting the newest 8192cu to 3.4 for us
<oliv3r>
rm: i would agree
<lioka>
rm: yes, i mean RTL8192CU_SW
<oliv3r>
so lioka i would suggest trying rtl8192cu :)
<lioka>
oliv3r: tried on hackberry, doesn't seem to work. 8192cu otoh works, but now i've got another pad with rtl8188, and things went really bad
<lioka>
as for patching newest realtek sources to sunxi-3.4 -- there are some sunxi-related tweaks, it seems
<rm>
sooo you want someone else to dig into that mess
<rm>
the plan is to abandon 8192cu completely
<rm>
if it works for you, then just be happy
<rm>
that it is not removed yet
<rm>
no use chasing the latest version just for the sake of it
<oliv3r>
the quicker you can use the vanila version, the sooner
<oliv3r>
the better*
<lioka>
i see. well, that's what i want to know
<oliv3r>
if ours is to old, you can try backporting it
jemk has joined #linux-sunxi
<lioka>
yep. may i suggest, that there is no sunxi-specific other than script_parser_fetch("usb_wifi_para", ... or sw_usb_enable|disable ... -- that sort of stuff ?
<lioka>
s,suggest,assume, sorry
<oliv3r>
yeah, all drivers need that hacked in
<oliv3r>
until we move to sunxi-next
<oliv3r>
which will be devicetree dependany
n01 has quit [Ping timeout: 255 seconds]
leowt has quit [Quit: leowt]
<Turl>
lioka: I updated the realtek one some time ago, sec
<hno>
rm, I have never got the vanilla driver to work reliably with the rtl8188cus, annoys me greatly. Backported rtlwifi from upstream but still no joy (but a bit better).
<oliv3r>
mripard_: ok i'll change it to be not required and pass it as var along
<Turl>
I don't see the other issue, at least not looking just at that function
leowt has joined #linux-sunxi
<Turl>
oliv3r: the thingis, you're not exporting it today. so it's like overengineering :) if you ever need to export it you can add the pointer
<Turl>
thing is*
<oliv3r>
Turl: yeah i went with mripards version! :p
<oliv3r>
you people just don't like german cars do you :p
<mripard_>
oliv3r: the point I was trying to make was not a technical one actually. On a general basis, when you feel that the way the comment goes is not the one you want, say it
<oliv3r>
german overengineering!
<mripard_>
don't discard it
<oliv3r>
mripard_: sorry :(
<oliv3r>
mripard_: you are right of course
<mripard_>
it just pisses off people for nothing, while we could have a nice discussion about this part
<mripard_>
and actually agree :)
<oliv3r>
yeah, but i'm just this little dev in the land of the giants
<mripard_>
Most of the time, it doesn't matter
<mripard_>
as long as you ask for explanations
<oliv3r>
yeah but when you feel insignificant, you only look up :)
<mripard_>
everyone has to start at some point :)
<hramrach_>
stand on a piece of furniture ;-)
<oliv3r>
lol
<Turl>
hramrach_: hahah
<oliv3r>
mripard_: i don't find rullel commenting specifically on the global far, only that it was non-static at some point accidentally
<hno>
Turl, look at offset.
<oliv3r>
where I did reply it wasn't supposed to be static
<oliv3r>
offset <= SID_SIZE
<hno>
Yes. What values can offset have?
<oliv3r>
0 - SID_SIZE
<hno>
No, what values can offset have?
<hno>
not which values are valid.
<lioka>
hno: 8188cus
<mripard_>
oliv3r: "
<mripard_>
So what happens if you have two of these devices?"
<oliv3r>
mripard_: ah yeah, i completly forgot about that, not ignored!
<Turl>
hno: ~ -MAX_INT/2 - MAX_INT/2? or does the const play tricks on us?
<hno>
const does not matter.
<oliv3r>
hmm, very good point, I do the size > 0 and offset < SID_SIZE on line 78 in the sysfs read function, but if you do it 'internally' you can poke anything in there
<oliv3r>
so you could have negative numbers there indeed
<Turl>
hno: should be unsigned int right? so <0 does not happen
<hno>
unsigned int is easier to deal with yes.
<Turl>
also would prevent funny values when >>
<hno>
oliv3r, the other if is also botched. if (likely(size > 0) && ((size + pos) <= SID_SIZE)) {
<Turl>
nvm my last comment
<oliv3r>
pos could be negative
<Turl>
sid_key is unsigned already
<hramrach_>
hehe, picking apart a poor driver
<oliv3r>
yeah but you only ioread into that
<oliv3r>
hno: so the proper thing is to put guards in both places then
<Turl>
oliv3r: or just make it unsigned :) guaranteed it'll never be negative
<oliv3r>
Turl: allready done :p
leowt has quit [Quit: leowt]
<hramrach_>
you need jdk 1.6 for android build? the reals thing? not openjdk, not 1.7? /o\
<Turl>
hramrach_: openjdk works just fine
<Turl>
that's the buildsystem bitching only :)
<hramrach_>
1.6 or 1.7?
<oliv3r>
Turl: to come back to your question, is it not nicer to have that antipattern there; I think i prefer in this case the 'pattern' there. Only run do_something(); when you are within your parameters
<oliv3r>
Turl: you say 'in this confeined space are you only allowed to do something'
<Turl>
hramrach_: I think I'm using 1.7 atm, pretty sure .6 works too
<hramrach_>
1.6 is *old*
<oliv3r>
Turl: whereas the other way around you say, 'you fail if you don't, otherwise, do what you want'
<hramrach_>
but I would not be surprised if you required something that was current at the time ICS was developed
<hramrach_>
the matson-hall repo is correct or is there one more recent one?
<Turl>
oliv3r: if you ever worked with specification, theorems and that kind of stuff, the antipattern looks more like a precondition
<hno>
oliv3r, I would drop the sid_read_byte function, it's only 2 lines if ignoring the double conditions..
<Turl>
hramrach_: if you're building ics you'll probably need openjdk6
<hramrach_>
it says to build ics on the Android guide
<hramrach_>
I don't really care what version comes out as long as it's bootable
<oliv3r>
hno: well the idea was that you can export the read function so you can call it elsewhere, use it as Key or MAC for example (if not 0) or an eeprom framework even
<hno>
Ok. Yes then it's needed. And likewise the static pointer.
<oliv3r>
I added a comment clarifying the global pointer
<oliv3r>
* To have sunxi_sid_read_byte not depend on any other parameters we keep a
<oliv3r>
* pointer here. This allows sunxi_sid_read_byte to be exported if needed.
<hno>
Note: only used when mandatory due to hardware design etc...
<hramrach_>
it's mandatory due to hardware design :/
<hno>
- environment ("ethaddr", "eth1addr", ...) (see CONFIG_ETHADDR)
<hno>
Note: this is the preferred way to permanently store MAC addresses
<hno>
But will likely add something for the A20 OLinuXino, it actually have a real MAC address EEPROM. But the I2C driver needs to be improved a bit first.
<mripard_>
ho, about the i2c
<mripard_>
it's the same controller than the one used in the marvell chips
<oliv3r>
mripard_: have you confirmed this allready?
<mripard_>
only with a slightly different register layout
<mripard_>
oliv3r: yep
<oliv3r>
cool
<oliv3r>
will you merge them or merge them later?
<oliv3r>
never saw the answer to your qquestion
<mripard_>
I don't know, I'm waiting for Wolfram answer
<hno>
mripard_, I know they are similar. But learnt it after the driver was written.
<mripard_>
same thing here
<bfree>
Complete build of working 3.10 Debian package with EMAC from net-next is now up at http://dl.linux-sunxi.org/users/niall/3.10+emac/ It supports nbdroot anyway. / on nfs should also be fine but I didn't test it. armmp is the kernel flavour for sunxi.
<hno>
and iirc there is some other small differences, not only register offsets.
<mripard_>
I didn't catch any
<hno>
oliv3r, file I/O is expected to return what is possible. Not reject all if you try to read more.
<oliv3r>
hno: yeah i allready changed it to your suggestion, it's much better
n01 has quit [Ping timeout: 256 seconds]
leowt has quit [Quit: leowt]
<hno>
mripard_, looked again, and differ in register offsets, clocking and the sunxi have some more functions (none used)
<Turl>
bfree: great :) thanks
<bfree>
Turl: well thank you for discovering how I could confirm it really works ;)
<mripard_>
hno: yeah, the enhanced feature thing
<mripard_>
the newer versions of the marvell controller have some kind of extensions to have a saner behaviour and not get an interrupt each time you have to do something
<mripard_>
also
<mripard_>
maybe the two are related, I'd need to look closer on this.
<mripard_>
what clocking changes are there?
<mripard_>
when I looked at it, the clock computation function looked like what was documented into the allwinner datasheet
jemk has quit [Read error: Operation timed out]
<hramrach_>
hmm, there seems to be jb-cubieboard branch but repo init refuses to use it
<jemk>
its far away from an real libjpeg replacement, but its poc
<ssvb_>
jemk: looks great, thanks
leowt has joined #linux-sunxi
<ssvb_>
jemk: can you try to document it on the wiki?
_BJfreeman has joined #linux-sunxi
_BJfreeman is now known as BJfreeman
<ssvb_>
jemk: I mean the things that are done in set_quantization_tables(), set_huffman_tables(), etc.
<jemk>
i'll try, but especially these things are hard to explain
<ssvb_>
thanks!
<ssvb_>
the purpose of the hardware registers, the valid range of input data and corner cases cedarx can accept, the way how these registers are linked to the data structures described in jpeg spec, ...
<ssvb_>
jpeg is a rather simple, so it can be used for practice before moving to more difficult codecs
<jemk>
valid ranges corner cases, good question, i dont really know yet
<ssvb_>
I believe these can be tried with specifically crafted input files
<Turl>
lioka: the one on linux-sunxi is 'sanitized' I think
tinti has joined #linux-sunxi
<Turl>
lioka: you can diff with -w
<ssvb_>
jemk: it does not mean that you should do really extreme experiments, but we preferably would want to know whether cedarx can deal with the common jpeg bitstream variants used in the wild
<ssvb_>
btw, is arithmetic coding not supported at all?
tinti has quit [Remote host closed the connection]
<jemk>
progressive didn't work
<hno>
mripard_, to verify that the I2C bus is idle.
<jemk>
i didn't test arithmetic coding
tinti has joined #linux-sunxi
<jemk>
as said, its only first proof of concept
<ssvb_>
yeah, it is a really great milestone (after a working cedarx tracer), I just wondered about what are your next plans
<hno>
mripard_, but looking at that code again I do not think it works....
<mripard_>
hno: which code?
<mripard_>
the mv64xxx one?
<mripard_>
I have some patches here that ran and i2cdetect/i2cdump successfully yesterday
<mripard_>
I don't have my logical analyzer here however
<mripard_>
so it need to be confirmed
<mripard_>
but it looks ok
<hramrach_>
maybe the code to check bus status
zumbi_ has joined #linux-sunxi
zumbi_ is now known as Guest99492
<hramrach_>
hmm, gihub is suposed to be online but android still does not sync
jemk_ has joined #linux-sunxi
<hramrach_>
maybe they hav a download limit? the andriod stuff is large and seems to be fetched fully again when re-synced
piyushverma has quit [Ping timeout: 246 seconds]
zumbi has quit [Ping timeout: 246 seconds]
jemk has quit [Ping timeout: 246 seconds]
jemk_ is now known as jemk
n01 has joined #linux-sunxi
<ssvb_>
jemk: sorry for pestering you, I'm just too excited and the first fully open source proof of concept hw accelerated jpeg decoder is a really great news
* ssvb_
shuts up
<hno>
mripard_, my code using lctl
drachensun has quit [Quit: Leaving]
<jemk>
ssvb, np, ill do more when i have time, but i have to do other things too
<Turl>
ssvb_: that reminds me I need to post my SS proof of concept tools :p
<leowt>
rz2k: tnks, gotta go now, but will be back soon
leowt has quit [Quit: leowt]
eebrah|away is now known as eebrah
<hno>
rz2k, ext4 on mtd?
tzafrir has quit [Ping timeout: 260 seconds]
<rz2k>
just for testing mtdblock
<rz2k>
(i know that ext4 on mtd is superbad idea)
tinti has quit [Quit: Leaving]
<hno>
ext4 on mtd is not a superbad idea by definition, but mtdblock on mtd is...
tinti has joined #linux-sunxi
rellla has quit [Remote host closed the connection]
jemk has quit [Quit: bye]
hramrach_ has quit [Ping timeout: 240 seconds]
hramrach_ has joined #linux-sunxi
shineworld has joined #linux-sunxi
shineworld has quit [Quit: Leaving]
gzamboni has quit [Read error: Operation timed out]
<oliv3r>
what is the difference between ext4 on mtd, and ext4 on mtdblock on mtd?
<oliv3r>
also, ext4 on mtd is no issue at all; if its read only :)
tzafrir has joined #linux-sunxi
wingrime has quit [Read error: Operation timed out]
<hno>
oliv3r, you can't do block filesystems such as ext4 on mtd.
<hno>
you need a FTL between.
<oliv3r>
but isn't ext4 a block fs?
<hno>
mtdblock is the simplest possible FTL you can make.
<hno>
yes ext4 is a block filesystem. So it can't run directly ontop of mtd.
<oliv3r>
well you said 'ext4 on mtd is not superbad; but mtdblock on mtd is
<hno>
Yes.
<oliv3r>
i thought, as you said, you always need mtdblock inbetween
<oliv3r>
so it confused me
hramrach_ has quit [Ping timeout: 240 seconds]
<hno>
ext4 on mtdblock on mtd is extremely superbad idea, but it's not really ext4 fault.
<hno>
anything on mtdblock is a bad idea, even read-only.
eebrah is now known as eebrah|away
<oliv3r>
why even when read-only?
<oliv3r>
I mean, you only write once, after that, it shouldn't matter any longeR?
notmart has quit [Quit: notmart terminated!]
<hno>
because even if only reading you still need to relocate blocks and in most cases also handle bad blocks somehow. Reading from a NAND wears the data stored in the accessed page(s) so you need to periodically rewrite it. Erasing a block wears the NAND cells as such.
<oliv3r>
ah ok that makes perfect sense
<oliv3r>
except for the 'relocating blocks after read'
<hno>
meant reloate pages/sectors. nand uses block for a larger element..
<oliv3r>
yeah erase blocks
<oliv3r>
but if you don't write, i don't see why you have to relocate them
<hno>
because the stored levels in the NAND cells gets worn out the more you read.
<oliv3r>
i know they wear from writing, didn't know from reading
<oliv3r>
ah, didn't know that
<oliv3r>
NOR doens't have that problem does it
<hno>
It's mainly a problem for MLC cells.
<oliv3r>
ok, learned something again :)
<oliv3r>
mripard_: i did find 1 use for sunxi; but it's used internally; the entropy fill is done in the same driver
<oliv3r>
mripard_: so technically, 2 users, the sysfs read + entropy
paulk-desktop has quit [Quit: Ex-Chat]
<hno>
oliv3r, entropy fill from where?
tkoskine has quit [Ping timeout: 248 seconds]
<oliv3r>
linus actually suggested to use the sid to fill the kernel entropy pool with
tkoskine has joined #linux-sunxi
<oliv3r>
even if it can be 0 on some devices, it's still okay to do it
<oliv3r>
that way, you have device specific 'random' entropy added to your kernel pool
<oliv3r>
quite nifty
<oliv3r>
i think it's safe to say that our sid's are 'random' enough for this purpose
<hno>
it's not random. Highly predictable. But OK as a one-time seed to the entropy pool.
<oliv3r>
how is it highly predictable?
<oliv3r>
i haven't found a pattern for bits 192-256 yet
<oliv3r>
the other bits do follow some pattern
<oliv3r>
0x4848 seems to be something specific to a10 and a20 aswell a10s and a13 use 7030 and 3030 respectivly there
<bfree>
and ftr < BTS> Opened #711998 in linux-image-3.10-rc4-armmp 3.10~rc4-1~exp1 by Niall Walsh <niallwalsh@users.b...> «net: Add EMAC ethernet driver found on Allwinner A10». http://bugs.debian.org/711998
<hno>
oliv3r, yes.. Olimex is already past that barrier which helps. But they dod not get any programming information.
<hno>
Wasn't aware they even got information on what voltage to connect. But they must have got that 2.5V from somewhere.
<oliv3r>
yeah
<bfree>
there really are tooooo many sunxi boards/targets now in u-boot sunxi-current, build time gone through the roof ;)
<hno>
bfree, I know... and there will be more.
<oliv3r>
i'm really gonna try to work on dram read from mmc (raw); should reduce it enormously
<hno>
Just having it in a identified section of the SPL is sufficient.
<bfree>
I'm clueless about them ... I kinda presume it's going to have to wait now for 2013.10 at the earliest?
<hno>
All of it is not possible in that timeframe. But maybe the core support can make it so that it's at least possible to boot boot0->boot1->u-boot->serial load. maybe even tftpboot.
<hno>
SPL support and MMC driver needs a fair bit of work.
<oliv3r>
but if you inject it into a header, you need tomodify your binary. if we reserve 1k beteween spl and u-boot for example, we can have a static exe
<hno>
what is the difference? We do add a header anyway.
<hno>
and if it's in the header then it will be loaded automatically at a known location in memory.
<oliv3r>
you only write a small blob too the mmc?
<oliv3r>
1 binary per platform people can dl and use, unmodified, md5-able
<hno>
I build u-boot-spl.bin, then pass that to mksunxiboot which adds the header.
leowt has joined #linux-sunxi
n01_ has quit [Ping timeout: 248 seconds]
<hno>
in theory there can be one single u-boot-spl.bin for all a10+a13+a10s+a20 boards, but one for each soc generation is no problem at all.
<leowt>
Turl: u there?
<bfree>
hno: thanks for the update (and your work in general on it of course)
<hno>
bfree, thanks.
<oliv3r>
right now, only dram settings are diff per gen
<hno>
but I only looked in schematics, haven't looked at what is on the board.
<rz2k>
Turl: nope, that wasnt me, I dont usually do android stuff
<Turl>
rz2k: it was techn, just checked
<Turl>
leowt: any specific thing you need help with?
<leowt>
im trying to figure out what specific bits go into android source from the hw vendor. i am reading some doc about android's architecture to get to know it better
<leowt>
Turl: will ping you tomorrow, what is your local time?
<Turl>
leowt: GMT-3, 20:20 now
<leowt>
Turl, cool, tomorrow then, tnks ;)
tinti has quit [Remote host closed the connection]