<maz>
wens: if that's called from assembly, you need to declare this as asmlinkage.
<maz>
also, touching LR and SP from C code is a big no-no.
reinforce has quit [Quit: Leaving.]
codekipper has quit [Ping timeout: 250 seconds]
<maz>
and doing a bx from C?
<wens>
maz: i should probably just leave psci_arch_init in assembly
<wens>
rewriting it in C is an ugly naked function
<maz>
wens: well, there is a number of things you can do in C, but you need to put the CPU in a state where it *can* execute normal C code. not hack with ASM directives inside a C function, because the compiler completely looses track of where things are.
<ssvb>
agraf: thanks for fixing this webserver
<wens>
asmlinkage doesn't seem to mean anything on arm
<agraf>
you're welcome :)
<maz>
wens: it did at some point.
<wens>
maz: yeah, but psci_arch_init's job is to put the CPU in a proper state (setting up the stack and stuff)
<wens>
so i guess i'll leave it in assembly
<maz>
wens: exactly.
pmattern has joined #linux-sunxi
<apritzel>
ssvb: btw: I managed to port your A64 SPL enablement on top of upstream U-Boot, so I can boot this via SPL
<apritzel>
ssvb: this is still 32-bit for the time being, but at least we can have the same code base for boot0 and SPL
reinforce has joined #linux-sunxi
<NiteHawk>
apritzel: Hi! Thanks for your feedback on "./sunxi-fel ver", could you give "./sunxi-fel -v sid" a try too?
al1o has joined #linux-sunxi
* apritzel
is looking for a free USB port ...
* NiteHawk
finds USB ports tend not to come for free :D
vickycq has quit [Ping timeout: 244 seconds]
<KotCzarny>
nitehawk, unless you are good at scavenging usb hubs
<apritzel>
NiteHawk: no idea if that makes sense, but it gives me:
<apritzel>
SID key (e-fuses) at 0x01C14200
<apritzel>
92c000ba 24104620 51900808 14160acb
vickycq has joined #linux-sunxi
* apritzel
is replugging the mouse :-D
<NiteHawk>
apritzel: thx! we'll have to cross-check that with other A64 users, but at least it doesn't crash the FEL, so the SID address seems to be okay
<hpeter>
after enable CONFIG_CONFIG_SUN8I_H3_EPHY, I can found my eth0
<hpeter>
but the right net orange led is disappear, it's seems no phy connection
<ssvb>
NiteHawk: oh, the SID value is space separated? hmm, I was almost sure that I have seen ':' as a delimiter in your old patch
<hpeter>
how should I do to help to debug?
<NiteHawk>
ssvb: if using a "a ? b : c" expression, maybe that misled you? been trying to mimic U-Boot's "md.l" output here...
<NiteHawk>
s/if/I'm/
<NiteHawk>
of course we're free to choose whatever output format we like
<ssvb>
NiteHawk: you are right :-) I was a little bit puzzled about where have I seen ':' before
<ssvb>
using '-' or ':' as separators between nibbles is better because the SID value looks like a single identifier then
<ssvb>
and is easier to handle in the FEL server code
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<NiteHawk>
ssvb: yes, this output might be mistaken for a list otherwise
avph has quit [Ping timeout: 260 seconds]
<NiteHawk>
ssvb: if we thing of grepping / partial string matches with a future "--sid <pattern>" option for device selection, would it make sense to do away with the spaces and have a single "word"? tends to make it less readable though
<NiteHawk>
*think
<ssvb>
the --sid option is imho also better without extra spaces
<ssvb>
partial string matches? how is it useful for SID?
avph has joined #linux-sunxi
<NiteHawk>
ssvb: dunno, might save you typing ;) just tossing around ideas here. you're right if you consider that "slightly dangerous" (read: error-prone)
tipo has quit [Quit: Leaving]
<montjoie>
hpeter: yes you need both EMAC and EPHY
<montjoie>
hpeter: could you paste your bootlog ?
al1o has joined #linux-sunxi
<NiteHawk>
ssvb: what would be your vote then? "1651664f-80485686-53504848-0702dde9", "1651664f:80485686:53504848:0702dde9" or "1651664f80485686535048480702dde9"
<hpeter>
montjoie: i need retry 14,5,35,14,37 times to wait reset complete
<montjoie>
strange
<prasannatsm>
git send-email to linux-sunxi@googlegroups.com does not show up in linux-sunxi page. I have tried twice in the past 4 days. Is it a known issue?
<NiteHawk>
prasannatsm: worksforme(TM)
afaerber has joined #linux-sunxi
<prasannatsm>
wondering how to send my patch
The_Loko has joined #linux-sunxi
<NiteHawk>
did you check with "git send-email --dry-run" that everything looks sane? has your (provider's) mail server replied with an "OK" message after sending?
<NiteHawk>
ssvb: know anything about the boot_head_sun3i.elf target in the sunxi-tools Makefile? the dependencies listed don't exist - i assume it's supposed to be treated the same as the sun4i and sun5i ones (only with a different MACHID)?
<prasannatsm>
yes it did. I have cc'ed myself and got the email myself.
<NiteHawk>
prasannatsm: iirc, you mentioned before that a (regular?) email from you didn't go through to the ML?
<prasannatsm>
I was asking about the patch email not a regular one.
<NiteHawk>
prasannatsm: i was thinking along the lines of: there might be a general filter / block preventing *any* of your messages?
afaerber has joined #linux-sunxi
<prasannatsm>
nope. I tried with the same patch twice.
<topi`>
hi. As far as I understood, all the BPi etc. boards use 3.3 volts on the GPIO lines. Then, if I bring in input which is between 0..12 V, how can I make sure the GPIO pins of A20 aren't being fried? Maybe some resistors?
<topi`>
if there is some kind of adapter block in Aliexpress, please let me know how it is called :)
<KotCzarny>
max232?
<topi`>
what about octocouplers? Should they work?
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Amit_T>
Is it right branch for pine64 FEL , origin/A64-support ?
<NiteHawk>
Amit_T: yes. it's currently not merged into master yet
<apritzel>
yesterday night I ported this over to upstream U-Boot, but haven't pushed the patches yet
<Amit_T>
apritzel: Ok Thanks, I would start looking into it.
pitelpan has joined #linux-sunxi
al1o has joined #linux-sunxi
<apritzel>
Amit_T: roughly you would do: checkout ssvb's branch, make pine64_plus_defconfig && make (with a 32-bit ARM cross-compiler), sunxi-fel uboot u-boot-sunxi-with-spl.bin
<apritzel>
I will document this in more detail later
<Amit_T>
ok I need to checkout wip-a64-experimental branch, right ?
<NiteHawk>
the branch name is "20160126-wip-a64-experimental"
<tkaiser>
TheLinuxBug: Longsleep said he provides a new kernel over the weekend so remember to run the update scripts to benefit from latest fixes
leio has joined #linux-sunxi
<tkaiser>
longsleep: Are you around?
merbanan has quit [Ping timeout: 252 seconds]
<apritzel>
tkaiser: smells like Brückentag ;-)
<tkaiser>
apritzel: Longsleep 'promised' to drive into office today to test 4K displays ;)
<apritzel>
tkaiser: so maybe he's got a sunburn from the awesome picture quality ;-)
<tkaiser>
apritzel: Yeah, or already on his way back to beergarden where the real development happens. BTW: Just remembered my first time travelling to spain and experiencing an 'Acueducto'. Two BrŸckentage in one week and no one went to work.
stasiic has joined #linux-sunxi
<ssvb>
NiteHawk: I don't know anything about boot_head_sun3i.elf, git blame would probably point to somebody who knows more
<ssvb>
apritzel: I just moved back to Pine64 from Orange Pi PC after cleaning up the code a bit and the SPI boot worked
<NiteHawk>
ssvb: yeah, i've checked that - and it looks like that rule was b0rken right from hno's inital commit - so i've simply adjusted it to the sun4i and sun5i templates
<apritzel>
ssvb: thanks!
benjamin_ has joined #linux-sunxi
<stasiic>
hello! I have a Denver Tac android table, which I believe uses Allwinner A10, and I want to be able to tinker with it. Is this the right place for getting help and exchanging ideas? :)
IgorPec has quit [Ping timeout: 265 seconds]
stasiic has quit [Quit: leaving]
stasiic has joined #linux-sunxi
reev has quit [Ping timeout: 265 seconds]
<stasiic>
woops... accidentally dropped out for a second :(
premoboss has quit [Quit: Sto andando via]
nove has joined #linux-sunxi
<ssvb>
apritzel: not sure what exactly fixed it, I initially suspected that the internal clock speed of the SPI hardware block may be somehow responsible, but now trying to set high divisors does not really break it
<NiteHawk>
ssvb: that SPI emulator of yours seems pretty neat :D
<ssvb>
apritzel: so it was a cargo cult / snake oil all along, and in the SPI slave mode the SPI is clocked by the other end
benjamin_ has quit [Ping timeout: 246 seconds]
<ssvb>
apritzel: must have been some other bug in the code, or maybe a problem with jumper wires connection
<ssvb>
maybe we can add a simple SPI driver to the sunxi-fel tool, I'll try to hack something like this :-)
benjamin_ has joined #linux-sunxi
<ssvb>
as a bonus, it is also possible to connect the reset pin and control it too
diego_r has quit [Client Quit]
diego_r has joined #linux-sunxi
benjamin_ has quit [Ping timeout: 244 seconds]
<apritzel>
ssvb: does U-Boot support (sunxi) SPI flash?
<ssvb>
apritzel: not yet, but this should be relatively simple to implement
* apritzel
wonders if we could put at least the EFI variables and/or the U-Boot environment on this
<apritzel>
as the boot priority spoils this have-firmware-on-SPI-flash dream :-(
<apritzel>
we could only put some check-for-SPI-flash code into the SD-card SPL
<ssvb>
still we can just use GPT partitioned SD cards without any bootloader on them and have such SD cards recognized by the firmware
<NiteHawk>
shouldn't it be possible to work around the SDcard priority by simply having no valid boot0 boot signature (at 8k)?
<ssvb>
NiteHawk: exactly
<ssvb>
apritzel: there is no security in such setup, because any bad guy can create a bootable SD card with GNU/Linux or Allwinner's Android and easily take over the hardware
p1u3sch1 has quit [Ping timeout: 252 seconds]
<apritzel>
security? dev boards? Allwinner? -ENOPARSE ;-)
<apritzel>
security in the sense of preventing someone from booting their own stuff on a dev-board style device is frankly my least concern
<ssvb>
from this point of view, the current boot priority is just fine
oliv3r has joined #linux-sunxi
p1u3sch1 has joined #linux-sunxi
<apritzel>
I was thinking about using the SPI flash as some kind of "on-board" BIOS thing, which at least brings up the board to some usable state
<apritzel>
can the boot priority be influenced by pins? So other _board vendors_ could fix this?
<ssvb>
some other Allwinner SoCs had extra pins to control boot priority, but A64 is not one of them
FlorianH has quit [Ping timeout: 250 seconds]
<apritzel>
too bad
<ssvb>
the firmware in the SPI flash can boot any kind of "industry standards" compliant system that you want from the SD card, as long as it is not a legacy-bootable SD card with the SPL/boot0 at 8K
<apritzel>
that sounds reasonable
<apritzel>
after all it's still a dev board style device
<ssvb>
and a bootable SD card with the SPL/boot0 at 8K can be used for unbricking the device
<agraf>
so what does the separate spi buy you then?
<agraf>
you can use a generic image, yes
<agraf>
but as a user, what's the benefit? :)
<agraf>
or is this about automated testing?
<apritzel>
to have a board agnostic image?
<ssvb>
agraf: well, aren't you now questioning the whole purpose of the EFI? ;-)
<apritzel>
and not requiring the firmware to be on the only reasonable mass storage device
<agraf>
we can't demand users to buy a spi flash expansion card ;)
<agraf>
so if a distro wants to have users, they need to provide a specialized image either way
<agraf>
at which point the separate spi flash doesn't really buy you too much anymore, since you don't reduce the amount of work for people - there will still be specialized images
<ssvb>
or the users can just buy a new revision of the dev board with SPI flash already included
<agraf>
oh, sure, that case works great
<agraf>
so if the pine65 has a 4MB SPI flash, we're all set
<agraf>
or 2MB
<agraf>
or whatever, doesn't have to be big
<apritzel>
I guess 4Mbit would suffice
<agraf>
then we could even make it SBBR compliant I guess
<apritzel>
who sets up the kickstarter for this? ;-)
<agraf>
but for the pine64, there's no big incentive to use a separate spi flash for booting :)
<apritzel>
Olimex, are you listening?
<apritzel>
agraf: but it's just cool
<agraf>
oh, of course
<agraf>
ssvb: so how fast can you drive the spi slave emulation?
<agraf>
ssvb: one project on my big pile of todos is an mmc emulation layer
<agraf>
ssvb: to fully model an SD card in software
<agraf>
ssvb: for automated testing of SD images for various boards
<ssvb>
agraf: it's not a real emulation, I'm just constructing the output based on the expected input but not handling real requests
<agraf>
ssvb: so far I was thinking bbb and PRUs, but if the native spi slave hardware is fast enough to get me reasonable bandwidth, i guess single spi is good enough for now
<ssvb>
and can detect unexpected input and complain after the fact
<agraf>
ssvb: sure, but that's a software problem ;)
<agraf>
ssvb: but how fast is the interconnect between the cpu and your spi controller? can that handle 50mbit/s?
<agraf>
or was it 25?
<agraf>
i think it's only 50Mhz
<ssvb>
GPIO bit-banging can only handle a couple of MHz at most
<agraf>
also for this I'd need a multi-core system, to have one dedicated core for the SD emulation
<ssvb>
and for SPI flash emulation we are receiving the read command and the address, and then need to adjust the output very fast
<agraf>
for SPI flash, yes, for SD emulation not IIRC
<agraf>
you can always return "sorry, I'm busy"
<agraf>
so you need to reply fast, but you don't need the data fast
<ssvb>
the lowest 8-bit part of the address can be assumed to be always 0 in the SPI Flash emulation implementation and ignored, this gives us 1 byte gap
vagrantc has joined #linux-sunxi
premoboss has joined #linux-sunxi
<ssvb>
but this gap is still insufficient, the TX buffer still underflows and we fail to do proper communication in time
<apritzel>
agraf: btw: I was wondering if we could use the OpenRISC as some kind of PRU for the Pine64
<agraf>
apritzel: well the really cool part about the PRU is that it only needs 1 clock cycle for GPIO access
<agraf>
apritzel: I don't think the OpenRISC can get anywhere near that?
<ssvb>
the "READ DATA BYTES at HIGHER SPEED" command has 1 byte padding before reading the response, and this is a bit easier to emulate
<apritzel>
agraf: not sure about the access latency, but at least it's a separate entity which could run a real RTOS
<ssvb>
agraf: we can surely try to measure the GPIO speed on OpenRISC
<agraf>
apritzel: you could easily cut off one of the arm cores for that too if you wanted
<apritzel>
agraf: but people paid for four of them
<agraf>
apritzel: yeah, and they need 1 ;)
tomboy65 has joined #linux-sunxi
<agraf>
apritzel: just get jailhouse working on the pine64 and you have your average realtime workloads covered
<agraf>
ssvb: would be great if you could :)
* apritzel
turns around to Jean-Philippe ;-)
<apritzel>
agraf: do you know about the state of AArch64 support in Jailhouse?
<agraf>
apritzel: I know that huawei was working on it
<agraf>
apritzel: the biggest problem with the a64 is the lack of an iommu
<agraf>
apritzel: or at least i haven't seen any :)
tomboy64 has quit [Ping timeout: 244 seconds]
<agraf>
apritzel: so you don't get full isolation
<agraf>
either way, bbl
<apritzel>
just asked JPB: it's looking good, Huawei is on the right track, so aarch64 support should be merged sooner or later
<apritzel>
I wonder if someone is making a _real_ case for the Pine64: with a reset and power button, RTC battery holder, power LED, wireless antenna and SPI flash
* vagrantc
apparently made the mistake of ordering pine64 with cases
p1u3sch1 has quit [Ping timeout: 260 seconds]
<apritzel>
vagrantc: in terms of: delivery is delayed?
<vagrantc>
apritzel: i *think* so ... though it's honestly hard to know for sure
* vagrantc
hasn't really been able to parse some of these emails about delays
p1u3sch1 has joined #linux-sunxi
hrw has quit [Read error: Connection reset by peer]
hrw has joined #linux-sunxi
<vagrantc>
oh nice, pine64 in mainline u-boot.
zuikis has joined #linux-sunxi
jernej has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 276 seconds]
p1u3sch1 has joined #linux-sunxi
jelle has quit [Ping timeout: 264 seconds]
LostSoul has quit [Ping timeout: 250 seconds]
LostSoul has joined #linux-sunxi
apritzel1 has quit [Ping timeout: 244 seconds]
Amit_t_ has joined #linux-sunxi
staplr has quit [Remote host closed the connection]
diego_r has quit [Quit: Konversation terminated!]
staplr has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
premoboss has quit [Quit: Sto andando via]
<longsleep>
tkaiser: any particular reason why mikhail stopped at 3.10.75?
<longsleep>
tkaiser: did he got stuck or felt that .75 is fresh enough?
avph has joined #linux-sunxi
fl_0 has quit [Ping timeout: 250 seconds]
<longsleep>
tkaiser: i can also remove the custom name from the repository if people do not like it - i just added it there so i do not forget it when building :)
fl_0 has joined #linux-sunxi
IgorPec has joined #linux-sunxi
caog has quit [Ping timeout: 246 seconds]
pmattern has quit [Quit: Genug für heute.]
robogoat has quit [Ping timeout: 252 seconds]
apritzel has quit [Ping timeout: 244 seconds]
Amit_t_ has quit [Quit: Page closed]
azend|vps has joined #linux-sunxi
Netlynx has joined #linux-sunxi
dlan has quit [Ping timeout: 276 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
matthias_bgg has quit [Ping timeout: 260 seconds]
<lennyraposo>
hey longsleep
<longsleep>
si si
<lennyraposo>
I remember
<lennyraposo>
why debian didn't get fbturbo
<lennyraposo>
one dependency that needs upgrading
<lennyraposo>
libvdpau is less than 1.1
<lennyraposo>
;)
vagrantc has quit [Quit: leaving]
<lennyraposo>
but the image will be released with all the trimmings this time around
<lennyraposo>
not fbturbo
<lennyraposo>
but vdpau
afaerber has quit [Quit: Ex-Chat]
robogoat has joined #linux-sunxi
al1o has joined #linux-sunxi
massi_ has quit [Quit: Leaving]
ricardocrudo has quit [Remote host closed the connection]
kelvan has quit [Remote host closed the connection]
azend|vps has quit [Remote host closed the connection]