<libv>
first off, this sounds like something you should throw at merrii and not at linux-sunxi
<dothebart>
yes, these guys are pretty communicative
<dothebart>
;-)
<libv>
secondly, even though i got myself a80 hw 2 months ago, i have not worked with it yet, or even started to document it, so i have no idea what the state of sunxi support for a80 is
<dothebart>
am I right that the uboot sits on that fat partition?
ganbold__ has quit [Ping timeout: 255 seconds]
wickwire has joined #linux-sunxi
<wens>
dothebart: if you're using allwinner/merrii binaries/images, you should ask them
<libv>
dothebart: it usually sits somewhere in the first MB of the SD card, it probably sits in a similar location on NAND
<dothebart>
/dev/mmcblk0p1 * 76289 958464 7057408 b Win95 FAT32
<dothebart>
that one?
<libv>
before that.
<libv>
but as wens said, this is for merrii to answer
<dothebart>
yea, I guess I may get an answer if I book a flight to cn, and turn up there with a baseball bat
<libv>
...
<dothebart>
but you probably already know that
<libv>
dothebart: do you really expect the sunxi guys to solve your issue when you are not working on or towards sunxi code for a80?
<dothebart>
well, first I hoped to broaden my knowledge about uboot
arokux has quit [Ping timeout: 272 seconds]
enrico_ has joined #linux-sunxi
<wens>
dothebart: allwinner u-boot and mainline u-boot are pretty different
<wens>
and mainline u-boot doesn't really support a80
arokux has joined #linux-sunxi
<libv>
wens: too few users?
enrico_ has quit [Quit: Bye]
<libv>
or too early days still?
<wens>
libv: maybe both
<libv>
wens: but the sdk works (somewhat)?
<vpeter>
libv: I think it's more somewhat.
foudubassan has quit [Remote host closed the connection]
<wens>
libv: i've not tried compiling the sdk
<libv>
not even the uboot or linux kernel in there, separately?
<wens>
maybe uboot, don't remember for sure
<wens>
i'm running fel mode with fel boot0 + aw u-boot binary + mainline kernel
<wens>
afaik others use fastboot
<libv>
where did you get the aw u-boot binary?
<libv>
are any of these workflows documented in our wiki?
<wens>
libv: the sdk from merrii has an already compiled binary
<dothebart>
I put 'thanks for your help' just in case somebody of their staff reads it and maybe blushes ashamed a little.
<simosx>
dothebart, there is a language issue so it needs a bit more than just asking directly (...) ;-(
<dothebart>
I wonder why they took the time to install a phpbb if they don't use it at all
<simosx>
dothebart, they do use it to publish pan.baidu.com links with images/SDKs.
<dothebart>
yea, at least something... a dokuwiki would probably be a better fit for that ;-)
<dothebart>
ah, now I know why 'arches' was all over the pcduino site ;-) they're renaming it.
naobsd has joined #linux-sunxi
orly_owl has quit [Ping timeout: 258 seconds]
iamfrankenstein has quit [Ping timeout: 244 seconds]
orly_owl has joined #linux-sunxi
flyhorse_wSVmf has quit [Ping timeout: 256 seconds]
<RSpliet>
jackdaniel: I've taken your sunxi-nand SPL patch and transformed it into something that style-wise adheres more to the kernel/u-boot conventions
<RSpliet>
but... I wanted to ask you: is there a particular reason why you decide to set up the clocks, reset the controller and reset the NAND chip?
<RSpliet>
on the one hand I'd say it's good practice to assume no state from the NAND controller, so no argument there
<RSpliet>
but as a result the patch makes a lot of assumptions (page size, ECC block size...)
<RSpliet>
on the other hand, if we make the assumption that BROM configured the NAND controller, the code would fail if SPL is on an MMC card, but we can re-use the controller configuration used by BROM to successfully load the SPL
dack has joined #linux-sunxi
<RSpliet>
my (wild) idea is for SPL to use... perhaps the state of the NAND clock to determine whether BROM loaded SPL from NAND or from MMC. If the former, we can continue reading from NAND to RAM skipping most of the configuration, if the latter, ignore NAND for the boot process and look for U-boot on the MMC
<dack>
hey.. I'm trying to update my uboot to the mainline version and I'm having a problem with it finding my boot.scr file. When I try to boot it starts saying "BOOTP broadcast" and counts...
<dack>
I've placed boot.scr in both / and /boot... I don't think it's loading either. If I run the commands manually at the uboot prompt it works with no issue.
wickwire has quit [Ping timeout: 258 seconds]
<RSpliet>
dack: u-boot decides what to do based on an ENV variable containing a few commands. check those
<dack>
RSpliet: do one of those tell it where to find the boot.scr file?
<RSpliet>
it should... I don't recall which one it is
<dack>
RSpliet: how do I output the current env settings from the uboot prompt?
<dack>
RSpliet: printenv :) just found it
<dack>
I found: boot_scripts=boot.scr.uimg boot.scr
<dack>
It seems like it should be reading the boot.scr and running it... I'm not even sure it's looking, though.
<RSpliet>
that's just the name of the boot script
<RSpliet>
there's an mmc load command and an execute command somwehere else
<RSpliet>
hmm, shuffle those letters around a little
<dack>
bootcmd_mmc0=setenv devnum 0; run mmc_boot ?
<RSpliet>
bootcmd is probably the toplvl
<dack>
yeah.. that runs distro_bootcmd and that is a loop that then runs bootcmd_mmc0
<dack>
Where are these env settings set, any way?
<plaes>
RSpliet: I think you can mark 'random_seed' as static
<RSpliet>
plaes: thanks, I've been meaning to look at that bit, maybe even take it out for SPL
<RSpliet>
it's still a WIP :-)
<plaes>
thanks for working on this ;)
<RSpliet>
haha, npo, just scratching an itch :-)
<mripard>
RSpliet: on some SoCs, there's some register somewhere that indicates from which device you booted from
<mripard>
maybe that would be a better bet
<RSpliet>
mripard: well... I'd have to see if BROM sets some register for that
<dack>
If I run "run mmc_boot" it says "No partition table - mmc 0". However I can load the kernel with "load mmc 0 0x42000000 boot/uImage", so what gives?
<mripard>
RSpliet: but I don't really understand what you try to achieve. My guess would be to have two different configurations for booting from the NAND or from the MMC (or at least that's what is usually done)
<mripard>
starting from that, it's easy to get from where you've been loaded from
<mripard>
you even knew it at compilation time
<RSpliet>
mripard: well, yes, I don't mind either way
<RSpliet>
what I worry about more tbh is all the configuration options associated with NAND
<RSpliet>
BROM just tries an arbitrary list of combinations one after the other
<RSpliet>
(which... comes with it's own problems, but let's ignore those for now)
<mripard>
define "all the configuration options associated with NAND"
<dack>
ah.. I think it's not working because the partition isn't flagged as bootable
<mripard>
or at least, define why it does worry you
<dack>
RSpliet: the driver in the sunxi repo is really old... I'm trying to use a newer one, but I'm having issues. https://github.com/lwfinger/rtl8188eu has two versions, and no explanation as to the differences between them
<RSpliet>
ask Ardillo in #randomdata, he's playing with it
<RSpliet>
he's not very talkative on IRC, beware
<dack>
RSpliet: okay, I will. thanks.
<dack>
RSpliet: I was using the master version for quite a while but discovered it's not able to connect to an AP with no encryption... very strange.
simosx has quit [Quit: Leaving]
simosx has joined #linux-sunxi
<dack>
RSpliet: ... he seems to be away.. think I'll just file an issue on github... Larry is pretty good at responding
angry_specing is now known as angry_angry_spec
angry_angry_spec is now known as angry_specing
dev1990 has joined #linux-sunxi
lemonzest has joined #linux-sunxi
a1d3s has quit [Ping timeout: 276 seconds]
leviathancn has quit [Ping timeout: 272 seconds]
afaerber_ has joined #linux-sunxi
afaerber has quit [Ping timeout: 245 seconds]
JohnDoe_71Rus has joined #linux-sunxi
reinforce has joined #linux-sunxi
simosx has quit [Quit: Leaving]
reinforce has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
ganbold_ has quit [Ping timeout: 255 seconds]
Gerwin_J has joined #linux-sunxi
prz has quit [Quit: Leaving.]
MY123 has quit [Ping timeout: 276 seconds]
MY123 has joined #linux-sunxi
khuey|away is now known as khuey
awe00 has quit [Ping timeout: 255 seconds]
iamfrankenstein has quit [Quit: iamfrankenstein]
iamfrankenstein has joined #linux-sunxi
enrico_ has quit [Quit: Bye]
dev1990_ has joined #linux-sunxi
dev1990 has quit [Ping timeout: 258 seconds]
aoao has quit [Ping timeout: 264 seconds]
aoao has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
pstef has quit [Ping timeout: 256 seconds]
iamfrankenstein has joined #linux-sunxi
Dodger78 has quit [Ping timeout: 256 seconds]
Dodger78 has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 256 seconds]
awe00 has joined #linux-sunxi
<dack>
does the mainline version of u-boot work for NAND booting?
pstef has joined #linux-sunxi
RzR has quit [Excess Flood]
RzR has joined #linux-sunxi
viccuad has quit [Quit: WeeChat 1.1.1]
bgola has joined #linux-sunxi
<plaes>
dack: IIRC RSpliet is currently working on that
<dack>
plaes: k.. I guess I'll just keep using what's already on the NAND