premoboss has quit [Read error: Connection reset by peer]
apritzel has joined #linux-sunxi
egbert has quit [Ping timeout: 245 seconds]
egbert has joined #linux-sunxi
tomboy65 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 250 seconds]
apritzel has quit [Ping timeout: 248 seconds]
adj__ has quit [Quit: Leaving]
Net147 has joined #linux-sunxi
premoboss has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 245 seconds]
Gerwin_J has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
apritzel has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 276 seconds]
p1u3sch1 has joined #linux-sunxi
utente_ has joined #linux-sunxi
utente_ has quit [Client Quit]
premoboss has quit [Ping timeout: 260 seconds]
tomboy64 has quit [Ping timeout: 250 seconds]
tomboy64 has joined #linux-sunxi
diego71 has quit [Ping timeout: 272 seconds]
paulk-collins_ has joined #linux-sunxi
apritzel has quit [Ping timeout: 248 seconds]
paulk-collins has quit [Ping timeout: 252 seconds]
tomboy64 has quit [Ping timeout: 250 seconds]
ricardocrudo has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
apritzel has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 250 seconds]
premoboss has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
tomboy65 has joined #linux-sunxi
apritzel has quit [Ping timeout: 248 seconds]
tomboy64 has quit [Ping timeout: 264 seconds]
tomboy64 has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 245 seconds]
tomboy65 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 260 seconds]
p1u3sch1 has quit [Ping timeout: 256 seconds]
p1u3sch1 has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 240 seconds]
p1u3sch1 has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 245 seconds]
domidumont has quit [Ping timeout: 246 seconds]
<longsleep>
Hey folks, is there any way to debug why the Kernel does not boot after boot command from u-boot. The kernel image in question does boot with another u-boot, but not with the one i built myself (Pine64). Any suggestions?
<wens>
use earlycon for some more output?
premoboss has quit [Quit: Sto andando via]
<longsleep>
wens: Yeah i use that, earlycon=uart,mmio32,0x01c28000 but no output
<longsleep>
i guess it is related to the warn boot to 64bit stuff
<longsleep>
I probably missed something because when using the binary blobs from the working android image it also fails to boot when i use it when loading stuff from vfat partiton instead of sunxi flash.
tomboy64 has quit [Ping timeout: 252 seconds]
cnxsoft has quit [Remote host closed the connection]
tomboy64 has joined #linux-sunxi
apritzel has joined #linux-sunxi
cptG_ is now known as cptG
<wens>
i haven't touched my pine64 yet though
jstein has quit [Read error: Connection reset by peer]
<longsleep>
well, i only have limited time for it on the weekend and began to clean up my scripts, https://github.com/longsleep/build-pine64-image (no docs yet as it does not boot and still uses boota to boot :/)
vickycq has joined #linux-sunxi
jstein has joined #linux-sunxi
jstein_ has joined #linux-sunxi
jstein has quit [Ping timeout: 252 seconds]
apritzel has quit [Ping timeout: 248 seconds]
tomboy65 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 248 seconds]
tomboy64 has joined #linux-sunxi
sunxi_fan1 has quit [Remote host closed the connection]
tomboy65 has quit [Ping timeout: 264 seconds]
viccuad has joined #linux-sunxi
diego71 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 256 seconds]
tomboy64 has joined #linux-sunxi
IgorPec has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
Nacho_ has quit [Quit: No Ping reply in 180 seconds.]
Nacho has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 240 seconds]
cosm has quit [Ping timeout: 248 seconds]
tomboy64 has joined #linux-sunxi
tomboy65 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 240 seconds]
cosm has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 250 seconds]
p1u3sch1 has quit [Ping timeout: 240 seconds]
p1u3sch1 has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
longsleep: still around?
<apritzel>
I learnt more about the real boot process by looking at their ATF port
<apritzel>
so they don't warm-reset directly into the kernel - that wouldn't work because it would enter the kernel in EL3
<apritzel>
instead they use a "service" from the ATF to switch to 64-bit
<apritzel>
this service is some Allwinner made-up function call using the same principles like PSCI, just with different numbers
tomboy64 has quit [Ping timeout: 250 seconds]
<apritzel>
so the do a "smc" from 32-bit SVC, which takes the CPU back into AArch64 EL3 and calls the associated handler function
<apritzel>
*so they do a "smc" ...
<apritzel>
this function then drops back into the kernel entry point (which the caller put into a register) in AArch64 EL1
<apritzel>
longsleep: so this is their boot story, don't know which firmware parts you changed and which not
<wens>
sounds quite complicated :|
<apritzel>
wens: it is, this is the price for using a 32-bit U-Boot
<apritzel>
of course this function call is completely non-standard, but using an ARM standard number
<wens>
i guess there really isn't an alternative atm?
<apritzel>
64-bit U-Boot would be the cleanest way
tomboy64 has joined #linux-sunxi
<apritzel>
then would need to change one line in ATF to start U-Boot in AArch64
<apritzel>
the rest would be natural then, U-Boot jumps to the kernel
<wens>
how much platform code did they add to ATF? is it maintainable?
<apritzel>
they added a lot, but we don't need it
<apritzel>
I am in the process of cleaning this up
<apritzel>
so for some reason they provide a smc call interface to the arisc
<ssvb>
I guess this can be safely purged
<apritzel>
which is kind of pointless since you could use the messagebox mechanism directly, I think
<apritzel>
indeed
<apritzel>
also they copied errata workarounds for Juno and A57 ;-)
IgorPec has joined #linux-sunxi
<ssvb>
doesn't SCPI define some sort of a standard interface?
<wens>
do we stll need arisc after this?
<ssvb>
do I understand it right that Allwinner is partially implementing it and partially bypassing it?
<plaes>
wens: did you figure out the earlycon?
<wens>
plaes: not really, just dropped the options bit, seems to work now
<plaes>
ok
huawei has quit [Ping timeout: 256 seconds]
<ssvb>
wens: arisc is not really critical for booting the system, and even the AXP803 PMIC has a somewhat sane default configuration
<wens>
ssvb: they should, considering they are tailored for the soc
<apritzel>
ssvb: my hunch too, we can get away without any PMIC or arisc for the beginning
<ssvb>
wens: we get 3.0V instead of 3.3V which is not nice, but the datasheet says that the acceptable range is 3.0V - 3.6V
<wens>
ssvb: a lot of later boards use 3.0V instead of 3.3V
<wens>
not sure why
IgorPec has quit [Ping timeout: 250 seconds]
<ssvb>
either way, the system starts with the AXP803 default settings, so they can't be completely wrong/dangerous
<codekipp1r>
ssvb: Hi, do you have a .config handy that enables everything for OTG
<codekipp1r>
I can't seem to get mine working...but then again I can't confirm that my otg converters work
<wens>
codekipp1r: sunxi_defconfig, with my latest patches (see mailing list) :)
huawei has joined #linux-sunxi
<codekipp1r>
cheeers wen...
<apritzel>
ssvb: by the way: I tried your U-Boot on the Remix Mini (via FEL)
<apritzel>
created a new dts
<apritzel>
but it hangs after DRAM detection, I guess when eventually relocating
<wens>
do they have the same type of ram?
<codekipp1r>
the minute I look away you post all that!
<wens>
iirc they were different
<apritzel>
yeah, my guess to
<apritzel>
the original libdram output gives one different parameter
<ssvb>
wens: thanks for taking care of enabling OTG in defconfig
<ssvb>
apritzel: probably we need to extract 'dram_para' data from the Remix Mini boot0
<apritzel>
yes, my idea too
<apritzel>
but I couldn't find an image on the net
<codekipp1r>
ahhhh....I can see what I was missing now
<apritzel>
so I guess we need to write some custom code which read the eMMC and load that via FEL
<ssvb>
apritzel: exactly
<apritzel>
ssvb: something like a hacked U-Boot SPL
<wens>
any chance the remix mini is rooted, so one could just dd it out?
<apritzel>
wens: I logged into it (via ssh), but this Android is seriously locked
<ssvb>
wens: it is not rooted, and there are some complaints from the users about this
<apritzel>
wens: and I couldn't find anything about a root with a quick google search yesterady
<wens>
too bad :(
<apritzel>
but since we can run our code via FEL ...
<apritzel>
ssvb: do you think that your U-Boot port would work with boot0 instead of the SPL?
<ssvb>
apritzel: A80 uses boot0 instead of SPL
<apritzel>
I wanted to wrap the non-SPL part with their header and give it a try
<ssvb>
I don't have A80, but that's what I heard
<apritzel>
ah, OK
<ssvb>
apritzel: this should be trivially easy
<apritzel>
worth to give it a try then
<apritzel>
well, I can't just prepend something with a script
<apritzel>
but I can insert a jump and reserve some space in head.S
<apritzel>
the fill the gaps with their magic data
<wens>
you need the special boot0 binary for fel, likely called fes1
<wens>
which returns execution back to FEL
<ssvb>
wens: I guess, apritzel wants to have somethong that is bootable from mmc
<wens>
right, then you'd have to go with their magic header and checksums
<apritzel>
ssvb: wens: yes, MMC
<apritzel>
I guess I need their checksum generating binary?
<ssvb>
frankly speaking, I don't quite like such use of boot0 because people will be happy with it and assume that the problem has been solved ;)
<ssvb>
apritzel: mksunxiboot does this checksum stuff for the SPL
<apritzel>
ssvb: this is for the moment and plan B for the case that Allwiner does not provide the source
<ssvb>
the plan B is reverse engineering of libdram
<apritzel>
has boot0 been replaced by reverse engineering in the past (for other SoCs)?
<apritzel>
Ah, I C
<apritzel>
is it about the DRAM parameters only?
<apritzel>
or are there magic algorithms involved
<apritzel>
?
<apritzel>
or do they use a different DRAM controller in the A64?
<ssvb>
libdram apparently also sets up PLL5
<apritzel>
which drives the controller?
<ssvb>
each Allwinner SoC has a slightly different DRAM controller
<wens>
pll5, dram controller, maybe critical regulators
<ssvb>
disassembling the libdram blob is relatively easy, but doing it in a clean and legal way may be a hassle
<apritzel>
you mean following clean room rules?
<ssvb>
yes
<ssvb>
we can cut some corners, but this makes us vulnerable to a potential legal retaliation from Allwinner (hopefully this is extremely unlikely though)
<apritzel>
ssvb: maybe this can be avoided by TL intervening
<apritzel>
also not sure Allwinner takes someone to court (thinking of their GPL violations) ;-)
<wens>
imagine the retaliation lawsuits they'd get
<ssvb>
yes, I hope that TL succeeds in convincing Allwinner to open source libdram for A64
<apritzel>
ssvb: mksunxiboot is only for the checksum that the BROM requires, right?
<apritzel>
ssvb: AFAICT boot0 itself uses a different checksum'ed header?
<apritzel>
or is the checksum algorithm the same?
Netlynx has quit [Quit: Leaving]
<ssvb>
apritzel: SPL and boot0 should use the same checksum, because it is the BROM thing
<apritzel>
yeah, sorry, wrong writing
<apritzel>
I meant that the parts that boot0 _loads_ have a different header
paulk-collins_ has quit [Quit: Quitte]
<ssvb>
oh, does it have one more checksum?
<wens>
the u-boot source should have something on that
<wens>
private-header.h or something
<apritzel>
apparently, looking at the Allwinner hacks in their U-Boot and ATF source
<apritzel>
yes
<apritzel>
AFAICT they rely on an x86-64 binary for generating the checksum
<ssvb>
"Thus, instead of being nice they decided to go and hit us badly"
<ssvb>
"SCUMM engine, later versions of which is used in Humongous Entertainment games is one of the engines which was reverse engineered, and that is what the lawyers tried to blackmail us for."
<plaes>
hrm.. that Jide HW looks almost as bad as Intel Compute Stick's Ubuntu Edition one.. :S
<plaes>
realtek8723 (sdio?) and 1GB or RAM :P
<apritzel>
plaes: there are 2GB versions
<apritzel>
and what do you mean by bad? You can't stuff a bunch of high-performance hardware into a 50$ product
IgorPec has joined #linux-sunxi
<plaes>
well, it's mainly Intel's fault ;)
<plaes>
I recently helped a company here who's using Intel Compute sticks in one of their services
<plaes>
and factory-installed Ubuntu version (that had 1G of RAM) didn't work at all as one would expect
<plaes>
it had Gnome3 and starting Firefox was enough to trigger OOM :)
<longsleep>
apritzel: hey i am back now if you got some time to discuss the pine64 boot
<apritzel>
longsleep: sure
<apritzel>
longsleep: so what's your issue, exactly
<apritzel>
?
<plaes>
+ it had the rtl8723bs driver via dkms
<longsleep>
apritzel: so what works is booting the binary blobs from your image with a fat partition and loading kernel and dtb with fatload
<longsleep>
apritzel: now as i need to change uboot, i built some gear to build u-boot from BSP source, u-boot works fine as well but fails to boot kernel
<longsleep>
apritzel: the problem is i do not know why, i guess it is somewhat related to the device tree or i might have missed something
<apritzel>
how do you boot the kernel? which command?
<apritzel>
and which bitness? 64-bit?
<longsleep>
boota, i did not patch bootz yet to do the 64bit reset stuff
<longsleep>
u-boot is 32 bit, kernel 64bit
<apritzel>
bootz will not work anyway, because it's about the arm(32) kernel image
<apritzel>
you need the booti command from upstream u-boot
<longsleep>
right, meant bootm
<longsleep>
well, for now i stick to boota as this has the gear already
<apritzel>
so their boota ignores any fdt addr setting, for instance
<apritzel>
it always uses the hosted DT
<apritzel>
so though you can load a DT and set the address to it ("fdt addr $fdt_addr" or the like)
<longsleep>
let me post a log
<apritzel>
boota will _not_ use this address
<apritzel>
no output is usually due to a broken DT
<apritzel>
so my guess is that it still uses the Allwinner DT
<apritzel>
which goes nowhere with an upstream kernel
<longsleep>
ah
<longsleep>
so even if i load your dtb it still passes the one which i compiled into u-boot?
<apritzel>
shouldn't be too hard to hack the boota command, though
<apritzel>
yeds
<apritzel>
yes
<longsleep>
i assume you do not have the fex file they used to build the u-boot?
<apritzel>
I try to ignore any of that fex crap ;-)
<apritzel>
longsleep: using their for 64-bit will go nowhere ;-)
<longsleep>
apritzel: yeah, is there any u-boot 64-bit platform out there?
domidumont has joined #linux-sunxi
<apritzel>
yes, I am using it on my Junos
<apritzel>
but I have the impression that it would more effort to get that to work
ricardocrudo has quit [Ping timeout: 272 seconds]
<apritzel>
adding sun50i support to the existing sunxi 32-bit port is much easier (if you look at ssvb's repo)
<longsleep>
well, i have came to the conclusion some years ago that i should stop caring about everything which happens before the Kernel overly much :)
<longsleep>
apritzel: yeah i looked at the repo last week and it worked fine, but 32 only for now
<longsleep>
boots 32 bit only i mean
<longsleep>
then that boots 64bit kernels on top of boot0 and with the help of arm-trusted-firmware stuff then this is something
<apritzel>
I know, that's the other thing I want to look at the weekend:
<apritzel>
add that Allwinner special ATF call to get from 32-bit to 64-bit to (upstream) U-Boot
<apritzel>
and probably include the booti command
<longsleep>
bad thing is, each weekend has only 2 days :/
<apritzel>
and lots of other stuff to do as well ;-)
<longsleep>
well it should be rather easy to add the code from boota to any other u-boot, if that u-boot gets accepted by boot0/bl31
<longsleep>
maybe it is also feasible to remove the check from bl31
<longsleep>
i did not look at the patchset though
<longsleep>
just was happy that it compiles
jinzo_ has quit [Quit: Leaving]
<apritzel>
not even sure that bl31 itself cares about the checksum
<apritzel>
I guess it's boot0 that checks U-Boot's checksum before calling bl31
<longsleep>
yeah could be
<apritzel>
but that's worth checking ...
<longsleep>
just doing that
<apritzel>
then we could just remove the check from bl31 ;-)
<ssvb>
apritzel: would the linux kernel be able to work in EL3 and without ATF if we try such a test?
<apritzel>
ssvb: I guess not
<apritzel>
ssvb: are you thinking about a RMR from your u-boot?
<apritzel>
you could do this, but not directly into the kernel
<apritzel>
but instead to your own trampoline code again
<apritzel>
which could drop to EL2
<apritzel>
but this has more implications
<apritzel>
that's why ATF is a good thing to have, because it takes care about this
<apritzel>
ssvb: if you are interested, look at the bootwrapper
MackBoy has quit [Remote host closed the connection]
MackBoy has joined #linux-sunxi
libv_ is now known as libv
domidumont has quit [Ping timeout: 246 seconds]
ricardocrudo has joined #linux-sunxi
jstein has joined #linux-sunxi
jstein_ has quit [Ping timeout: 252 seconds]
bonbons has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Equilibrium 4.2.0, revision: 42021, sources date: 20120701, built on: 2013-10-21 12:25:22 UTC 42021 http://www.kvirc.net/]
<cptG>
forgive me if this is a stupid question, but: can gdb be attached to uboot running on the device (have UART, ETH, USB otg)?
IgorPec has joined #linux-sunxi
IgorPec has quit [Ping timeout: 272 seconds]
<longsleep>
Success, Pine64 self compiled U-Boot now boots after hacking boota to pass correct dtb address. Full boot log here: http://paste.ubuntu.com/14947706/
indy has quit [Ping timeout: 264 seconds]
indy has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 240 seconds]
libv_ is now known as libv
cosm has quit [Ping timeout: 240 seconds]
apritzel has joined #linux-sunxi
<longsleep>
apritzel: Making boota use the loaded fdt did the trick. Self compiled u-boot now boots your Kernel tree.