<stekern>
I also notice that there seems to be no nand support in https://github.com/linux-sunxi/u-boot-sunxi, so has the situation been the same for sun4i/sun5i and that's why it's (naturally) not included in the github tree?
<derethor>
i remembered that the bus pirate has a 3.3v uart monitor
<derethor>
so, i found why i can not boot... the kernel was in the wrong partition
<derethor>
:)
<derethor>
nice, tomorrow i will make an initrd with a busybox
<derethor>
btw, the a13 is really hot, i think it needs some kind of cooling
<derethor>
it runs at 1Ghz
<rz2k>
stekern: there is no opensource nand driver for sun6/7i
<rz2k>
but we have mtd nand driver from yuq for A10
<rz2k>
stekern: also sun4/5i had nand block driver from allwinner, it is in drivers/block/sunxi_nand, if you want - you can try to run it
_BJFreeman has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
BJfreeman has quit [Read error: Connection reset by peer]
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
_BJFreeman has joined #linux-sunxi
BJfreeman has quit [Ping timeout: 252 seconds]
_BJFreeman is now known as BJfreeman
stekern has quit [*.net *.split]
Soru has quit [*.net *.split]
arete74_ has quit [*.net *.split]
theborger has quit [*.net *.split]
jinzo has quit [*.net *.split]
fredy has quit [*.net *.split]
n01|away has quit [*.net *.split]
cajg has quit [*.net *.split]
jelly-home has quit [*.net *.split]
hramrach_ has quit [*.net *.split]
Soru has joined #linux-sunxi
stekern has joined #linux-sunxi
arete74_ has joined #linux-sunxi
fredy has joined #linux-sunxi
jinzo has joined #linux-sunxi
theborger has joined #linux-sunxi
n01|away has joined #linux-sunxi
hramrach_ has joined #linux-sunxi
cajg has joined #linux-sunxi
jelly-home has joined #linux-sunxi
stekern has quit [*.net *.split]
Soru has quit [*.net *.split]
arete74_ has quit [*.net *.split]
theborger has quit [*.net *.split]
jinzo has quit [*.net *.split]
fredy has quit [*.net *.split]
stekern has joined #linux-sunxi
fredy has joined #linux-sunxi
Soru has joined #linux-sunxi
jinzo has joined #linux-sunxi
arete74_ has joined #linux-sunxi
theborger has joined #linux-sunxi
rz2k has quit [Read error: Connection reset by peer]
tzafrir has quit [Ping timeout: 240 seconds]
rz2k has joined #linux-sunxi
BJfreeman has quit [Quit: had a good time]
rz2k has quit []
\\Mr_C\\ has quit []
mturquette has joined #linux-sunxi
wingrime has joined #linux-sunxi
_whitelogger_ has joined #linux-sunxi
eebrah|away has joined #linux-sunxi
wingrime has quit [Ping timeout: 264 seconds]
<oliv3r>
rain + 22C in the morning. nice
<oliv3r>
almost got poured on while riding to work
n01|away is now known as n01
Soru has quit [Quit: No Ping reply in 180 seconds.]
Soru has joined #linux-sunxi
memeka_ has joined #linux-sunxi
<memeka_>
hi, this is a mali issue that might be of interest to sunxi as well: http://forums.arm.com/index.php?/topic/16860-bad-performance-on-38-kernel/
<rm>
enjoy your proprietary blobs
<memeka_>
i think the issue is in the open source mali driver
memeka_ is now known as memeka
<memeka>
just wondering if a similar issue popped out in the 3.6 kernel...
<rm>
most people use 3.0 or 3.4 on sunxi currently
<memeka>
3.4 then :)
<memeka>
the issue is 2x the number of ioctls done for a GP job
<oliv3r>
rz2k stekern; both gone; we have nand sources ;) lkcl got them from AW (with GPL header) and sent them to various people, just need to be merged
<oliv3r>
libv probably has noticed/fixed/worked around that in the way more important lima driver ;)
<memeka>
what's the status of lima?
dl9pf has quit [Remote host closed the connection]
<oliv3r>
memeka: 6% faster then mali :)
<memeka>
is lima replacement for libMali? or the entire stack?
memeka has quit [Quit: Page closed]
rellla has joined #linux-sunxi
tzafrir has joined #linux-sunxi
rellla2 has joined #linux-sunxi
<stekern>
oliv3r: I wasn't gone ;)
<stekern>
that sounds good
<oliv3r>
stekern: but the driver is nearly identical to what we had in the past
Soru has quit [Ping timeout: 248 seconds]
Soru has joined #linux-sunxi
cnf has left #linux-sunxi ["Leaving"]
<stekern>
my immediate problem is that I want to load a custom built linux kernel into memory from u-boot
<stekern>
I can't use sdcard, since the console is attached to that
notmart has joined #linux-sunxi
notmart has quit [Changing host]
notmart has joined #linux-sunxi
<stekern>
so I though I'd put it on the filesystem on one of the nand partitions (nanda for instance), but that didn't go too well with the nand blob...
<stekern>
*thought
<stekern>
I guess I can put it as a raw image in the recovery partition
<hno>
stekern, should work fine to put it in nanda if there is sufficient space.
<stekern>
hno: yes, but how do I read it from (AW flavour) u-boot?
<rz2k>
stekern: iirc you can read/write AW's nand with standard 'nand' command if you have theirs libnand compiled in, check the default envorinoment.
<rz2k>
it somehow reads the uImage from nanda
<rz2k>
also again about MTD driver - there is yuq's MTD driver for u-boot, you can port that to a31 and use, it also generates boot0 replacement that you can write in with livesuit image
<rz2k>
but that will indeed need normal serial console available
<stekern>
AW's sunxi_nand command reads the android.img from nandc (boot partition)
<stekern>
it can also read the recovery image from nandg
<rz2k>
hmm
<stekern>
I tried dumping nanda to memory with sunxi_nand, but libnand bailed out
<rz2k>
i remember Amery launching uImage from nanda on his hardware when we had no u-boot sources in working status
<rz2k>
that was for A10
<oliv3r>
stekern: mmc-uboot doesn't know about nand; only boot0/1/aw-u-boot
<oliv3r>
sunxi-uboot is mmc only for now
<stekern>
oliv3r: yeah, I've understood that, I'm using aw sun6i u-boot with libnand blob though
<oliv3r>
well remember sun6i .... needs tons of work here still :)
<oliv3r>
lkcl: get us DRAM controler 'user manua' even just register names/description would be enough ;)
dl9pf has joined #linux-sunxi
dl9pf has joined #linux-sunxi
<hno>
stekern, fatread
<hno>
oliv3r, lkcl, a31 boot0 sources is quite sufficient. Not in a mood of decompiling boot0 again.
<oliv3r>
hno: don't we have those again?
<oliv3r>
hno: i actually ment a10/a20 sources
<oliv3r>
so i can put a name to registers etc :)
<oliv3r>
registers + bits
<oliv3r>
we still have quite some 'random' bits that have leittle meaning
<oliv3r>
hno: in the leaked sources we actually have boot0 for sun6i
<oliv3r>
just need those copyrighted properly
<oliv3r>
lkcl: ^
<stekern>
hno: ok, I think there are some differences between how the sun4i/sun5i and sun6i aw u-boot work in that regard
vicenteH has quit [Ping timeout: 240 seconds]
<stekern>
sunxi_flash (sorry I wrote it wrong above) is pretty much decoupled from the nand subsystem and thus also from the fatread subsystem
rzk has joined #linux-sunxi
rz2k has quit [Ping timeout: 264 seconds]
<hno>
stekern, I noticed that, but thought it was still available as ablock device.
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
<stekern>
perhaps I can hack it into being
<stekern>
because it actually doesn't look that different from what'
<stekern>
s in sun4i/sun5i
BJfreeman has quit [Read error: Connection reset by peer]
Soru has quit [Quit: No Ping reply in 180 seconds.]
<oliv3r>
(all of it, i copy pasted that line for no appearant reaeson
sud0x3 has quit [Quit: Leaving]
\\Mr_C\\ has joined #linux-sunxi
<oliv3r>
hno: btw, is there a reason you don't use --signed-ff?
<oliv3r>
i noticed a few commits in the logs without it
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
tinti has quit [Quit: Leaving]
<hno>
oliv3r, yes it's directly related to the bus width. #DLLCR = bus_width / 8 + 1
<hno>
oliv3r, I only add Signed-off-by on patches I touch.
<oliv3r>
ah, your watchdog fix didn't have it i think
<oliv3r>
or 349ad6a093029627fe623c5d0ccc0c6dbd9dba58349ad6a093029627fe623c5d0ccc0c6dbd9dba58 neither :)
<oliv3r>
349ad6a093029627fe623c5d0ccc0c6dbd9dba58
<oliv3r>
hno: ah, so 32bit = 5; 16bit = 3 (as can bee seen) but 8 bit is 2? 8/8 = 1 + 1 = 2?
<oliv3r>
i would have expected 1
<oliv3r>
:)
<hno>
Right. often forgot to add one on my own small changes.
<hno>
I would expect 2.
<hno>
but never seen a device with 8-bit dram bus.
<oliv3r>
well
<hno>
1 per 8 bits of data.
<hno>
+ 1
<oliv3r>
5:3:1 makes more sense then 5:3:2 i guess (mathematically)
<hno>
no.
<oliv3r>
64bit would be 7! :)
<hno>
64 bit would be 9
<hno>
64/8 + 1 = 9
<oliv3r>
1:3:5:9
<hno>
dllcr0 is special. And there is one dllcr per 8 bits data.
<hno>
which is the per-chp bus width.
<oliv3r>
ah, that sounds more logical
<oliv3r>
'special' :)
<oliv3r>
but yeah I did see it
<hno>
actually I would expect A31 to have 10.
<oliv3r>
10 dllcr's?
<oliv3r>
not 9?
<oliv3r>
64bit is 9 though
<hno>
A31 have a dual channel SDRAM controller, so I would expect it to have two DLLCR0.
<hno>
but haven't looked at it yet.
<oliv3r>
ah ok
<oliv3r>
so how does this relate to interleaving
<oliv3r>
i thought that you can have multiple chips per bank
<oliv3r>
and thus use interleaving to 'raid' it sort of
<oliv3r>
does A13 not have 1 8 bit chip? or does even a13 have 2 chips?
<hno>
banks is within a chip.
<oliv3r>
ah ok
<oliv3r>
sorry
<oliv3r>
only know the very very basics
<oliv3r>
though the a13 olinuxino-micro has 1 16bit chip
<oliv3r>
so it would be an a10 device with only 128 MiB ram
<oliv3r>
technically possible still :)
<hno>
There is much smaller chips available if you want one..
Kadosch has joined #linux-sunxi
<oliv3r>
well 8 bit bus i ment mostly
<stekern>
oh, this whole fatload nand.. thing is an 'aw-extension', completely handled by libnand
Tartarus_ has joined #linux-sunxi
<stekern>
wonder why that doesn't work out of the box for me, by a quick look at the disassembly of libnand it looks like the sources in u-boot-sunxi/lichee-dev
tinti has joined #linux-sunxi
Tsvetan has joined #linux-sunxi
<oliv3r>
hey Tsvetan
<Tsvetan>
hi
<oliv3r>
Tsvetan: can you confirm/deny that the a20 nand comes with the assumptions an LCD or something is used? e.g. no hdmi by default?
<Tsvetan>
A20 NAND is preloaded with Android and both LCD and HDMI are enabled by default
<Tsvetan>
A20 have two video channels and can have both HDMI and LCD at same time not like A13/A10S
<hramrach_>
same kernel builds when I build it separately without the andriod build system. At least I think it's the same on. I don't know how to check that it's really identical because repo makes bare repos and archives, not checkouts.
<oliv3r>
Tsvetan: then i have to figure out why mine won't boot nand to HDMI
<oliv3r>
hramrach_: haven't build the android kernel forever
<hramrach_>
yes, it's the same kernel
<hramrach_>
repo does actually make some wier checkout without branch info but the tree is identical
<Tsvetan>
oliv3r does it boot Linux?
Tartarus_ has quit [Quit: Ex-Chat]
<oliv3r>
it boots the kernel about half way through
<oliv3r>
but can't see why it fails
<oliv3r>
i posted it a while ago; i'll check again tonight
<Tsvetan>
we have now A20 Linux image in our Wiki, you can put on SD card and check if the hardware is working
<Tsvetan>
while A10 works with the DDR up to 480 Mhz A20 can work just up to 380Mhz at least the A20 samples we got from Allwinner refuse to work at higher DDR3 settings
<hno>
mine boots fine, but have not tried to connec the HDMI yet.
<hno>
Cubieboard2 uses higher frequencies for DRAM, but their layout is a lot more compact.
<Tsvetan>
hno higher than 480Mhz?
<hno>
no. higher than 380.
<Tsvetan>
it may be other A20 version
<Tsvetan>
as same layout works on A10 up to 480Mhz so its not layout problem :)
n01 has quit [Ping timeout: 248 seconds]
<hramrach_>
hmm, it's the toolchain
<hramrach_>
recent 3.4 linux-sunxi does not build with jellybean gcc
<hramrach_>
or maybe there are some additional environment settings not shown by make
<hramrach_>
actually, there aren't. it fails all right with the settings shown
<hno>
Tsvetan, the Cubieboard2 I got has 432MHz DRAM clock. And there is an image available for download with 480MHz (haven't tried).
<Tsvetan>
hno: we got very early samples of A20
<hno>
I suspected so. Their SID is blank..
<hramrach_>
ok, maybe time to try another repo
<Tsvetan>
Im waiting new lot of A20 and will compare the silicon marks and then we will see if they will work at higher freq too
Tartarus_ has joined #linux-sunxi
Tartarus_ has quit [Remote host closed the connection]
<hno>
Tsvetan, chip markings on the cuvieboard2 is almost the same. Logo etc is identical. Chip number D2161AA 23B instead of 237 on the OLinuXino. Does not smell like there have been a new silicon revision between the two..
lioka has joined #linux-sunxi
BJfreeman has quit [Quit: had a good time]
n01 has joined #linux-sunxi
n01 has quit [Client Quit]
n01 has joined #linux-sunxi
n01 has quit [Ping timeout: 260 seconds]
paulk-desktop has joined #linux-sunxi
n01 has joined #linux-sunxi
rzk has quit []
wingrime has joined #linux-sunxi
Soru has quit [Read error: Connection reset by peer]
tzafrir has quit [Ping timeout: 276 seconds]
n01 is now known as n01|away
Kadosch has quit [Read error: Connection reset by peer]
Jhinta has joined #linux-sunxi
rellla has joined #linux-sunxi
Soru has joined #linux-sunxi
<Turl>
hi Tsvetan
Soru has quit [Read error: Connection reset by peer]
tzafrir has joined #linux-sunxi
n01 has joined #linux-sunxi
mripard_ has joined #linux-sunxi
mripard has quit [*.net *.split]
_BJFreeman has joined #linux-sunxi
<jelly-home>
this Mele M5 also has D21261AA 237 on the A20 soc
<oliv3r>
hno: i did some very light and maybe slightly silly math now
<Turl>
mripard_: I doubt the tproxy code has anything to do, so I suppose it's just memory corruption
<mripard_>
yeah, the weird thing being that I have the same error every time iirc.
<mripard_>
so it's not random enough to be RAM corruption
<Turl>
mripard_: the USB stack on A20 (and back in the day, A10) had an overflow bug that caused crashes
<mripard_>
yet, u-boot doesn't seem to check the CRC
<hno>
oliv3r, great. Sorry that I am a little distant tonight. General Assembly meeting in the Swedish Linux Society, and lots of followup discussions. Plus a bad headache still...
<oliv3r>
hno: the fever gone?
<mripard_>
so the saveenv I made could very well have overwritten just a part of the kernel
<oliv3r>
hno: oh don't excuse yourself, i'm the burden here :)
<Turl>
mripard_: if you can boot recovery, you could try dd'ing a copy and diffing them
<oliv3r>
my idea was though, to merge/change some stuff later (and making a better math solution easier there (didn't wanna rewrite it yet)
<mripard_>
yeah, the point is that I don't have any copy of the kernel :)
<oliv3r>
like dllcrx and dllr0 can easily be merged I would say
<mripard_>
I made one of the environment, not the kernel
<mripard_>
which is probably dumb, but anyway :)
<Turl>
mripard_: no livesuite flashable image?
<mripard_>
none yet.
<Turl>
mripard_: I think drachensun had one of the kits too, he might be able to copy it for you
<mripard_>
ah, true
<drachensun>
who summons me....
<oliv3r>
rellla: ssvb I'm guessing we can push tom into getting us updated mali blobs
<oliv3r>
rellla: ssvb tom needs it just as much as we do, if not more
<drachensun>
mripard: you need a copy of the original android kernel?
<oliv3r>
hno: my main priority with this magic value reducment patch, is having the code (variables) to be readable and understandable from just the code
<oliv3r>
hno: but i'm far far from skilled enough; so i just dabble :)
* rellla
is idling for hipboi ...
<oliv3r>
#cubieboard? #cubietech #cubietruck
<mripard_>
drachensun: yeah, the one on the nand
<Turl>
drachensun: yup
<mripard_>
if you still have it :)
<drachensun>
Well I've got the livesuite image they provided
<mripard_>
except for the number of cpus of course.
<oliv3r>
a31 has gic?
<mripard_>
drachensun: ok, thanks!
<oliv3r>
a20 is sun4 + sun5i + sun6i then :)
<mripard_>
oliv3r: yes
<oliv3r>
si'll look at your wip stuff tomorrow then
<oliv3r>
see if I can get that to boot
<mripard_>
drachensun: and this image contains what exactly, the whole boot0/boot1/u-boot/kernel/android stuff?
<drachensun>
yeah, its everything phoenixsuit needs to reflash the nand
<mripard_>
wow, great :)
<drachensun>
I got all the support files in an odd way
<drachensun>
since they didn't send my dvd
<drachensun>
so maybe I got some extras in the downloads
<drachensun>
they didn't give you that image to reflash the board with?
<mripard_>
yeah, they just sent me the board, without anything more.
<mripard_>
nope :)
<drachensun>
no LCD?
<mripard_>
well, that's part of the board for me, so yes
<drachensun>
ah ok
<drachensun>
well I think thats the real standard kit then
<mripard_>
the colombus board, with its LCD, a camera, and something else I don't remember
<mripard_>
VGA probably
<drachensun>
yeah, thats pretty much what I got
<mripard_>
on a small PCB that plugs into one of the headers
<oliv3r>
so mripard_ you'll start reverse engineering powerVR soon? :)
<drachensun>
I've got another larger image
<drachensun>
I'm not sure what it is though
<mripard_>
oliv3r: nah
<drachensun>
I'll put it in the same directory
<mripard_>
I don't understand a thing about all these weird graphics stuff :)
<drachensun>
me either but I have a question in case anyone here knows, would this libhybis approach to getting acceleration from the Android blobs work on the powerVR too?
<oliv3r>
mripard_: just so i can start wrapping my head around things for tomorrow; the main reason the kernel won't start ist he DTB?
<oliv3r>
i thought that sun7i's registers where nearly exactly the same as sun4i
<oliv3r>
so took a leap :)
<oliv3r>
what's the bear minimum support the kernel needs, earlyprintk obviously to see stuff, interrupts I assume to make uart work
<oliv3r>
'arm core' but that should work no matter
<oliv3r>
memory controller
<mripard_>
oliv3r: yes you need a dtb, to patch the core so that it recognises the machine, and compile in the gic driver
<mripard_>
the only thing tricky is that you have to find out which interrupt the uart uses
<oliv3r>
i fix that via the dtb though
<oliv3r>
Pcorrect?
<oliv3r>
and set the 'machine id' somewhere right i remember reading somewhere
<mripard_>
no
<mripard_>
machine id is deprecated.
<oliv3r>
ah ok so we don't use that
<oliv3r>
good
<mripard_>
the machine id we use is 0xffffffff :)
<oliv3r>
ironically i've been doing some u-boot-spl work
<oliv3r>
and it's back to dtb-less old skool register writing
<oliv3r>
since you don't have a dtb
<mripard_>
well, it begins to come to some bootloaders
<mripard_>
barebox is already supporting dt-only probing as well.
<oliv3r>
spl is to small to do dtb
<oliv3r>
we only have 24k to play with
<oliv3r>
and our current SPL is 22k
<oliv3r>
with only dram, spl and i2c drivers
<mripard_>
I wonder how much a stripped down libfdt would take
<mripard_>
i2c? what for?
<oliv3r>
power
<mripard_>
ah, yes, of course
<oliv3r>
though i think that might be in regular u-boot
<oliv3r>
mmc is big too
<oliv3r>
and that's without even a FS
<oliv3r>
so you need to load the dtb too from somewhere
<oliv3r>
can't have a fs driver in spl; too small iirc
<mripard_>
not really
<oliv3r>
with only 2k to play with?
<mripard_>
where would you load it from?
<oliv3r>
IF you'd really go that way, bare partition/sector
<oliv3r>
eeprom
<mripard_>
and how would you know that you have an eeprom ? :)
<oliv3r>
probe for an i2c, check for a signature
<oliv3r>
we where playing with the idea to load dram settings from script.bin/specific dram file/dtb
<oliv3r>
so we did some math and some poking
<mripard_>
what would be the base address and the driver you want to load for that i2c controller ? :)
<oliv3r>
hardcoded
<oliv3r>
or probe all i2c controllers for possible eeproms
<mripard_>
you can't possibly hardcode it
<mripard_>
otherwise, you would lose all the benefits of being generic
<oliv3r>
mripard_: you can't embedd/append it to the SPL
<oliv3r>
the dtb is way to big
<mripard_>
yeah, I agree
<oliv3r>
reading it from an mmc sector could be possible
<oliv3r>
but then your mmc driver won't be generic :p
<mripard_>
it's a shame we don't have a mecanism such as the one found in the freescale imx/marvell armada
<oliv3r>
which one is that?
<oliv3r>
it's a shame there's not some ISP mode, to change the BROM
<mripard_>
where it's the rom code that setups the ram, using a header of the bootloader image
<oliv3r>
it's a shame it's not some flash rom embedded into the CPU
<oliv3r>
well this offers you a little more flexability
n01 has quit [Read error: Operation timed out]
<oliv3r>
it's like out of soc ROM :)
<mripard_>
it offers you all the flexibility you need, since you always run from RAM
<mripard_>
you have all the memory space you want
<oliv3r>
ideally, we'd flash the SPL into the rom; which would actually be allowed to be bigger, BROM is 32k
<oliv3r>
i'm still slightly skeptical the BROM is pure rom and not some eeprom :)
<Turl>
mripard_: did you get a chance to test the mod0 clock code?
<hno>
oliv3r, the SPL also have MMC (or NAND in the NAND version)
<oliv3r>
aye
<oliv3r>
so unless we can clean out some cruft, dtb parsing won't be possible imo
<oliv3r>
but finally i can boot the a20 branch (didn't work before for some reason)
<Turl>
oliv3r: maybe building with -Os if not already, or thumb?
<oliv3r>
Turl: no clue what we do now :)
<oliv3r>
Board: A20-OLinuXino_MICRO
<oliv3r>
DRAM: ? ? 0MB
<oliv3r>
### ERROR ### Please RESET the board ###
<oliv3r>
but i broke it again :)
<hno>
I don't see dtb for the SPL as realistic no. But it's can be a generic SPL for all 5 CPUs only differing in runtime config in the SPL header, and a DTB full u-boot, and a small tool to configure the SPL from the DTB.
<oliv3r>
have a bit in the header identify the chip
<hno>
yes
<oliv3r>
verify it against SRAMC
<oliv3r>
:p
<oliv3r>
but yeah, getting it more general shouldn't be to far out of reach
<oliv3r>
if it fits that is
<oliv3r>
those #ifdefs do save a bit of space
<oliv3r>
if you'd replace some with if (chip = )
<hno>
but chip id is only needed to try to complain if the user uses an image configured for another CPU. Which is just overhead.
<oliv3r>
true
<hno>
there is many other ways using the wrong image will fail.
<oliv3r>
well you could use the chip id to boot an SPL without a bit in the header
<oliv3r>
if we'd have one generic image that is
<hno>
yes, if size allows we could try to probe some common DRAM configurations.
<oliv3r>
well i wasn't even thinking of dram configs; but that too
<hno>
the SPL is pretty much only about DRAM config.
<hno>
and to load u-boot into DRAM when configured.
<oliv3r>
well we have some #ifdefs now for various things
<oliv3r>
i was thinking as a first step; generic SPL, that loads dram config from 'somewhere' not important now
<oliv3r>
anyway
<oliv3r>
lots of work; first gotta get things better into shape:)
<hno>
I don't see a reason to bother with SPL loading configuration, Just embed the config in the SPL header and me done with it.
<oliv3r>
u-boot, when booted from SPL, is the same thing over again, right? i mean, same files are used for mmc driver, clock.c etc
<oliv3r>
having config and binary seperated is a big pro imo
<oliv3r>
write binary once, don't bother with it
<hno>
drivers are the same. clock have some stuff that is SPL specific.
<oliv3r>
want to change memory timings? no problem, write it xxx
<oliv3r>
want to 'update' SPL without touching memory timings, just write spl
<hno>
even if the header it's still separated.
<oliv3r>
well it would be very easy to overwrite
<hno>
the header is added by mksunxiboot, not part of u-boot-spl.bin.
<oliv3r>
well there's still the stupid users to cater :)
<oliv3r>
they want to download bin, flash bin
<oliv3r>
we don't want them to overwrite their memory timings
<oliv3r>
(yes, we shouldn't help stupid users)
<hno>
I'd rather cater them by people making binary images for them...
<oliv3r>
but it improves unbrickability
<oliv3r>
well you know how it goes though :)
<oliv3r>
but having less chance to brick a device (even so slightly) is good (not total brick of course, specially in the case of mmc)
<hno>
It's trivial for a kitchen sink tool to update the SPL header automatically. 0 brick chance.
<hno>
flashing NAND implies running code that can access NAND and it's then trivial to preserve DRAM settings etc both from allwinner bootloeaders and already installed SPL loaders.