<apritzel>
this is a firmware only image with 64-bit upstream U-Boot and heavily fixed ARM Trusted Firmware, using boot0 but no scp/arisc code
ganbold has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 276 seconds]
cnxsoft has joined #linux-sunxi
<lennyraposo>
I do I do
<lennyraposo>
will check it out aprtizel
<wens>
what board samples from xunlong were we talking about?
wens has quit [Quit: leaving]
wens has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 276 seconds]
p1u3sch1_ has joined #linux-sunxi
robogoat has quit [Quit: leaving]
robogoat has joined #linux-sunxi
reev has joined #linux-sunxi
<lennyraposo>
adding your latest releases longsleep my downloads page mate ;)
<lennyraposo>
to my*
arossdotme has quit [Ping timeout: 240 seconds]
arossdotme has joined #linux-sunxi
mossroy has joined #linux-sunxi
jernej has quit [Ping timeout: 240 seconds]
jernej has joined #linux-sunxi
IgorPec has joined #linux-sunxi
jernej has quit [Read error: Connection reset by peer]
jernej has joined #linux-sunxi
<lennyraposo>
long night eh longsleep
<lennyraposo>
or bright and early depending on your time zone
IgorPec has quit [Ping timeout: 244 seconds]
jernej has quit [Ping timeout: 260 seconds]
lemonzest has joined #linux-sunxi
wens has quit [Ping timeout: 246 seconds]
wens has joined #linux-sunxi
brainwagon has quit [Ping timeout: 276 seconds]
pietrushnic has quit [Ping timeout: 252 seconds]
pietrushnic has joined #linux-sunxi
apritzel has joined #linux-sunxi
reev has quit [Ping timeout: 244 seconds]
reev has joined #linux-sunxi
reev has quit [Max SendQ exceeded]
reev has joined #linux-sunxi
<KotCzarny>
wens: probably orange pi plus 2e
apritzel has quit [Ping timeout: 244 seconds]
IgorPec has joined #linux-sunxi
massi_ has joined #linux-sunxi
reinforce has joined #linux-sunxi
<rellla>
wow. answering to a 3,5 year old mail is very impressive :)
<wens>
google groups does let you reply to threads directly :p
<rellla>
wens: i know. i was just i the "oh-no-not-another-cedarx-dealer-again"-mood :p
<wens>
:p
premoboss has joined #linux-sunxi
ganbold has quit [Quit: This computer has gone to sleep]
reinforce has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
User_1000 has joined #linux-sunxi
Worf has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
matthias_bgg has quit [Remote host closed the connection]
matthias_bgg has joined #linux-sunxi
<wens>
mripard: any chance getting an ack from stephon and including all the remaining drm patches for next?
<wens>
be a shame not to get it in
reinforce has joined #linux-sunxi
premoboss has quit [Quit: Sto andando via]
fl_0 has quit [Quit: STRG + Q]
fl_0 has joined #linux-sunxi
sunxi_fan has joined #linux-sunxi
p1u3sch1_ has quit [Ping timeout: 240 seconds]
p1u3sch1 has joined #linux-sunxi
abruanes- is now known as abruanese
caog has joined #linux-sunxi
Dev184 has quit [Quit: Page closed]
hrw has joined #linux-sunxi
<hrw>
hi
<hrw>
apritzel: thanks for pine64 work
<apritzel>
oh, an user ;-)
<KotCzarny>
:>
<hrw>
apritzel: trying to get fedora/rawhide running
<hrw>
sunxi-mmc 1c0f000.mmc: no support for card's volts
<hrw>
ops, wrong window
<apritzel>
hrw: which kernel?
<hrw>
apritzel: 4.6-rc6
<apritzel>
do you have my patches on top?
<hrw>
apritzel: mainline tree, have to check which patches fedora adds
<apritzel>
Fedora tree should be fine - unless Hans sneaked in something ;-)
<apritzel>
but still you need some patches from my github tree
<hrw>
apritzel: there are some of them. will have to check are they latest
Worf has quit [Quit: Konversation terminated!]
<apritzel>
hrw: you need at least: "clk: sunxi: add generic multi-parent bus clock gates driver" and "clk: sunxi: Let divs clocks read the base factor clock name from devi…"
<hrw>
ok
<apritzel>
also probably "arm64: sunxi: Kconfig: add essential pinctrl driver" if you want to use defconfig
<hrw>
apritzel: from your a64-wip tree?
<apritzel>
yes
<hrw>
ok
<apritzel>
then take the .dtbs from my new image
<apritzel>
and tell me whether this works ;-)
<hrw>
ok
<apritzel>
I tested it with the top commit of a64-wip and "make defconfig", just copy the resulting "Image" to the FAT partition and it should boot
<apritzel>
then you can add a Fedora rootfs to partition 5 (/dev/mmcblk0p5 on the Pine, /dev/sdx5 on an USB card reader)
<apritzel>
also this U-Boot can boot EFI kernels, though I haven't tested this
<hrw>
apritzel: I have fedora u-boot, fedora rootfs etc
<apritzel>
Please don't use Fedora U-Boot, I guess this doesn't work
<hrw>
it boots fine
<apritzel>
you can't boot it easily anyway on the Pine64
<apritzel>
how do you boot it
<apritzel>
?
<apritzel>
FEL?
<hrw>
it blobbed with atf and smc like you described then it boots
<apritzel>
I have a much better tool now, which allows to move ATF into SRAM and avoid glueing U-Boot to ATF
<hrw>
apritzel: I am all ears ;D
<apritzel>
It's finished, but it looks pretty horrible, so I need to clean it up a bit
<apritzel>
later tonight
<hrw>
ok
<apritzel>
check this IRC log for the command line I posted tonight ;-)
<hrw>
sure
p1u3sch1 has joined #linux-sunxi
<hrw>
apritzel: if you can mention me then it will be even easier d:
<apritzel>
I will post something once I release the tool
<hrw>
cool
<apritzel>
afk
<NiteHawk>
apritzel: is something like "sunxi-fel spl uboot0.bin" already known to work on the A64 (with ssvb's wip patches)?
<NiteHawk>
(i.e. can you FEL-boot Allwinners boot0?)
fdcx has quit [Read error: Connection reset by peer]
fdcx has joined #linux-sunxi
pietrushnic is now known as pietrushnic`away
pietrushnic`away is now known as pietrushnic
pietrushnic is now known as pietrushnic`away
pietrushnic`away has quit [Quit: Coyote finally caught me]
pietrushnic`away has joined #linux-sunxi
pietrushnic`away is now known as pietrushnic
pietrushnic is now known as pietrushnic`away
pietrushnic`away has quit [Client Quit]
pietrushnic`away has joined #linux-sunxi
<apritzel>
NiteHawk: yes, I use that all of the time
<apritzel>
NiteHawk: I managed to load ssvb's U-Boot (with libdram), ATF (so we have SMP), kernel and initrd over it
<NiteHawk>
good to know. given that folks seems to be happily FEL-ing A64 all the time, i guess it's about time we move forward with "official" support in sunxi-tools :D
<apritzel>
yes, I was asking ssvb already for that
pietrushnic`away is now known as pietrushnic
pietrushnic is now known as pietrushnic`away
<apritzel>
I need to find a nice way to use upstream U-Boot for FEL, at best the 64-bit version
pietrushnic`away has quit [Quit: Coyote finally caught me]
pietrushnic`away has joined #linux-sunxi
pietrushnic`away has quit [Client Quit]
<NiteHawk>
i think ssvb wanted to sort out that SRAM issue / inconsistency before updating his branch, but my impression is that it doesn't interfere with the SPL support (using a different memory region)
<apritzel>
NiteHawk: yes, I rebase myself regularly
pietrushnic`away has joined #linux-sunxi
pietrushnic`away has quit [Client Quit]
pietrushnic`away has joined #linux-sunxi
pietrushnic`away has quit [Client Quit]
pietrushnic`away has joined #linux-sunxi
pietrushnic`away is now known as pietrushnic
pietrushnic is now known as pietrushnic`away
pietrushnic`away is now known as pietrushnic
ganbold has joined #linux-sunxi
pietrushnic is now known as pietrushnic`away
pietrushnic`away has quit [Quit: Coyote finally caught me]
pietrushnic`away has joined #linux-sunxi
IgorPec has quit [Ping timeout: 250 seconds]
sirblackheart has joined #linux-sunxi
pietrushnic`away has quit [Quit: Coyote finally caught me]
pietrushnic`away has joined #linux-sunxi
pietrushnic`away is now known as pietrushnic
pietrushnic is now known as pietrushnic`away
akaWolf has quit [Ping timeout: 260 seconds]
pietrushnic`away has quit [Quit: Coyote finally caught me]
pietrushnic`away has joined #linux-sunxi
pietrushnic`away is now known as pietrushnic
sirblackheart has quit [Quit: sirblackheart]
pietrushnic is now known as pietrushnic`away
pietrushnic`away has quit [Client Quit]
<oliv3r>
wens: ok i've added the pwr-seq too and don't seem to cause any problems, so I guess it works :p http://sprunge.us/EJSB what do you think of this? then i'll send a v3 with that as a seperate patch added
reev has quit [Ping timeout: 240 seconds]
<wens>
oliv3r: looks ok
<wens>
you should just squash it in though
<wens>
btw, when you tried 8-bit, did you also patch the pinctrl driver and pinmux node?
<oliv3r>
wens: here's my patch for 8 bit more; you can double check it
hrw has quit [Read error: Connection reset by peer]
premoboss has joined #linux-sunxi
pietrushnic`away has joined #linux-sunxi
pietrushnic`away is now known as pietrushnic
hrw has joined #linux-sunxi
<wens>
that looks right
<wens>
sad, a20 really doesn't support it
<wens>
well, at least with 4 bit ddr you can get up to around 50 MB/s throughput
<oliv3r>
did you finish your ddr work?
<oliv3r>
wens: i didn't add the ddr stuff in the dts, only the 'standard' stuff
<oliv3r>
and allready get quite nice performance
<oliv3r>
and do you need 1.8v with ddr?
afaerber has quit [Quit: Ex-Chat]
<wens>
oliv3r: ddr support is in v4.6-rc1
<wens>
though there were no a10/a20 boards with emmc
<wens>
so i couldn't test
<wens>
if you run the latest -next you should be able to see it
<wens>
you might also need to increase the drive strength for mmc2_pins
<apritzel>
NiteHawk, ssvb: would a tool to assemble boot0-accepted firmware blobs be a fit for sunxi-tools?
ricardocrudo has quit [Read error: Connection reset by peer]
<NiteHawk>
apritzel: it's a patchwork / collection of quite heterogenous stuff anyways - so i'm inclined to say: yes :) the problem lies somewhere else: we probably don't want to "support" proprietary blobs...
<NiteHawk>
the problem that currently there is no alternative might not justify / be a sufficient excuse for including tools like that?
<apritzel>
NiteHawk: yeah, I agree, hopefully it's a temporary kludge only anyway
<ssvb>
apritzel: I think that we can definitely consider anything that is useful, but having a descriptive readme is necessary
<apritzel>
I can just put it in my pine64 github repo, so people can pick it from there
afaerber has joined #linux-sunxi
<apritzel>
ssvb: yes, I will write some documentation tonight
<ssvb>
right now there are some poorly documented utilities included in sunxi-tools, I even don't know what they do :)
<NiteHawk>
nor do i :D
tipo has joined #linux-sunxi
<apritzel>
I can send it as a RFC patch against sunxi-tools to the linux-sunxi ML, then we can have the discussion there
akaWolf has joined #linux-sunxi
afaerber has quit [Ping timeout: 250 seconds]
afaerber has joined #linux-sunxi
<willmore>
"hopefully it's a temporary kludge" famous last words.
<hrw>
;DD
<NiteHawk>
X)
<apritzel>
willmore: well, I wanted to have something working for the moment, I guess since AW is not really moving on the boot0 front, we are going the reverse engineering way to get the DRAM initialization
<willmore>
apritzel, that's the impression I have received by reading the conversations here.
<apritzel>
but from a kernel development perspective this doesn't really matter (whether we boot with boot0 or a proper U-Boot SPL)
<willmore>
understood
<apritzel>
and frankly I don't have too strong opinions about binary blobs if they don't stay resident or get in the way
<apritzel>
that's the reality on 99.9% of PCs these days anyway - and there the blobs _do_ get in the way sometimes
<willmore>
My only concern with tools that manipulate strange stuff as a temporary measure is that nothing ever ends up being temporary. 8 years from now, someone will be here complaining that the tool won't build under GCC 9.2 and demanding that someone fix it. :)
<willmore>
Yeah, half of the reason to switch from BIOS to UEFI was so that they could have more space to include the blobs. Ever looked through a PC UEFI? Both Intel and AMD have tons of 'just use this, trust us' bits.
<oliv3r>
wens: okay, increase the str pins to how much in the a20-dtsi? and i'm on 4.6-rc4 i think
<oliv3r>
wens: so i can test it, if you tell me what i need to add :)
<oliv3r>
wens: default pin str is at 30mA, you don't think that'll be enough?
<ssvb>
apritzel: even when we get everything sorted out for A64, there will be probably new SoCs from Allwinner with new boot0 blobs
<wens>
you can try, and it might be enough
<wens>
i set them to 40mA to be safe
<ssvb>
apritzel: and everything will repeat again, so having some tools to deal with this junk is still likely useful in the long run
* apritzel
is looking forward to new AW SoCs with new hac^Wfeatures
<oliv3r>
wens: well then we'd want to set them to 40 by default in the dtsi no?
<tipo>
can a orange pi pc running armbian provide enough power for a 2.5" 7200rpm hard drive?
cnxsoft has quit [Quit: cnxsoft]
ricardocrudo has joined #linux-sunxi
<buZz>
tipo: OS doesnt determine amperage supplied on 5V
<tipo>
yeah i know i just mentioned it because i'm stoned
<wens>
oliv3r: mine failed directly at 30
<wens>
oliv3r: yours may vary :)
<ssvb>
apritzel: regarding the blobs being OK, would you really want to use the ATF from Allwinner with all its gotchas if it was available only as a binary blob?
<ssvb>
apritzel: the DRAM init code from Allwinner is also usually full of crazy shit
JohnDoe_71Rus has joined #linux-sunxi
<apritzel>
ssvb: ATF from Allwinner: no (as it stays resident)
<apritzel>
but if there is run-once DRAM init code, I don't care so much
<ssvb>
even if this causes reliability problems?
<apritzel>
that's another issue, I'd say
<apritzel>
then Allwinner would need to fix it anyway, right?
<ssvb>
btw, we haven't really stress tested the DRAM reliability in A64 yet
<ssvb>
I wouldn't count on Allwinner fixing anything
<TheLinuxBug>
hehehe in Allwinners eyes we are just lucky 'THEY LET US' have these chips and what we have... like they would care enough to actually do work on things, lol :Z
<ssvb>
apritzel: there are also blobs from the other SoC vendors, which stay resident in RAM
<TheLinuxBug>
I mean it would be awesome if Allwinner cared and would actually open source drivers like they said they would :Z
* TheLinuxBug
dreams
<ssvb>
apritzel: at least that's the case with my Exynos 4412 based ODROID-X board
<apritzel>
ssvb: I don't argue that having DRAM initialization as OpenSource is the much better way and that boot0 is probably some nasty piece of code
<apritzel>
but at the moment it just works for me (TM)
<apritzel>
and frankly we have other issue to fight as well
<apritzel>
*issues* even ;-)
<ssvb>
yeah, toy-grade quality FTW :-)
<apritzel>
ssvb: sure, I wouldn't put it in anything where my life depends on ;-)
<oliv3r>
wens: so where is the sensible place to set the str, if yours is failing allready, it might be that some mmc cards might actually also be at their limit with 30mA? so it's not all weird to set it to 40mA by default
<oliv3r>
wens: i don't understand 8826532c76da7 your commit message states that it enables HS-DDR, but i don't see this reflected in the dts change in that commit? So nothing is needed for HS-DDR mode in terms of the dts?
nove has joined #linux-sunxi
<oliv3r>
wens: or is it automatically enabled if vqmmc is defined?
premoboss has quit [Quit: Sto andando via]
<wens>
oliv3r: it's only driver related changes
<wens>
it will be enabled even if vqmmc isn't defined (which just falls back to 3.3v only signaling)
<oliv3r>
ah ok, so i don't have to do anything to see if it works :)
<oliv3r>
wens: mmc1: new DDR MMC card at address 0001 so that's all i need? :)
<ssvb>
apritzel: It would be great if the ATF could stay away from SRAM A2 in the final form :-) Otherwise we are making it really difficult to use arisc
<apritzel>
ssvb: I ran the ATF from various locations by just changing one define in the source
<apritzel>
so that's a no-brainer
<apritzel>
I could even imagine to make it position independent
<apritzel>
so once we have a boot0 replacement and a proper loader, we can put it somewhere else
<apritzel>
for instance even in SRAM A1
<ssvb>
ok
<apritzel>
afk
lemonzest has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
<montjoie>
ssvb: for FEL issue yesterday, it seems to be ENEEDMOREPOWER
massi_ has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
ricardocrudo has quit [Ping timeout: 250 seconds]
IgorPec has quit [Ping timeout: 252 seconds]
reinforce has joined #linux-sunxi
dlan has quit [Ping timeout: 246 seconds]
dlan has joined #linux-sunxi
susan33 has joined #linux-sunxi
jernej has quit [Ping timeout: 276 seconds]
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
interrobangd has joined #linux-sunxi
jernej has joined #linux-sunxi
Andy-D_ has quit [Ping timeout: 252 seconds]
staplr has joined #linux-sunxi
gzamboni has quit [Ping timeout: 276 seconds]
lemonzest has quit [Ping timeout: 276 seconds]
avph has quit [Ping timeout: 260 seconds]
Netlynx has quit [Quit: Leaving]
iamfrankenstein has joined #linux-sunxi
<oliv3r>
mripard: should be the 'regular' lime2 compatible in the compatible as well? or is this enough. compatible = "olimex,a20-olinuxino-lime2-emmc", "allwinner,sun7i-a20";
avph has joined #linux-sunxi
apritzel has joined #linux-sunxi
gzamboni has joined #linux-sunxi
Andy-D_ has joined #linux-sunxi
jstein has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
<hrw>
apritzel: can you provide atf as separate file? would like to check with fedora u-boot as well as yours
zuikis has left #linux-sunxi [#linux-sunxi]
susan33 has left #linux-sunxi ["Quitte"]
gzamboni has quit [Ping timeout: 260 seconds]
gzamboni has joined #linux-sunxi
mossroy has quit [Quit: Quitte]
jernej has quit [Ping timeout: 265 seconds]
<lennyraposo>
funny tkaiser
reinforce has quit [Remote host closed the connection]
<apritzel>
hrw: (if you read this:) the ATF version in there is tailored to be loaded in SRAM, so it will not work easily with agraf's script and Fedora U-Boot
<apritzel>
hrw: but I will push the required patches and my script later
pmattern has joined #linux-sunxi
ganbold has quit [Ping timeout: 252 seconds]
reinforce has joined #linux-sunxi
nove has quit [Quit: nove]
apritzel1 has joined #linux-sunxi
Nyuutwo has quit [Ping timeout: 240 seconds]
Nyuutwo has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
matthias_bgg has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
afaerber has quit [Quit: Ex-Chat]
Dev_184 has joined #linux-sunxi
<Dev_184>
hello, quick question does anybody know why CONFIG_WIRELESS_EXT is missing from sunxi-next ? I can't compile the rtl8723bs driver
Andy-D_ has quit [Ping timeout: 265 seconds]
Andy-D_ has joined #linux-sunxi
ganbold has joined #linux-sunxi
keesj_ has quit [Ping timeout: 260 seconds]
Tusker has joined #linux-sunxi
<Tusker>
Hey guys, I am trying to build a jessie image for the BPi M3 (A83T), and the instructions on http://linux-sunxi.org/Mainline_Debian_HowTo say to use flash-kernel to build the boot.src. The trouble is that the flash-kernel is jessie doesn't have the DTB files for the BPi M3. I have the built u-boot.dtb.bin and u-boot.dtb.img, but the filenames don't seem to gel, so I'm not sure how to patch the flash-kernel installation. Could someone point me in t
<Dev_184>
mkimage -C none -A arm -T script -d boot.cmd boot.scr
<Dev_184>
to generate the scr from cmd
<Tusker>
OK, so don't use flash-kernel at all then ?
<Dev_184>
not sure what it does... the sunxi way to generate the scr is ^^^
pmattern has quit [Quit: Genug für heute.]
<Tusker>
OK, strange that the sunxi wiki says differently :P
<Dev_184>
yeah...
<Dev_184>
I had to search a bit till I got it right
<Dev_184>
regardign the dtb files you can find them in the arch/arm/boot/dts folder
<Dev_184>
you need to compile dtbs
<Tusker>
OK, the Makefile from u-boot will do that ?
<Dev_184>
no, the dtbs are in the kernel
<Tusker>
OK, so I have u-boot and the kernel compiled, and the jessie chroot built and ready... there seems to be dts files in uboot, and a u-boot-dtb.img generated by make