<foxx_>
but the uboot checksum remains the same in the image
<foxx_>
(i've added some code locally to dump it)
<apritzel>
yeah, but the issue was that --device does seeks on the block device, so any garbage that's on the card gets skipped, but boot0 reads this anyway and calculates the checksum based on that
<apritzel>
the fix was to fill this space with zeroes
<apritzel>
dumping to a temp file and dd'ing that should have the same effect
keh has quit [Quit: = ""]
Michal has quit [Ping timeout: 244 seconds]
<foxx_>
no luck with temp file either
kelvan has quit [Ping timeout: 264 seconds]
<foxx_>
grabbing checksum from boot0 output and hardcoding it into uboot header structs in boot0img.c helps with that stage
<apritzel>
I know ;-)
<apritzel>
could you try with -p 100 on the temp file?
<apritzel>
and then skip the generated partition table on the dd?
<foxx_>
ok, will try
<apritzel>
I remember I reworked most of that offset calculation code with the fix, possibly there was another bug
<apritzel>
foxx_: sorry for that mess, the test matrix for boot0img is now quite big, you seem to exactly poke in the holes I haven't tested ;-)
Da_Coynul has joined #linux-sunxi
<foxx_>
that's okay :) it's just a hobby for me
<foxx_>
glad if I could help with anything
<apritzel>
I will push the fix tonight and would be happy if you could test it again then
<foxx_>
thanks
popolon has quit [Ping timeout: 252 seconds]
Michal has joined #linux-sunxi
<enrico_>
oliv3r: lime2 with emmc needs all the "fixes" (randomizer, bit flips etc...) like the nand version or you can just use it without all that troubles?
aballier has quit [Quit: leaving]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
aballier has joined #linux-sunxi
aballier has quit [Changing host]
aballier has joined #linux-sunxi
Michal has quit [Ping timeout: 244 seconds]
Michal has joined #linux-sunxi
<foxx_>
apritzel: FYI, making clean image with -p and dd'ing it workarounds boot0 stuck on checksum
<foxx_>
but next it stucks on 'Jump to secend Boot'
<apritzel>
foxx_: are you using the latest upstream U-Boot?
<apritzel>
if yes, can you retry a few times?
<foxx_>
tagged as v2016.09-rc1
<apritzel>
(reset or power cycle)
<apritzel>
there seems to be some nasty bug, which I haven't tackled yet
<apritzel>
v2016.07-rc1 works fine for me, also every version when using FEL boot
<apritzel>
I tried to bisect twice between -rc1 and v2016.07, but it didn't help
<apritzel>
also for confirmation can you build ATF with DEBUG=1 to see if it runs?
<foxx_>
yes, in an hour
aballier has quit [Quit: leaving]
Wizzup has quit [Ping timeout: 244 seconds]
Da_Coynul has joined #linux-sunxi
aballier has joined #linux-sunxi
Wizzup has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Michal has quit [Ping timeout: 244 seconds]
therealfibonacci has joined #linux-sunxi
<foxx_>
multiple resets doesn't help
<foxx_>
debug ATF gives 'INFO: BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9' as a last boot string
Michal has joined #linux-sunxi
<aalm>
apritzel, w/regards to above, i was unable to find the binaries i had used, so i never got around testing if retrying would help :/
cptG_ has joined #linux-sunxi
<foxx_>
apritzel: v2016.07-rc1 passes init boot sequence ok
cptG has quit [Ping timeout: 260 seconds]
<NiteHawk>
didn't we introduce a modified SPL header for sunxi in v2016.07? maybe there's something going on with that... (just a random thought)
<NiteHawk>
u-boot commit b19236f
Dodger78 has joined #linux-sunxi
Dodger78 has quit [Client Quit]
Dodger78 has joined #linux-sunxi
Dodger78 has quit [Client Quit]
Dodger78 has joined #linux-sunxi
imcsk8 has quit [Ping timeout: 252 seconds]
kaspter has joined #linux-sunxi
jukivil1 has quit [Ping timeout: 264 seconds]
Michal has quit [Ping timeout: 244 seconds]
Michal has joined #linux-sunxi
clonak has quit [Ping timeout: 240 seconds]
popolon has joined #linux-sunxi
Michal has quit [Ping timeout: 244 seconds]
<apritzel>
NiteHawk: this issue is with boot0 only, I couldn't reproduce it with SPL
<apritzel>
foxx_: yes, that is the issue then, U-Boot hangs quite early in start.S
<montjoie>
apritzel: thanks for the endianess, I will test it this week end
clonak has joined #linux-sunxi
<apritzel>
montjoie: I think I have a big-endian ARMv7 initrd somewhere, in case you need this
jukivili has joined #linux-sunxi
<apritzel>
montjoie: I used this to test a similar fix for the MMC driver (which also uses DMA descriptors) on my BPi-M1
<montjoie>
I need to publish my v3 soon
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
<foxx_>
the cause of boot stuck for uboot is 1a83fb4
<montjoie>
apritzel: dmap_map_xxx does not need to have endianess function on their return right ?
<foxx_>
uboot v2016.09-rc1 boots with 1a83fb4 reverted
<apritzel>
foxx_: I think that's a red herring
<apritzel>
we had this commit under suspicion before
<apritzel>
AFAICT this affects SPL code only anyway
<apritzel>
can you try to reboot several times?
<apritzel>
you may see the same issue as I did: sometimes it works
<apritzel>
I think we need to add debug UART TX register writes into start.S to spot the issue
<foxx_>
apritzel: rebooted many times already
<foxx_>
it's ok for me
<montjoie>
apritzel: oh you do it but after dma_mapping_error
<apritzel>
foxx_: have you ever tried the exact 2016.07 release before?
<foxx_>
another issue is that the kernel doesn't boot :)
<apritzel>
foxx_: details .... ;-)
<foxx_>
apritzel: nope, never. jumped to 2016.xx just yesterday
<foxx_>
tried longsleep's u-boot based on 2014.wtf before
<apritzel>
foxx_: so maybe it's another issue then, between 2016.07 and 2016.09-rc1
<NiteHawk>
ssvb: ^ commit 1a83fb4 has issues on A64 / pine64
<foxx_>
sure, I'm not a guru in u-boots
<foxx_>
but it gave me an entry point
Michal has joined #linux-sunxi
<apritzel>
NiteHawk: as mentioned we had this before, and this commit should only affect SPL, right?
<apritzel>
NiteHawk: which isn't used at all here (with boot0_
paulk-aldrin has quit [Quit: Leaving]
<NiteHawk>
apritzel: okay, i'm not sure that i followed the discussion closely enough. might better try to reproduce the issue first...
<apritzel>
montjoie: yes, otherwise we clobber the possible error code too early
Michal has quit [Ping timeout: 250 seconds]
<montjoie>
apritzel: added a comment for it:)
p1u3sch1 has quit [Ping timeout: 244 seconds]
<apritzel>
montjoie: yeah, good point, prevents the next one from stumbling over it ;-)
<montjoie>
apritzel: for v3 the number of comment change is more than code change:)
<apritzel>
that speaks for code maturity
p1u3sch1 has joined #linux-sunxi
<MoeIcenowy>
apritzel, foxx_: it's the same issue for me on 2016.07-rc3
<foxx_>
2016.07-rc3 contains 1a83fb4
<foxx_>
MoeIcenowy: try to revert it locally and check
<apritzel>
foxx_: but I think we tried reverting that, in the end it turned out to be something with tiny_printf, which we fixed
<MoeIcenowy>
I'm recently playing with my CHIP
<MoeIcenowy>
and waiting for the A64 clock-ng driver by mripard to be merged
<apritzel>
MoeIcenowy: which reminds me of finishing that email response on that
<montjoie>
apritzel: due to number of users of cpu_to_le32(BIT(x)), perhaps sending a patch of LE32_BIT() could be done:)
<apritzel>
montjoie: oh, indeed, I haven't actually checked for other users
<apritzel>
great, a mini-series touching code all over the place ;-)
<MoeIcenowy>
apritzel: it seems that mripard's patch enabled rsb?
<apritzel>
MoeIcenowy: I think he just mentioned it, but I couldn't find it
<foxx_>
guys, I came into kernel boot problem now
Michal has joined #linux-sunxi
<foxx_>
uboot finds the kernel, tries to load and start it, and that finishes with 'Timer summary in microseconds:' message immediately after booti command
<foxx_>
could someone give an entry where to dig?
kaspter has quit [Ping timeout: 276 seconds]
<foxx_>
this particular kernel booted well with longsleep' uboot a few days ago
aalm has quit [Ping timeout: 244 seconds]
<longsleep>
foxx_: can you post your full output - eg to paste.ubuntu.com or something
<apritzel>
foxx_: which code base is this? is this an upstream kernel?
<apritzel>
foxx_: you can't boot a BSP based kernel on an "upstream" firmware chain (ATF & U-Boot)
<apritzel>
much to longsleep's dismay ;-)
<longsleep>
yeah .. :/
<foxx_>
kernel is apritzel/a64-v5 merged with upstream 4.7
<apritzel>
foxx_: can you post the exact log somewhere?
<ssvb>
foxx_, apritzel: this is a bit bizarre, I'm now checking why it ends up this way
<apritzel>
ssvb: indeed strange, thanks for looking into this ...
ikmaak has joined #linux-sunxi
<foxx_>
ssvb: well, i have much more differencies between working and non-working disasms :)
Nacho has quit [Ping timeout: 250 seconds]
<foxx_>
i'm just unsure what's really important
Nacho has joined #linux-sunxi
<ssvb>
foxx_: how are you building it?
<foxx_>
ssvb: what exactly? uboot? disasms?
<wens>
plaes: axp818 and axp813 seem to be the same
<plaes>
so that's why it's called axp81x?
<ssvb>
foxx_: I'm essentially doing "export SOURCE_DATE_EPOCH=1 && make pine64_plus_defconfig && make && sha256sum u-boot-dtb.bin" and there is one byte difference in the binary diff
<ssvb>
foxx_: and I don't revert the commit but patch the sources, so that in both cases it is labeled as "U-Boot 2016.09-rc1-dirty (Jan 01 1970 - 00:00:01 +0000) Allwinner Technology"
<foxx_>
ssvb: make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- -j9 mrproper && make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- -j9 pine64_plus_defconfig && make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- -j9
<foxx_>
both for reverted and non-reverted sources
<ssvb>
whatever, I'm getting a much smaller difference than you, so I probably did a somewhat better job filtering out the noise :)
therealfibonacci has quit [Quit: Leaving.]
<foxx_>
ssvb: i did aarch64-linux-gnu-objdump -C -d u-boot
<ssvb>
foxx_: as I said, I'm pretty happy with my diff and it already shows that something changes while it shouldn't
<ssvb>
still, it is your U-Boot binary that fails to work correctly, so we can't be sure that this particular 'clear_loop' thing is to be blamed for it
<ssvb>
but we normally should expect exactly the same binary (with the SPL-specific defines having no effect on it), assuming that U-Boot is really built in the same conditions
reinforce has quit [Quit: Leaving.]
<ssvb>
ok, it's CONFIG_SYS_INIT_RAM_SIZE define responsible for this
apritzel has joined #linux-sunxi
afaerber has joined #linux-sunxi
Netlynx has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
<ssvb>
foxx_: looks like there is some disagreement between armv7 and aarch64 in the way how they set the stack pointer in the initial startup code
Amit_t_ has joined #linux-sunxi
<ssvb>
I'll try to do a bit more tests and submit a fix
afaerber has quit [Ping timeout: 250 seconds]
afaerber has joined #linux-sunxi
<foxx_>
ssvb: that's too deep for me :) but thanks
<foxx_>
finally I've got pine64 fully booted with latest uboot and 4.7 kernel with gmac/phy working out of the box and now I'm really happy
<JohnDoe_71Rus>
enthusiasts write driver. Manufacturers release new chips. Interest switched to new items. It is sad.
Amit_t_ has quit [Ping timeout: 250 seconds]
IgorPec has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
apritzel has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
reinforce has joined #linux-sunxi
mossroy has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
Mr__Anderson has joined #linux-sunxi
popolon has quit [Ping timeout: 240 seconds]
diego_r has quit [Quit: Konversation terminated!]
enrico_ has quit [Quit: Bye]
massi has quit [Remote host closed the connection]
Mr__Anderson has quit [Remote host closed the connection]
apritzel1 has quit [Ping timeout: 244 seconds]
ricardocrudo has quit [Remote host closed the connection]
matthias_bgg has quit [Quit: Leaving]
IgorPec has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
jbrown has quit [Quit: Leaving]
aalm has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
paulk-collins has joined #linux-sunxi
vagrantc has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
Michal has quit [Changing host]
Michal has joined #linux-sunxi
foxx_ has quit [Ping timeout: 260 seconds]
raknaz has joined #linux-sunxi
raknaz has quit [Client Quit]
p1u3sch1 has quit [Ping timeout: 258 seconds]
p1u3sch1 has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
<topi`>
has anybody compiled McCalpin's stream.c for the A64? I'm interested how it compares to e.g. S905
p1u3sch1 has quit [Ping timeout: 258 seconds]
foxx_ has joined #linux-sunxi
p1u3sch1 has joined #linux-sunxi
fl_0 has quit [Quit: STRG + Q]
foxx_ has quit [Ping timeout: 250 seconds]
jbrown has joined #linux-sunxi
mzki has joined #linux-sunxi
Mr__Anderson1 has joined #linux-sunxi
BenG83 has joined #linux-sunxi
Mr__Anderson has quit [Ping timeout: 258 seconds]
iamfrankenstein has quit [Quit: iamfrankenstein]
ricardocrudo has joined #linux-sunxi
mzki has quit [Quit: leaving]
koza_ has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
koza_ has quit [Client Quit]
mzki has joined #linux-sunxi
fl_0 has joined #linux-sunxi
tsuggs has quit [Ping timeout: 240 seconds]
tsuggs has joined #linux-sunxi
fl_0 has quit [Quit: STRG + Q]
fl_0 has joined #linux-sunxi
tsuggs has quit [Ping timeout: 244 seconds]
afaerber has quit [Quit: Ex-Chat]
Mr__Anderson1 has quit [Ping timeout: 250 seconds]
Mr__Anderson has joined #linux-sunxi
apritzel has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 4.9.2, revision: git-6627-gf708225, sources date: 20160102, built on: 2016-05-12 17:32:15 UTC git-6627-gf708225 http://www.kvirc.net/]
Andy-D has quit [Remote host closed the connection]
Mr__Anderson has quit [Ping timeout: 258 seconds]
al1o has joined #linux-sunxi
mzki has quit [Quit: leaving]
gzamboni has quit [Ping timeout: 250 seconds]
paulk-collins has quit [Quit: Leaving]
jstein has quit [Read error: Connection reset by peer]