<NiteHawk>
you probably need to set bootm_boot_mode and should be okay
<nahom>
I've tried that... same result
<NiteHawk>
hmm... maybe go back to u-boot v-2015.07 or v-2015.04 to make sure it's not a regression with the latest version?
<nahom>
so you think this is a u-boot issue and not an issue with the kernel?
<plaes>
generally it is
<NiteHawk>
all i can say that the hang at "starting kernel..." is a typical thing with new u-boot and older kernel - usually related to that bootm_boot_mode
<nahom>
Do you have any other suggestions?
<NiteHawk>
and if your kernel worked with an older u-boot before, that points toward it as the culprit...
<nahom>
It hasn't worked before. This is my first attempt
<NiteHawk>
it's hard to suggest something else if your kernel doesn't even start - that way you won't get any diagnostic output / error messages :/
dlan has quit [Ping timeout: 260 seconds]
<nahom>
I tried with guillaume's images from guillaumeplayground.net
dlan has joined #linux-sunxi
<nahom>
and once I dd the images to the SD, I then also dd the u-boot-with-spl and the result is that...
<nahom>
it tries to bootp but fails as I don't have a TFTP server setup... and that's not even my mission, I need to boot from SD and eventually want to put it on NAND
<NiteHawk>
maybe skip the u-boot-with-spl (i.e. use the 'stock' image) to find a "known good" combination first?
<plaes>
what's your kernel cmd line?
<nahom>
I haven't found any images that work... the Guillaume image doesn't boot unless I write the u-boot-with-spl
<nahom>
plaes: kernel cmd line? I don't understand... I'm a bit of a noob
<plaes>
bootargs
<plaes>
or could you paste your boot.cmd somewhere
<nahom>
here in the bootargs, it tells it to look for the kernel at 0x48000000
<nahom>
Where is it configured so that the image is at that address?
<plaes>
fatload mmc 0 0x48000000 uImage
<plaes>
^^
<nahom>
Because at the u-boot prompt, I use the command iminfo 0x48000000 and it says there is no image at that address
<nahom>
Just doing iminfo will display the correct info but at address 42000000
<plaes>
but then try doing 'bootm 0x42000000'
<nahom>
Yeah... tried that...
<nahom>
same result "Starting Kernel..."
<nahom>
nothing after that
<NiteHawk>
nahom: does that image you dd already contain an older u-boot suitable for your device? if so, try booting with that first before attempting to upgrade u-boot to the "latest and greatest"
<nahom>
the image I dd doesn't boot at all... which is why I tried to dd the u-boot-with-spl...
<NiteHawk>
that's okay - and you obviously even got it working to the point where it's loading the kernel
<nahom>
Are there any particular things I should pay attention when compiling the kernel (in the menuconfig)?
<NiteHawk>
you're compiling the kernel too? i got the impression you were trying to use the one from the image
<NiteHawk>
which means the usual "el cheapo" support quality i guess :D
<nahom>
No support at all!
<nahom>
But on some forums people have reported having success with putting linux on it
<nahom>
It comes with android 4.2
<NiteHawk>
well, let's take a step back. you said you're able to see that "Starting kernel..." - may i ask where?
<nahom>
On the vga monitor
<NiteHawk>
okay, so i guess there are other u-boot messages predecing it - but nothing on the serial console?
lemonzest has quit [Ping timeout: 252 seconds]
<NiteHawk>
*preceding
<nahom>
Nothing on the serial console
lemonzest has joined #linux-sunxi
<nahom>
The messages preceding that are from u-boot... seems like everything is normal
<nahom>
until that point...
<bonbons>
nahom: maybe you need to ask uboot to set console=ttyS0,115200 on kernel cmdline (and note that you should have a kernel that matches uboot in device-tree versus fex)
<NiteHawk>
okay, that's not ideal, but at least it's *something*
<nahom>
I feel like the problem is with uImage (the kernel)
<NiteHawk>
there's another question that still was open
<NiteHawk>
<nahom> Are there any particular things I should pay attention when compiling the kernel (in the menuconfig)?
<NiteHawk>
<NiteHawk> you're compiling the kernel too? i got the impression you were trying to use the one from the image
<nahom>
No... I'm compiling the kernel too
<NiteHawk>
the "sunxi" 3.4 flavor or mainline?
<nahom>
sunxi 3.4
<NiteHawk>
can you pastebin your boot script somewhere? i.e. the boot.cmd text that you use to create boot.scr
<bonbons>
nahom: which version of uboot are you using? it might be that your uboot and your kernel are not compatible...
<nahom>
U-boot 2015.10-rc1
<nahom>
Aug 10
IgorPecovnik has quit [Ping timeout: 264 seconds]
<bonbons>
not sure about compatibility or how FEX info must be passed to 3.4 sunxi kernels from mainline uboot...
<bonbons>
nahom: you might have some more success (though no GFX accel and some missing features) with mainline kernels (4.1.x or even 4.2rc) and using device-tree
<nahom>
Can you explain a bit more... I really am a noob.
<NiteHawk>
nahom: in your situation my suggestion would be to try an alternative (mainline) u-boot, and go back to an older version tag that's known to work on A20 and 3.4.x - e.g. "git clone -b v2015.04 git://git.denx.de/u-boot.git"
<nahom>
Should I first try replacing just my uboot?
<NiteHawk>
might be another option. it's possible that you replace too many things at once from that 'stock' image, and thus can't tell exactly where things break
lemonzest has quit [Ping timeout: 245 seconds]
<nahom>
I'll try that older uboot
<nahom>
I'm cloning it as we speak
<nahom>
Cloning done... I should still use the u-boot-with-spl.bin right?
<NiteHawk>
yes, rebuild following the previous instructions unchanged ("make Mele_M3_defconfig; make"), then dd the u-boot-with.spl.bin
<NiteHawk>
btw. how did you get a u-boot prompt before without serial console - USB keyboard?
<nahom>
Yes... USB Keyboard
<NiteHawk>
i see
nashpa has quit [Ping timeout: 252 seconds]
philectro has quit [Quit: Konversation terminated!]
<nahom>
Just tired booting...
<nahom>
same result with older uboot
<NiteHawk>
so it gets up to "Starting kernel..." and nothing after that?
nashpa has joined #linux-sunxi
<nahom>
NiteHawk: yes
<NiteHawk>
:/
<nahom>
Isn't there any "checks" I could do on the uboot prompt?
<nahom>
it has a few commands
<NiteHawk>
yes, but there's not much you could do - all the test would probably show that the uImage was transferred to memory properly and is ready to boot - your problem arises the very moment that u-boot actually tries to transfer control to the loaded kernel image...
<nahom>
Yes, you're right...
<nahom>
Next I guess is to try the mainline kernel
<ssvb>
NiteHawk: "Current status Awaiting good patches" is a bit misleading on the M3 wiki page
<ssvb>
nahom: try to use the mainline kernel instructions from the linux-sunxi wiki
<nahom>
Yeah... perhaps once I get this things figured out, I'll update the wiki
<ssvb>
nahom: thanks
<NiteHawk>
ssvb: it's also not clear whether that refers to the community kernel (sunxi-next), or mainline
<nahom>
I have to be going now... but this will be the first thing I try Monday morning. How can I find you guys then?
<ssvb>
NiteHawk: yes, this wiki page is definitely not in the best shape
<NiteHawk>
since it has a separate "mainline kernel" section, i'm inclined to assume the former
<NiteHawk>
nahom: we're usually hanging out here - you might not get an instant reply from people, but someone in the channel should be able to help you
<nahom>
Ok, thanks a lot. You have been very helpful.
<NiteHawk>
you're welcome
nahom has quit [Ping timeout: 246 seconds]
philectro has joined #linux-sunxi
Nacho has quit [Ping timeout: 256 seconds]
arossdotme has quit [Ping timeout: 256 seconds]
doppo has quit [Ping timeout: 256 seconds]
doppo has joined #linux-sunxi
ssvb has quit [Ping timeout: 246 seconds]
Nacho has joined #linux-sunxi
arossdotme has joined #linux-sunxi
wens has quit [Quit: leaving]
wens has joined #linux-sunxi
lemonzest has joined #linux-sunxi
leviathanch has quit [Read error: Connection reset by peer]
leviathanch has joined #linux-sunxi
loosenut has quit [Ping timeout: 246 seconds]
doppo has quit [Ping timeout: 246 seconds]
doppo has joined #linux-sunxi
<vishnup>
Hello
<vishnup>
I'm trying to write latest spl using FEL
<vishnup>
fel write 0x2000 u-boot-spl.bin
<vishnup>
it gives error: libusb usb_bulk_send error -7
<vishnup>
BTW, as I remember there was 16KB limit for SPL, now the SPL size is 21KB
<vishnup>
I'm trying it on A33 tablet
<wens>
check what error -7 is?
<vishnup>
wens: I'm able to write the older spl which is 15KB
JohnDoe_71Rus has quit [Ping timeout: 255 seconds]
<NiteHawk>
vishnup: maybe try with a newer sunxi-tools version and the "fel spl" command?
<vishnup>
NiteHawk: for A33 it gives error MMU not enabled by BROM
<wens>
yeah... that's a problem i don't know how to fix :(
<NiteHawk>
hmm... maybe that's related to your "libusb timeout" (error -7)?
<NiteHawk>
but same here: no idea how to tackle that...
sauerkraut has joined #linux-sunxi
sauerkraut is now known as Guest88822
<Guest88822>
Hey I was checking out the wiki to find a list of compatable ddr modules for the a13 and the link seems to be down, anyone have a working link for that site?
JohnDoe_71Rus has joined #linux-sunxi
cubeast has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
kz1 has quit [Read error: Connection reset by peer]
kz1 has joined #linux-sunxi
<NiteHawk>
vishnup: fel.c seems to be missing "soc_sram_info" for the A33 - maybe try to hack something up based on the A23? i'm not sure it will make a difference, but it's at least worth a try
<vishnup>
NiteHawk: wens: for A33 MMU is not enabled by default, if we dont call aw_backup_and_disable_mmu() and respective aw_restore_and_enable_mmu(), it can load SPL
<vishnup>
by default= by BROM
<NiteHawk>
but you're running into a size limit or? as i understood it, you cound load a smaller SPL, but not the one exceeding 16KB?
<vishnup>
ssvb: yes, that's right, it gives error: MMU not enabled by BROM
<ssvb>
vishnup: this code is just trying to be a bit too "defensive" and refuses to work if it encounters something unexpected
<ssvb>
if can be surely adapted to support a33 properly
<ssvb>
vishnup: can you try to fix this and submit a patch?
<ssvb>
"aw_backup_and_disable_mmu()" function can probably return NULL if MMU is already disabled, and "aw_restore_and_enable_mmu()" can probably do nothing if it gets NULL as the "tt" argument
<vishnup>
ssvb: I'll try
<ssvb>
thanks
<ssvb>
the a33 sram layout is probably the same as in a23, but we can check the datasheets
<ssvb>
yes, the memory layout seems to be very similar in the documentation, so using 0x44000 should work
<ssvb>
wens: btw, do you have an a80 board?
<ssvb>
it would be interesting to also get fel booting working on it
<ssvb>
at least to successfully load and run the boot0 blob via fel (while u-boot is still missing spl for a80)
<wens>
ssvb: i do
<ssvb>
wens: a80 is a bit of an oddball, because it uses 0x10000 as the load address instead of 0x0
<wens>
yeah, because 0x0 is by default mapped to brom, though can be remapped to sram
<ssvb>
it might need a bit more work, but with some luck it should not be too difficult
<ssvb>
I wonder about the locations of the FEL application stacks on A80 (they are at 0x2000 and 0x7000 on older SoCs)
<ssvb>
wens: is a80 able to run some basic fel commands ("write", "read", "exe")?
<vishnup>
ssvb: why can't fel write do work for A33?
<vishnup>
16kb size limit?
domidumont has joined #linux-sunxi
domidumont has joined #linux-sunxi
<ssvb>
vishnup: I don't quite understand the question
<ssvb>
vishnup: are you having some problem with fel write command on a33?
* ssvb
unfortunately does not have a33 hardware
<vishnup>
fel write 0x2000 u-boot-spl.bin
<vishnup>
it gives error: libusb usb_bulk_send error -7
<vishnup>
older 15kb spl works well with latest fel
<ssvb>
maybe it is oversized?
ricardocrudo has joined #linux-sunxi
<wens>
ssvb: sure, that's how i boot it :)
<wens>
for some reason fastboot doesn't work for me
<ssvb>
fel code in brom typically uses two areas in sram, one is a few kilobytes below 0x2000, and another is a few kilobytes below 0x7000
<ssvb>
if you manage to corrupt either of these, then it dies
<ssvb>
so we had something around ~15K starting at 0x2000 for our use
domidumont1 has joined #linux-sunxi
<ssvb>
the new 'fel spl' command does its trick by backing up and restoring these sensitive areas before/after running the spl
paulk-cccamp has joined #linux-sunxi
<ssvb>
wens: sounds good :)
<ssvb>
are you booting boot0 this way?
<ssvb>
wens: if your a80 board is not too far away, could you check where it places stack?
domidumont has quit [Ping timeout: 246 seconds]
<wens>
ssvb: yes, booting fel boot0
<wens>
will check tomorrow (though question is how?)
<ssvb>
wens: basically dump and report the value in 'sp' register
<ssvb>
wens: thanks, this can surely wait till tomorrow
<ssvb>
wens: do you normally just write boot0 blob to the address 0x10000 and execute it on a80?
<ssvb>
wens: if a80 places fel stacks elsewhere (away from 0x10000), then we probably don't need that weird gymnastics with saving/restoring fel stacks anymore :)
paulk-cccamp has quit [Ping timeout: 246 seconds]
pirea has quit [Quit: Leaving]
paulk-cccamp has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 244 seconds]
paulk-cccamp has quit [Ping timeout: 246 seconds]
Netlynx has quit [Quit: Leaving]
simosx has quit [Quit: Leaving]
pietrushnic`away has joined #linux-sunxi
pietrushnic`away is now known as pietrushnic
interrobangd has joined #linux-sunxi
NiteHawk has quit [Remote host closed the connection]