<willmore>
lennyraposo, I will be getting a pine64 this week, what does a total noob need to read to get started? I don't need video out, just network.
<lennyraposo>
well in development?
<lennyraposo>
told ot study the dts files
<lennyraposo>
understand the hierchy
<lennyraposo>
or just getting your board up and running?
<lennyraposo>
if that's the case
<lennyraposo>
longsleep's image build is a good place to start
<lennyraposo>
he has base image for xenial
<lennyraposo>
or if you prefer to do your own hsi simple image is agreat place to start
<lennyraposo>
but for learning I would say looking at his github is agood place to staart to get familiar
<lennyraposo>
I'm just experimenting with what does what at this time
<lennyraposo>
reviewing the history of changes on things to see what is going on to better understand
<luoyi>
because in the bpi M1+, I've to use interrupts = <7 15 0x00000008> ,which is differ from that patch. so I don't know how to get the right value of that line
<luoyi>
away for a while.
prasannatsm has left #linux-sunxi ["Part"]
<wens>
pine64 finally arrived
<wens>
surface mail... sheesh
<lennyraposo>
hehe
<wens>
also the "R.O.C" portion of the mailing address was redacted lol
<lennyraposo>
still awaiting the rest of my shipment
<lennyraposo>
a lot to do for their campaign I suppose
<KotCzarny>
wens, maybe that was the reason of the delay, lots of hand made art work ;)
<wens>
IR receiver sticks up too high for the case :p
<wigyori>
that's probably an old one, not sure if it was updated since
<luoyi>
well, I've used this value to get my dtb file, and wifi is working well
<wigyori>
mkay
<luoyi>
it says: , with the interrupt pin number modified according to the schematic diagram
<luoyi>
don't know what's the excat interrupt pin number means
IgorPec has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
massi_ has joined #linux-sunxi
KotCzarny has joined #linux-sunxi
reev has joined #linux-sunxi
<wens>
7 == H, so <7 10 X> is EINT on pin PH10
<wens>
luoyi: exact interrupt pin number means whatever pin (ex. PH10) the OOB interrupt line from the brcm chip is connected to
<wens>
it is something in the board design
FlorianH has joined #linux-sunxi
caog has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
willmore: what makes you think ATF is a horrible implementation? (just asking)
<Amit_T>
apritzel: Hello, Just to check that how do I make sure that PHY is really powered up, I see that there is no special PHY driver is required and Gen PHY driver should be enough.
<apritzel>
Amit_T: that is the million dollar question ;-)
<KotCzarny>
multimeter?
<KotCzarny>
:>
<wens>
afaik the LEDs will start flashing if the PHY is powered
<Amit_T>
apritzel: ok, any thing I could try in this regard ?
vickycq has quit [Ping timeout: 252 seconds]
<apritzel>
wens: Is it? Does the PHY without initialization and programming drive the LEDs according to the link status?
<Amit_T>
wens: In case of orangepi pc , if we set proper emac clock , LEDs will start flashing
<apritzel>
Amit_T: as KotCzarny said: you could try a multimeter if you have one
<apritzel>
Amit_T: also digging through some BSP crap to see which regulator rail the driver enables
<wens>
apritzel: i thinks it what the PHY does by default, but of course it is configurable
<wens>
Amit_T: yes
vickycq has joined #linux-sunxi
FlorianH has quit [Ping timeout: 244 seconds]
premoboss has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
yann|work has joined #linux-sunxi
yann|work is now known as yann
<luoyi>
wens: thanks for your explain. but I can't find the wifi oob interrupt line or flag in the cubietrunk schematic diagram file
<wens>
there's a line named "WIFI-HOST-WAKE"
<luoyi>
in the wifi&bt page, it just says: SDIO-D1/SDIO-D2/.../WL-HOST-WAKE and so on ...
<luoyi>
OK, I'll give a check
<wens>
WIFI / WL -HOST-WAKE
IgorPec has quit [Read error: Connection reset by peer]
<luoyi>
OK, find this line, but how can I know that it connect to PH7 ?
<luoyi>
hmmm.. great
<luoyi>
page 2
<luoyi>
WIFI-HOST-WAKE PH10
IgorPec has joined #linux-sunxi
<luoyi>
and in bpi m1+'s schematic , it's PH15
<luoyi>
wens: very thanks for your explainaion.
caog has left #linux-sunxi ["Ex-Chat"]
ricardocrudo has joined #linux-sunxi
IgorPec has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
FlorianH has joined #linux-sunxi
juri_ has quit [Ping timeout: 260 seconds]
creemj has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
hrw has left #linux-sunxi [#linux-sunxi]
juri_ has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
FlorianH has quit [Ping timeout: 260 seconds]
webmind has quit [Ping timeout: 260 seconds]
matthias_bgg has joined #linux-sunxi
kaspter has joined #linux-sunxi
andoma has quit [Remote host closed the connection]
andoma has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 252 seconds]
iamfrankenstein1 is now known as iamfrankenstein
<igraltist>
hi
<igraltist>
i use on cubietruck the wifi as accesspoint with kernel 4.4.9. when i set this ht_capab=[HT40] the connection always stall after short time inactivity. without this all running fine.
<igraltist>
so could the chip become to hot because somehow powersave does not work?
ricardocrudo has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
<wens>
i've not tried this, but it seems more of a problem with the chip itself?
<luoyi>
does your dmesg have 'brcmfmac: power management disabled' such line ?
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
<igraltist>
luoyi: i dont have such line
paulk-collins has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
tsuggs has quit [Ping timeout: 276 seconds]
<luoyi>
igraltist: maybe you can try to disable the power management
tsuggs has joined #linux-sunxi
<Tusker>
FYI: I'm just testing an autobuild script for the BPiM3 (builds a bootable SD card, with jessie installed) - http://pastebin.com/a5zqELgZ
<Tusker>
any comments would be appreciated
<KotCzarny>
tusker: post it to armbian forums maybe?
<Tusker>
yeah, that might be a good idea
<KotCzarny>
hrm
<KotCzarny>
which package provides 'mount' in diablo?
staplr has joined #linux-sunxi
nabblet has joined #linux-sunxi
<nabblet>
hi, I installed gentoo (with your sunxi modfied u-boot and kernel) and saw that you now recommend going mainline for u-boot and kernel if the server is headless (which is the case for me). What upgrade path do you recommend?
<nabblet>
Do you know of any incompatibilites between certain versions of uboot and the linux kernel (also taking in account that right now i am using the sunxi mods)
tkaiser has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
<tkaiser>
lvrp16: Regarding Armbian repos. We use an own for u-boot, kernel and board support package (other stuff like Cedrus accelerated video players might follow) but for the main stuff the repositories configured through /etc/apt/sources[.d] are used (defaulting to standard locations for Debian and Ubuntu)
reinforce has joined #linux-sunxi
<nabblet>
My question is also motivated by "While the mainline kernel should work on any bootloader (with the major exception being the A20), you'll need a recent sunxi U-boot, or even better a Mainline_U-boot." from https://linux-sunxi.org/Mainline_Kernel_Howto
Gerwin_J has quit [Quit: Gerwin_J]
staplr has quit [Remote host closed the connection]
<willmore>
apritzel, Just that it's meant to be a trusted bit of code that always runs on a little processor that has god like control of the SoC, but the code on it is written at the last minute and is likely buggy as all hell. One could write a very nice ATF, but I don't see that happening a lot.
<willmore>
Has anyone seen an STL file for a Pine64 case, yet? :)
arossdotme has quit [Ping timeout: 252 seconds]
IgorPec has joined #linux-sunxi
Shirasaka-Hazumi has quit [Ping timeout: 260 seconds]
<apritzel>
willmore: I think you are mixing things up here: ATF is running on the ARM cores, not the arisc
<apritzel>
also it's not "last minute and buggy as hell", it's a proper OpenSource project (driven by ARM) and actually used my the majority of ARM64 server boards out there
<apritzel>
for instance it cares about errata workarounds and the proper sequence of suspending and resuming CPUs (taking care of the GIC setup, for instance)
<apritzel>
willmore: were you be any chance referring to that Allwinner SCP blob, which runs on the arisc
<apritzel>
?
<willmore>
apritzel, I'm thinking of the bit of code that runs on a little Cortex-M(something) in many SoCs--like the S905 and handles a lot of low level settings of the SoC.
<apritzel>
willmore: yeah, that's not ARM trusted firmware
<willmore>
Okay, sorry for the misunderstanding, then.
<apritzel>
ARM Trusted Firmware is AArch64 only and it runs in EL3 on the ARM cores
<willmore>
What does it do?
book` has joined #linux-sunxi
<apritzel>
initializing the cores and the interrupt controller, and providing PSCI services (=SMP bringup)
<willmore>
Okay, that's useful.
<apritzel>
traditionally U-Boot tends to cover those things on ARM(32) cores in the past
<apritzel>
willmore: also it cares for errata workarounds
<apritzel>
it gets updated with the latest erratas and may enable chicken bits or the like to fix them
<apritzel>
think of what the core BIOS code does on a PC
<apritzel>
the good thing is that you can hide all those nasty details of a SoC specific setup in firmware
<apritzel>
and _any_ operating system can just use it easily
<apritzel>
and for the SCP bits (Allwinner code running on the arisc): I guess you are right, that's why I removed it from my latest image
<apritzel>
(and coded some of its functionality in ATF)
<willmore>
Understood. What are 'chicken bits'?
<apritzel>
bits in the core that enable or disable certain optimizations
<apritzel>
so if you introduce a new feature, say an agressive prefetcher or branch predictor, you add bits in the core to disable it
<apritzel>
so in case something goes wrong (a bug is found, which is not unlikely if it's new _and_ agressive), you can turn this feature off
<apritzel>
and ship the silicon anyway
<willmore>
Handy. Thanks for the education.
Tusker has quit [Quit: Time wasted on IRC: 2 hours 45 minutes 12 seconds]
<apritzel>
you wouldn't believe how useful this has been in the past - for every chip vendor out there
<willmore>
Looks like there was a lot done right in AARCH64.
<willmore>
apritzel, yeah, that's deep into the weeds.
juri_ has joined #linux-sunxi
<ssvb>
apritzel: "the good thing is that you can hide all those nasty details of a SoC specific setup in firmware" <- this is good as long as we still have full control over what's going on there
<ssvb>
which is not the case for ODROID boards
<apritzel>
but works for OpenSource firmware like ATF
<ssvb>
though I'm not sure about it being signed in C2, it could be just a binary blob
<ssvb>
probably somebody can try to patch it and see if it still boots :-)
<apritzel>
it says: "Bootloader signing process is not necessary for ODROID-C2 at all. "
<apritzel>
whatever that means exactly ;-)
<ssvb>
it means that signing is not needed for U-Boot
<apritzel>
and it looks like they describe how to build their U-Boot branch and run this, so I guess that works
<apritzel>
ssvb: yeah, but that bl1.bin.hardkernel is signed, I guess
<ssvb>
willmore: if you have a C2 board, then maybe you can try to patch one of the text messages inside of the bl1.bin.hardkernel binary, write it to the SD card and check if the system still boots
<ssvb>
willmore: if it boots, then it will be technically possible to eventually have an open source firmware for it
<ssvb>
willmore: but again, there may be a checksum in the header, so it's not completely trivial...
<rtp>
odroid c2 is s905 versus samsung for the others iirc
<ssvb>
yes, amlogic may be less evil than samsung :-)
<ssvb>
of course, normal users don't really care about these things, and signed binary blobs allow the SoC vendors to hide any kind of crap there
apritzel1 has quit [Ping timeout: 244 seconds]
<apritzel>
ssvb: well, "any kind of crap" sound like usual semiconductor business - you mess it up, get embarrassed, put something in firmware
<apritzel>
not sure that's really evil
<apritzel>
as I mentioned the other day: if it sets some secret chicken bits on power up and does some "magic" initialization here and there and then _stays out of the way_ for the rest, I am not so much against firmware blobs
premoboss has quit [Quit: Sto andando via]
<ssvb>
apritzel: in GP variants of OMAP3 and OMAP4, the boot ROM was dropping the CPU into the non-secure mode before passing control to the bootloader
<apritzel>
ssvb: yeah, I know, there was all kind of trouble with this in the past
* apritzel
prefers to not look back too much if possible
<apritzel>
that's why I kind of like Allwinner in this respect: they are unbrickable and one can completely replace the firmware
cnxsoft has quit [Quit: cnxsoft]
<wens>
the brom is sane, if not really flexible
juri_ has quit [Ping timeout: 276 seconds]
premoboss has joined #linux-sunxi
juri_ has joined #linux-sunxi
Amit_t_ has joined #linux-sunxi
nabblet has quit [Quit: leaving]
<apritzel>
wens: ah, good to know, has someone looked at it more thoroughly already?
premoboss has quit [Quit: Sto andando via]
<wens>
i think we have sources for some, disassembled and annotated versions of others
alain__ has joined #linux-sunxi
<alain__>
Quick question with Armbian running on OPI Plus, will I get both USB and Ethernet with the mainline kernel?
<montjoie>
alain__: no
<alain__>
too bad :) Any sight of your ethernet driver making it to mainline?
<montjoie>
need concensus on how to "driver" PHY
apritzel1 has joined #linux-sunxi
nove has joined #linux-sunxi
alain__ has quit [Quit: Page closed]
<wens>
the phy and syscon bits will most likely be folded into the driver
pietrushnic is now known as pietrushnic`away
<wens>
i will make time to do the modifications
pietrushnic`away is now known as pietrushnic
tkaiser has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
lemonzest has joined #linux-sunxi
jernej has joined #linux-sunxi
Andy-D has quit [Ping timeout: 260 seconds]
<igraltist>
btw, what is a good hz frequenzy for the cubietruck in kernelconfiog?
<willmore>
ssvb, I'll give that a try later this week when I get my SBC 'farm' back up. The 3D printer evicted them from where they had been.
massi_ has quit [Read error: Connection reset by peer]
Andy-D has quit [Ping timeout: 265 seconds]
vagrantc has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
Ultrasauce has joined #linux-sunxi
massi_ has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
jstein has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
jstein has quit [Remote host closed the connection]
avph has joined #linux-sunxi
FlorianH has quit [Ping timeout: 260 seconds]
avph has quit [Ping timeout: 260 seconds]
IgorPec has quit [Ping timeout: 265 seconds]
staplr has joined #linux-sunxi
avph has joined #linux-sunxi
buZz has quit [Ping timeout: 244 seconds]
avph has quit [Ping timeout: 260 seconds]
buZz has joined #linux-sunxi
buZz is now known as Guest43496
Guest43496 is now known as buZz
avph has joined #linux-sunxi
massi_ has quit [Remote host closed the connection]
avph has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
cosm has joined #linux-sunxi
prasannatsm has joined #linux-sunxi
FlorianH has joined #linux-sunxi
bmeneg has joined #linux-sunxi
<bmeneg>
hello everyone, are there any way to know where a GPIO pin is being used on my board? I mean, I would like to use a specific pin as normal GPIO, but the kernel reports me it is already in use, I would like to know who (which kernel module) is using it.
<NiteHawk>
bmeneg: for a 3.4.x kernel you should probably start by investigating the configuration in the .fex file - http://linux-sunxi.org/Fex_Guide
prasannatsm has quit [Ping timeout: 260 seconds]
prasannatsm has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
<bmeneg>
NiteHawk, the problem is I would like to use some pins as GPIOs that I had already configured on .fex file.. other places has the same pin number, but the module is not even being used, like "[mmc_para] ... sdc_used = 0"
<NiteHawk>
hmm... probably depends on the kernel whether it still 'claims' the gpio pin in question. for a test it should be simple enough to remove the "offending" definition from the .fex completely
<bmeneg>
let me see. I'll try with PG00, which was declared as 'gpio_pin_9 = port:PG00<1><default><default><1>' on fex.
<bmeneg>
so 'echo 9 > /sys/class/gpio/export' should work, right?
prasannatsm has quit [Ping timeout: 244 seconds]
<bmeneg>
NiteHawk, same results: sunxi_gpio_request can't request '[gpio_para]' '', already used ?
<NiteHawk>
i'm not sure which numbering scheme the 3.4 kernel uses there. PG00 might also be (6 * 32 + 0) = 192; if that's the cases you're asking for "PA09" with 9
<bmeneg>
NiteHawk, at https://linux-sunxi.org/GPIO says 3.4 schema uses the number after "gpio_pin_" declaration, this one you presented is true to the mainline kernel, but I'll try it anyway.
<bmeneg>
I'll try to export from 0 to 500 and see what happens.
mossroy has joined #linux-sunxi
prasannatsm has joined #linux-sunxi
<bmeneg>
NiteHawk, just PH20 and PB18 were exported successfully.
<bmeneg>
;/
<bmeneg>
nothing about PG00.
<NiteHawk>
:D well... you probably have to dig up what else claims the other gpios, or you might need to make them available explicitly (by adding pin definitions to the .fex)
apritzel has joined #linux-sunxi
<NiteHawk>
reading the GPIO page gives me the impressions the latter is actually a required step
avph has quit [Ping timeout: 260 seconds]
<bmeneg>
NiteHawk, the latter? I already explicitly added 67 GPIOs on .fex
<NiteHawk>
oh. i thought you might not have done that yet - but that's a different picture then. can you pastebin the .fex?
<NiteHawk>
you're missing gpio_pin_4 - maybe .fex compiler or kernel choke on that, or the resulting mismatch in gpio_num ?
<bmeneg>
as you can see lots pins were declared explicitly. others didn't, because I'm using them somehow different from GPIO, for instance UART or SPI pins.
<bmeneg>
NiteHawk, Hmm... that's a good point .
<ssvb>
bmeneg: PH10 is used in the wifi_para section, and it probably clashes with your gpio_pin_2 = port:PH10<0><default><default><0>
<ssvb>
bmeneg: I would not be surprised if this gpio list is only parsed until the first error and then everything else is ignored
<NiteHawk>
not sure if they all have to be sequential (and free of collisions with other sections) but it's remarkable that the two pins you mentioned working are right at the top of your gpio definitions
<bmeneg>
ssvb, but PB18 is exported wuth success.
<bmeneg>
yeah
<NiteHawk>
i agree with ssvb, that might be a case of "bail out" early...
<bmeneg>
ssvb, NiteHawk indeed. I'll take a close look again in all these pins.
<bmeneg>
I'll be back soon with some more info! thank you both!!
<NiteHawk>
btw: you might test it via a "round-trip" of .fex -> .bin -> .fex and compare the result, i suspect anything above gpio_pin_3 might already be missing
<bmeneg>
NiteHawk, your guess were right, although the "round-trip" showed exactly the same results compared to the original .fex file, the missing gpio_pin_4 corrupted everything above it!
<bmeneg>
NiteHawk, I made the right sequence till 8 and all 8 pins were exported.
<NiteHawk>
bmeneg: the .fex compiler probably just takes gpio_num and goes looking for matching pin definition lines. it fails on the gpio_pin_4, and quits :P
<bmeneg>
NiteHawk, probably! =P I didn't notice any kind of 'kernel warning' about it at dmesg, but it seems the correct answer!
<bmeneg>
NiteHawk, thank you very much! ssvb thank you too ;D
rellla has quit [Read error: Connection reset by peer]
<ssvb>
NiteHawk: unless I missed it, boot0img needs at least some basic documentation
<ssvb>
NiteHawk: also unless it works with boot0 images for other SoC variants, maybe we need to add a64 into its name
<NiteHawk>
yes, that's why i thought of keeping it in the branch for now, until we have decided how to proceed with "A64-support"
apritzel has joined #linux-sunxi
<apritzel>
ssvb: I will write something up for boot0img and push it to my repo for the time being
<apritzel>
I can check how it works with other SoC's boot0s, but frankly I don't see it being too useful once we have U-Boot SPL working
<apritzel>
which we do already for every SoC aside from the A64 ??
<ssvb>
apritzel: A80 has no SPL yet, but jemk had some experimental version of it
* vagrantc
pities the A80
<ssvb>
apritzel: IIRC the DRAM was unreliable unless significantly downclocked
<apritzel>
but boot0's DRAM setup is more stable at higher frequencies? Or is that a general problem?
jernej has quit [Quit: Konversation terminated!]
<apritzel>
so is the SPL DDR setup algorithm the reason for this, as we miss something that boot0 does?
<buZz>
like grabbing the fex file from some cheapskate android a10 tablet
<buZz>
without having to actually deal with android ^_^
<apritzel>
ok, well, to actually open an existing closed system
<buZz>
systems are ment to be open
<buZz>
if you love something, gotta set it free
<apritzel>
right, and in this case you don't need a "builtin su"
rellla_wc has joined #linux-sunxi
<apritzel>
unless you have a broken design, where some unprivileged process needs root access to achieve something
<apritzel>
like setting a GPIO pin or the like
<apritzel>
or mmapping /dev/mem
Graf_Ithaka has quit [Ping timeout: 276 seconds]
apritzel has quit [Ping timeout: 244 seconds]
IgorPec has joined #linux-sunxi
datagutt has joined #linux-sunxi
<datagutt>
Does Allwinner A64/H64 still support FES mode?
<ssvb>
datagutt: do you mean the binary only LiveSuit tool for Windows?
<datagutt>
Yes
<ssvb>
no idea, I'm not using Windows myself
<ssvb>
but https://linux-sunxi.org/FES works on top of a lower level FEL protocol, and FEL is supported on A64
<datagutt>
Well, neither Remix Mini or Pine A64 seems to have a fes1.fex in their images
<datagutt>
The Allwinner SDK has one, but it seems to freeze the device
<datagutt>
What i am trying to do, is flash a boot.img to a Remix Mini using FEL or FES
<datagutt>
I recall one or two people in here having a Remix device, while Pine is the main dev device for A64
<ssvb>
Remix Mini is using eMMC, so it is nowhere as complicated as NAND
<dave0x6d>
buZz: hah, I'm happy The Register retweeted me, at least this issue is getting some coverage now.
<ssvb>
datagutt: IIRC apritzel has done some experiments with reading the eMMC data from the FEL mode
<ssvb>
datagutt: what kind of image are you trying to flash to it?
<datagutt>
As far as i have read, he could successfully read data
<datagutt>
I am not even trying to flash a full image at this point, just an android kernel (boot.img) file
<dave0x6d>
jelle: it's amusing, I was trying to find a mainline kernel for my Orange Pi because I was worried that Xunlong's kernel would have security issues, and then I stumbled across that lovely backdoor.
<dave0x6d>
of course there's also tons of security issues due to it never being updated since early 2015.
<KotCzarny>
i think montjoie wrote mainline driver
<dave0x6d>
I hope the debug backdoor shames everyone into hurrying up with mainline support. :p
<KotCzarny>
unlikely
<dave0x6d>
there isn't much work left to do, is there...?
<KotCzarny>
see the mainlining page
<datagutt>
ssvb: Interesting. I guess i will wait for your implementation :)
tipo has joined #linux-sunxi
<dave0x6d>
I see that Hans de Goede has added USB support, and Chen-Yu Tsai has done networking.
<dave0x6d>
and Siarhei Siamashka has SMP.
<ssvb>
dave0x6d: not really, SMP is handled via PSCI now
<ssvb>
and PSCI is implemented as part of U-Boot
Guest_ has quit []
<dave0x6d>
ah
zuikis has quit [Remote host closed the connection]
<NiteHawk>
ssvb: that fel-sdboot and the required workaround seems a bit fragile to me. wouldn't we possibly be better off by building seperate bin files for older SoCs (with "high" BROM) and those variants where BROM starts at 0?
tsuggs has quit [Ping timeout: 265 seconds]
<ssvb>
NiteHawk: we still have exactly the same problem with multiple binaries, sometimes they do not work and need to be nudged a bit
<NiteHawk>
oh, even if they consist of nothing but the FEL jump?
<ssvb>
yes, if I rebuild the current fel-sdboot.sunxi file from git master using my GCC 4.7.4 croscompiler, then it does not boot on A10
<ssvb>
because it generates slightly different code and does not match the current binary in the bin directory
<NiteHawk>
i tried that with my gentoo-crossdev-gcc a while ago for A20, and the generated file was fine and worked. i should probably re-check that
<NiteHawk>
(i noted you changed some compilation flag in one of your patches to address this)
<ssvb>
btw, my first attempt which was reading the VER register and having a switch construct was working correctly on all my devices (which did not include a80)
<ssvb>
probably that's because it had a larger code in the beginning before trying to pass control to the FEL handler
<NiteHawk>
yeah, i wonder what's causing that behaviour - in theory checking the pc register should have been fine too
<ssvb>
yes, checking the pc register also works fine, unless we hit this strange bug
<NiteHawk>
addings nops to solve it smells a bit like it might be related to caches or jump prediction, imho
<ssvb>
yes
<ssvb>
I suspected that it has something to do with branch prediction and maybe passing control from 0x000000xy to 0xFFFF00xy
<ssvb>
when the lower part of the address matches
<ssvb>
and shifting the code a bit somehow resolves this
apritzel has joined #linux-sunxi
<apritzel>
datagutt: hey, you are playing around with the Remix Mini?
<apritzel>
I managed to boot ssvb's U-Boot on it using FEL and could access the eMMC
<apritzel>
as well as the SD card
<apritzel>
so I can copy stuff between the two
<apritzel>
didn't dare to write something to the eMMC yet, though
<apritzel>
I quickly tried to boot a (32-bit) kernel back then and it did start somehow, but then stopped
<apritzel>
but I didn't investigate (only 24 hours/day here, you know)