<KotCzarny>
sure, but fun to read that it got enabled BY DEFAULT
<jelle>
config or compile time
<KotCzarny>
which means debian might be bad system to use on servers ;)
<jelle>
pretty sure they will fix it
<KotCzarny>
sure, but also shows that current debian maintainers are just wrong
<KotCzarny>
and breaking things RH-like
<KotCzarny>
or MS-like, where they know better than USER (which should be nanny-treated, because USER is clearly an idiot)
ganbold has quit [Ping timeout: 260 seconds]
<KotCzarny>
which also mean linux is going mainline! because there is a need to adjust to much grown IDIOTUSER base
<KotCzarny>
s/mainline/mainstream/
medvid has joined #linux-sunxi
raknaz has joined #linux-sunxi
raknaz has quit [Client Quit]
alchemist87_it has joined #linux-sunxi
mosterta has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
NiteHawk: indeed, it's basically ssvb's original 32-bit U-Boot SPL work ported over to upstream U-Boot, then cat'ed with the upstream 64-bit u-boot.img
<apritzel>
and with "rmr64" I don't need patches on the 64-bit side anymore
<NiteHawk>
that's nice
<Amit_T>
apritzel: are you booting pine64 (ATF+U-boot) through fel without patches now ?
Mr__Anderson has joined #linux-sunxi
<apritzel>
Amit_T: well, you need some patches to generate the 32-bit SPL
<Amit_T>
apritzel: ok, could you please point to it ?
apritzel1 has joined #linux-sunxi
mosterta|2 has joined #linux-sunxi
IgorPec has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
mosterta has quit [Ping timeout: 240 seconds]
premoboss has joined #linux-sunxi
lemonzest has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
ganbold has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
kaspter has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
<apritzel>
ssvb: looks like someone saves 1500 US$ ;-)
<ssvb>
apritzel: actually it was a kind of serious question :-) does your chip look like the upper or lower picture?
jernej has quit [Ping timeout: 264 seconds]
<ssvb>
but now I at least have several of these SPI flash chips and can attach them to several boards and run tests without re-plugging wires
<ssvb>
oh, and the "real" one seems to be at least a bit faster, maybe I can actually get closer to the theoretical peak flashing speed as advertised in the manual
<apritzel>
ssvb: my 128Mbit chip has no Winbond name on it, so it looks like the lower picture
<ssvb>
apritzel: as expected :)
<ssvb>
so this Dutch/Polish guy is probably getting these chips from some shady source, and another funny thing is that he sells 80B chips at a rather high price, while it is in fact a 8 Mbit variant
<apritzel>
ssvb: so indeed you got me ;-)
<apritzel>
echo -e "80\n128" | sort
<apritzel>
shows that 80 is bigger than 128 ;-)
paulk-collins has quit [Ping timeout: 260 seconds]
<apritzel>
and I am pretty far with a README.pine64 to document the various hacky ways to get upstream U-Boot running on the Pine64
paulk-collins has quit [Remote host closed the connection]
<ssvb>
apritzel: thanks!
<apritzel>
including the 32/64 bit chimera for FEL booting ;-)
<ssvb>
well, the 32/64 bit booting is quite reasonable, we probably don't want to switch the SPL to 64-bit mode anyway because of the size restrictions
<apritzel>
admittedly it works quite well, but it's quite a pain to build
<ssvb>
well, say thanks to the AArch64 toolchain guys for not implementing the -m32 option
<apritzel>
and I think agraf did some experiments with a 64-bit SPL and the binary size was not really an issue
<apritzel>
ssvb: well, they are really two different architectures, so I can understand this
<ssvb>
frankly speaking, I don't believe this and want to see some numbers :-)
<apritzel>
but yeah, it's something we tease them at lunch about sometimes ;-)
<apritzel>
then they tease back with us uniting arm and arm64 in the kernel ;-)
<ssvb>
it is really silly and a poor design
<ssvb>
afaik clang supports multiple architectures in a single compiler
<ssvb>
GCC is able to at least support 32-bit and 64-bit flavors on every architecture except ARM, even though it was not very pretty
<apritzel>
but for instance on x86 the variants are so close that it's justified, I think the other archs as well
<ssvb>
but ARM is exactly the same as the other architectures, there is no difference at all
<apritzel>
I mean the differences between PowerPC 32 & 64 or x86-32 and x86-64 are really small, but between AArch32 and AArch64 it's much bigger
<apritzel>
but I agree that GCC is a bit, say handicapped by its architecture
<ssvb>
hmm, I think that the difference between x86-32 and x86-64 is much bigger than between AArch32 and AArch64
<ssvb>
well, maybe not much, but still bigger
<apritzel>
- the opcodes are practically identical (it's just the REX prefix minus the single-byte inc & dec instruction)
<ssvb>
who cares about the opcodes? binutils takes care of this and it is much more simple than GCC
<apritzel>
but also the instructions are the same
<apritzel>
on AArch64 you can't even do a "mov %w0, #0x44"
<apritzel>
which works fine on ARM (s/w/r/)
<apritzel>
scratch that %, my brain was half stuck in x86 world ;-)
<ssvb>
still a solution for GCC is really simple
<apritzel>
but I agree that it would be possible and beneficial to have a joint compiler
<ssvb>
the AArch64 toolchain should just try to call "arm-linux-gnueabihf-gcc" whenever it detects "-m32" option in the command line
<ssvb>
and bail out with a comprehensive error message when the arm-linux-gnueabihf cross-toolchain is not installed
<ssvb>
this would do the job for the U-Boot build
<apritzel>
mmh, sounds like a small hack in the compiler driver ;-)
<apritzel>
wouldn't work for me, its arm-slackware-linux-gnueabihf-gcc over here :-D
<ssvb>
"Even though Gentoo normally uses armv7a-hardfloat-linux-gnueabi as the toolchain triplet on ARM, we can also use Debian alike arm-linux-gnueabihf variant in order to be able to use the compilation instructions from the linux-sunxi wiki as-is (without substituting the toolchain name)"
<apritzel>
well, I built those cross-compilers myself, so the triplet was a deliberate choice, but it's the Slackware standard and also used on the respective native ports
<apritzel>
also I have a neat script, which gets sourced, so I just type "cross arm" or "cross arm64" and be done
<apritzel>
(and I can translate linux-sunxi Wiki instructions on the fly)
<ssvb>
still the fallback 32-bit toolchain name could be also configurable as a part of the aarch64 toolchain build (and the distributions could tweak it according to their own naming standards)
<apritzel>
sure
<apritzel>
care to send a patch?
<ssvb>
not today :-)
<apritzel>
fair enough: (23:59:57) ssvb: not today
<ssvb>
I think that the non-marked one was showing ~140 kB/s at best
<apritzel>
do you have some SPL SPI flash loading in place already?
<ssvb>
not yet, but I'm working on this and your U-Boot branch will be handy for testing
<apritzel>
ssvb: if you boot from SD or SPI, you need some kind of RMR switch in between SPL and U-Boot, which is not on the branch yet (as sunxi-fel does this now)
<apritzel>
ssvb: I can send you this magic switcheroo hack, which allows main U-Boot to be entered in AArch64 or AArch32 (doing the RMR in the latter case)
<ssvb>
apritzel: can you just push it to your branch (the SD card boot support)?
<apritzel>
well, the problem is that it clashes with the boot0 support and I haven't found a nice solution for this yet
<apritzel>
(but for real boot0 support there is one patch missing anyway in this branch, so I will push the patch in a minute)
reinforce has quit [Quit: Leaving.]
adj__ has quit [Ping timeout: 244 seconds]
adj__ has joined #linux-sunxi
<apritzel>
yup, works via FEL with just "uboot u-boot-3264.bin" or from the SD card