Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
<sdwrage> is there a link to one?
<sdwrage> also how do I load it onto the sd card from OS X?
<sdwrage> using diskutil?
<sdwrage> apritzel,
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #linux-sunxi
<sdwrage> will pifiller work?
<apritzel> don't know about appleish dd tools
<sdwrage> is this an OS or just tools to get an OS onto the sd card?
<sdwrage> I used piffled to install Lubuntu onto the sd card but the light is staying a steady red on the power
<sdwrage> pifiller*
<apritzel> it seems that pifiller is for the Raspberry Pi only
<apritzel> at the moment you have to write an image to the SD card
<apritzel> also I am not aware of any Linux installers ready for the Pine64 at the moment
<apritzel> sdwrage: either check out the images under the link above or pick something from the official Pine64 wiki page: http://wiki.pine64.org/index.php/Pine_A64_Software_Release
<sdwrage> Thanks :)
<apritzel> sdwrage: please note that the OS situation is far from ideal at this point and you can't expect the level of Linux support you would see on a PC or the Raspberry Pi
<sdwrage> apritzel, oh I totally understand
<sdwrage> I just want to try and get something to work
<sdwrage> and hope for a gui to work right now
kaspter has joined #linux-sunxi
<apritzel> hope dies last ;-)
kaspter1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 276 seconds]
TheSeven has quit [Ping timeout: 276 seconds]
TheSeven has joined #linux-sunxi
Tusker has joined #linux-sunxi
<Tusker> heya guys, I have the A83T on the BPi M3, and based on http://linux-sunxi.org/Linux_mainlining_effort, it looks like the A83T has been merged into 4.6. Does that mean that it is expected to boot ?
apritzel has quit [Ping timeout: 244 seconds]
kaspter1 has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
FlorianH has quit [Read error: Connection reset by peer]
sdwrage has quit [Quit: Leaving]
tsuggs has joined #linux-sunxi
ninolein has quit [Ping timeout: 276 seconds]
<wens> Tusker: expected to boot and nothing more :)
<Tusker> wens: OK :) what is missing to have init starting ?
<Tusker> i've got a copy of the uboot and linux from git, which includes your USB changes
ninolein has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
<wens> then it should boot?
<wens> remember to set a console
<Tusker> OK, I will experiment with the code Vishnu and yourself. Do you have a list of things that you are working on, and/or need some help ?
<wens> usb is done for the most part
<Tusker> OK, but for a fully working system, there is probably more work to be done? Is there a list that Vishnu maintains ?
<wens> don't think so
<wens> emac is being worked on
<wens> then comes pmic
<Tusker> OK, I suppose I will find out the status once I try and get some initrd happening
<Tusker> does uboot work OK so far ?
<wens> it does
<wens> what features are you looking for?
<Tusker> well, I'm just trying to get a vanilla server install happening of jessie
<wens> that should work
<Tusker> want to start with a clean slate, and will be doing some GPIO and USB programming of TI chips
<wens> though i use debootstrap instead of the installer
<Tusker> do you have any build scripts that you use including ARCH targets ?
<wens> it's all manual
<Tusker> do you have a bash history that I could create a script ? :)
<wens> probably not
<Tusker> OK, I'll work on it then, see if I can script something to build a jessie image using the git versions of linux and uboot
<wens> fyi sunxi_defconfig isn't useful when it comes to usb peripherals
<Tusker> do you have a defconfig that you use ?
<wens> i have a config that enables a bunch of stuff i use, yeah
<Tusker> do you mind sharing as a starting point?
<Tusker> (sorry if it is asking too much, just don't want to replicate work that has already been done/completed)
a|3x has quit [Ping timeout: 244 seconds]
<Tusker> also, what toolchain do you use to build ?
p1u3sch1 has quit [Ping timeout: 244 seconds]
<wens> cross compile toolchain in unstable :)
<Tusker> :) OK
<Tusker> is your defconfig in git somewhere ?
<wens> nope
p1u3sch1 has joined #linux-sunxi
<wens> i suggest you start with sunxi_defconfig and enable whatever usb peripherals are needed
<Tusker> OK
<Tusker> I'll try that out
<wens> my config is littered with debug options
<Tusker> to confirm, sunxi-a83-wip is the correct branch to be working off ?
<wens> whose?
<wens> that will be missing usb and emac
<Tusker> OK, what is the better git to use ?
<wens> you could use my a83-emac
<wens> though i rebase it from time to time
<Tusker> from the same URL ? just different branch ?
<Tusker> OK, let me try to build from that
<Tusker> thanks
a|3x has joined #linux-sunxi
<Tusker> and the uboot branch ?
<Tusker> a83t-usb ?
reev has joined #linux-sunxi
reev has quit [Max SendQ exceeded]
<wens> that's already upstreamed
<wens> the latest rc should do
reev has joined #linux-sunxi
ganbold has quit [Ping timeout: 260 seconds]
<Tusker> OK, I'll pull v2016.05-rc3 from upstream
<Tusker> LOADADDR=0x8000 ?
IgorPec has joined #linux-sunxi
ganbold has joined #linux-sunxi
<wens> use zImage
<Tusker> ok
ganbold has quit [Read error: Connection reset by peer]
<Tusker> that's all built now, will do a jessie debootstrap and test it out later this afternoon
<Tusker> thanks for all your help
ganbold has joined #linux-sunxi
Tusker has quit [Quit: Time wasted on IRC: 3 hours 19 minutes 7 seconds]
reinforce has joined #linux-sunxi
IgorPec has quit [Ping timeout: 260 seconds]
vagrantc has joined #linux-sunxi
reinforce has quit [Remote host closed the connection]
tkaiser has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
apritzel has joined #linux-sunxi
jernej has quit [Ping timeout: 276 seconds]
IgorPec has joined #linux-sunxi
reinforce has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
vagrantc has quit [Ping timeout: 250 seconds]
reinforce has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
massi_ has joined #linux-sunxi
JohnDoe7 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 260 seconds]
NiteHawk has quit [Remote host closed the connection]
JohnDoe7 has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
JohnDoe_71Rus has joined #linux-sunxi
reinforce has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
premoboss has joined #linux-sunxi
NiteHawk has joined #linux-sunxi
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
apritzel has joined #linux-sunxi
diego_r has joined #linux-sunxi
massi_ has quit [Ping timeout: 250 seconds]
apritzel has quit [Ping timeout: 244 seconds]
Andy-D_ has joined #linux-sunxi
Andy-D has quit [Ping timeout: 260 seconds]
massi_ has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
diego_ has joined #linux-sunxi
mpmc has quit [Ping timeout: 276 seconds]
diego_r has quit [Read error: Connection reset by peer]
nihcas has quit [Ping timeout: 276 seconds]
longsleep has quit [Ping timeout: 276 seconds]
ninolein has quit [Read error: Connection reset by peer]
avph has joined #linux-sunxi
arossdotme has quit [Ping timeout: 276 seconds]
[Awaxx] has quit [Ping timeout: 276 seconds]
bamvor has quit [Ping timeout: 276 seconds]
souther has quit [Ping timeout: 276 seconds]
tomboy64 has quit [Ping timeout: 276 seconds]
leio_ has joined #linux-sunxi
leio has quit [Ping timeout: 276 seconds]
[Awaxx] has joined #linux-sunxi
ninolein has joined #linux-sunxi
arossdotme has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
souther has joined #linux-sunxi
mpmc has joined #linux-sunxi
<oliv3r> wens: you are right about the no-1.8v property, but why mention the supply, the supply is mentioned 3 lines higher, vmmc = reg_3.3
<oliv3r> unless vqmmc is a eMMC specific thing, i cna't find anything in the do about it
<oliv3r> docs*
<oliv3r> wens: also, are you familiar with the cap-mmc-hw-reset? hw reset can be either via a pin or via a mmc command, which one is implied with this property? Since the reset line is hardwired to sdc2_reset on the lime2 and the chip supports the other reset aswell
kaspter has quit [Ping timeout: 260 seconds]
<oliv3r> wens: and sorry about wronging your name! :)
bamvor has joined #linux-sunxi
<oliv3r> it was not intentional :)
nihcas has joined #linux-sunxi
apritzel has joined #linux-sunxi
<wens> oliv3r: vqmmc is something that was added in 4.6 by me
<wens> basically for sd & emmc, there are 2 supplies, vmmc supplies power to the card's internals
<wens> vqmmc supplies power for the i/o signals
<wens> on allwinner boards the 2 are typically tied together, but they mean different things
<wens> cap-mmc-hw-reset means the controller can signal the reset, as opposed to a gpio
<wens> not sure if a10/a20 support it
<Amit_T> apritzel:montjoie: Hello, able to tftp kernel and other images but I do see this when bootz , http://paste.ubuntu.com/16199625/
<Amit_T> Now this needs to be taken by kerenl or u-boot source ?
<apritzel> Amit_T: great!
<apritzel> Amit_T: the mishap looks like you have to disable the EMAC properly before leaving U-Boot
<Amit_T> apritzel: Thanks :)
<Amit_T> ok
<apritzel> Amit_T: do you have a patch somewhere?
DullTube has joined #linux-sunxi
<apritzel> Can you maybe send it to the linux-sunxi list as a start?
<Amit_T> oh sorry , not have access that machine now where patch is present
<apritzel> Amit_T: well, don't have time for that now anyway
<Amit_T> but do I need to send it to u-boot list or kernel list ?
<oliv3r> wens: ahh so it is that, okay i'll add vqmmc as a 3.3 source as well
<apritzel> u-boot list, of course
<Amit_T> ok ,Also about this crash , is itn't it's duty of linux to take care of it , I mean I am just thinking
<oliv3r> wens: well the host driver talks to the registers, and the eMMC chip supports it
ricardocrudo has joined #linux-sunxi
<apritzel> Amit_T: maybe, needs to be investigated
<apritzel> Amit_T: that's why I was asking for the U-Boot driver ...
<apritzel> code
<apritzel> Amit_T: also a driver does make certain assumption, like no pending DMA transfers, for instance
<Amit_T> apritzel:ok , Also this code is running with cache off, so I have to take care of that as well , right ?
<Amit_T> ok
<apritzel> Amit_T: Do you mean your driver requires the caches to be off?
<Amit_T> Yes
<Amit_T> I mean I haven't tested it with cache on
<apritzel> just send the code and we will see
<Amit_T> but its likely to be failed
<Amit_T> ok, I will send it.
<apritzel> well, I'd love to play with it on the Pine64
kz1_ has quit [Quit: kz1_]
<Amit_T> Me too :)
<apritzel> U-Boot seems to be more hackable in this regard, so debugging a Pine64 MAC driver on U-Boot may be easier
<Amit_T> Just waiting for USB to USB cable to come
<Amit_T> Yes, it looks so
<apritzel> btw: I managed to get my whole new image working yesterday night
<apritzel> with 64-bit upstream U-Boot, heavily Allwinner-stripped ATF in SRAM and no arisc, all loaded from boot0
<Amit_T> Nice, This images containes ATF and all?
<wens> with u-boot you can play with registers, and shoot your feet in the process :)
<Amit_T> ok
<apritzel> wens: sure, but with it's quickly reset and re-loaded, with FEL boot you can even fix it very quickly
<wens> true
<Amit_T> apritzel: Just wanted to check, boot0 source present in sd card ?
<apritzel> there is not boot0 source, I just take the binary blob from Allwinner
<apritzel> we don't have an alternative to that yet
<apritzel> needed some tricks and trampolines to convince boot0 to do what I wanted
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
<oliv3r> wens: do you know of an easy way to reset the mmc controller from userspace? i can do a test to see if it works at all
<wens> oliv3r: nope
<wens> afaik it's all handled by the mmc core
<oliv3r> so no way to test it then?
<NiteHawk> find a way to set bit 0 of SD_CTRL? according to the user manual that should lead to a soft reset the SD/MMC controller
gzamboni has quit [Remote host closed the connection]
gzamboni has joined #linux-sunxi
enrico_ has joined #linux-sunxi
gzamboni has quit [Remote host closed the connection]
<KotCzarny> hrm, its not about sleeping but my stupid router o.o
<KotCzarny> somehow when it resets periodically it doesnt reconnect properly
gzamboni has joined #linux-sunxi
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
<Amit_T> apritzel: Oh , you mean to say , you didn't make any change in boot- source, we just only can get boot0 binary , right ?
FuNkY^MoNkEy has joined #linux-sunxi
FuNkY^MoNkEy has left #linux-sunxi [#linux-sunxi]
<wens> NiteHawk: afaik oliv3r is talking about eMMC reset, not MMC controller reset
<oliv3r> NiteHawk: i am :)
<oliv3r> and there's 2 ways to do it that i know off, send a mmc control message or whatever it is called, or pull the pin low
<wens> oliv3r: afaik cap-mmc-hw-reset means the controller can toggle the pin itself, instead of having the mmc core use a gpio
<oliv3r> the emmc chip can do both; so i'm assuming setting dt property is all that is needed
<Amit_T> wens: Hello, just wanted to check , your EPHY driver is written for H3 only and can't be used for A64 ?
<wens> the mmc reset control message is not related to the flag
<oliv3r> ahh okay
<wens> Amit_T: only the H3 has the EPHY
<oliv3r> then that is a good question
<oliv3r> in that case, it is not supported on our hw
<oliv3r> we need a gpio
<wens> but responses indicate that it should just be folded into the EMAC driver, by way of a second register range
<oliv3r> wens: can we define a gpio for the reset in the dt allready? or is this all missing still
<Amit_T> wens: But there is an register which allow you to select ext PHY or Internal PHY
<wens> oliv3r: i think its the emmc-pwrseq thing
<oliv3r> wens: i'll look into that
<wens> Amit_T: _second register range_
<oliv3r> what that is a very little used property
<wens> so the EMAC driver would toggle them by itself, without resorting to a clock or platform driver
<wens> Amit_T: as the EMAC driver currently stands, you can use it + a20-gmac-clk to toggle the bits
<wens> Amit_T: and the A64 does not have the bits for selecting internal/external phy
<wens> Amit_T: please look at the user manual
<Amit_T> ok
<Amit_T> Thanks
<Amit_T> wens: May be PHY_SELECT bit is not documented for A64 ?
tkaiser has joined #linux-sunxi
<wens> What's to select when there isn't one?
leio_ is now known as leio
<wens> there's no internal phy, no pins indicating one exists, no registers for it
<wens> no mention of it in the manual
<Amit_T> I mean to say that external PHY can only be used when we clear PHY_SELECT bit(which indicates ext PHY), Sorry if just sound stupid
<apritzel> wens: I am not so sure about your EPHY bits being merged
<apritzel> actually having this bit extra makes more sense
<apritzel> I tried to hack the existing a20-gmac-clk to cover the A64 as well, see the two clk-a20-gmac patches in here: https://github.com/apritzel/linux/commits/a64-wip
fdcx has quit [Ping timeout: 276 seconds]
<apritzel> so having one clock/PHY driver for the H3 and an extended a20-gmac-clk driver for the A64 makes more sense to me
<apritzel> they are easily referenced from the MAC DT node
<Amit_T> apritzel: what do you mean by this line , actually having this bit extra makes more sense ?
<wens> why do they keep changing it :/
<wens> merging them into the emac driver works too
<wens> and the emac bindings would indicate whether internal/external phy are used, and which of MII/RMII/RGMII to use as well
<apritzel> Amit_T: I meant the EMAC Clock register (@0x01c00030)
<wens> Amit_T: i am fully aware of what the bit does
<wens> what i meant was merging the EPHY driver into the EMAC driver
<Amit_T> ok
<apritzel> wens: yeah, I guess there are argument for both approaches
<apritzel> since this register is actually both a PHY control register as well as a clock register
<wens> apritzel: when i first did gmac support, it was supposed to be part of the glue driver
<wens> it was argued that since it was a clock, it should be a clock driver
<wens> looking back i think having the glue driver directly poking the bits is better
<wens> the clock api don't map to what the register controls are capable of
<wens> with the new SoCs, it's not even part of the clock controller block anymore
fdcx has joined #linux-sunxi
<montjoie> wens: so if I understand you, I need to add ephy register in my driver right ?
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
nashpa_ is now known as nashpa
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
<KotCzarny> tkaiser: you are advocating 1.3ghz on h3, yet in armbian max_freq in fex is set to 1.2ghz?
FlorianH has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 250 seconds]
p1u3sch1 has joined #linux-sunxi
DullTube has quit [Quit: Leaving]
<wens> montjoie: i guess it's still under debate?
<wens> no one else replied
<apritzel> wens: are you referring to that older thread on linux-sunxi?
<apritzel> apritzel: so it's OK to revive this?
<wens> apritzel: the actual ephy driver submission
<wens> rfc
adj__ has quit [Ping timeout: 240 seconds]
adj__ has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
Amit_T has quit [Ping timeout: 246 seconds]
<KotCzarny> wth hdmi is ifdeffed with config_switch
orly_owl_ has joined #linux-sunxi
Amit_T has joined #linux-sunxi
orly_owl has quit [Ping timeout: 246 seconds]
tipo has quit [Remote host closed the connection]
Shirasaka-Hazumi has quit [Ping timeout: 252 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
IgorPec has quit [Ping timeout: 246 seconds]
tipo has joined #linux-sunxi
reev has quit [Ping timeout: 260 seconds]
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Client Quit]
Amit_T has quit [Quit: ChatZilla 0.9.92 [Firefox 40.0/20150807094952]]
Amit_T has joined #linux-sunxi
tipo has quit [Remote host closed the connection]
<oliv3r> mripard: the eMMC board was developped with Ultimaker (we needed eMMC over nand); I know olimex sells them allready, there are users on the armbian forums for example that have these boards as well. I do not know when olimex will update their web-shop for it.
tipo has joined #linux-sunxi
<oliv3r> mripard: for example, https://www.olimex.com/forum/index.php?topic=5184.0 olimex supplies emmc images aswel
<oliv3r> mripard: and a mention of emmc on this page: https://www.olimex.com/wiki/A20-OLinuXino-LIME2 with a torrent of debian jessie for emmc memory
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Changing host]
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
premoboss has quit [Remote host closed the connection]
reinforce has quit [Ping timeout: 260 seconds]
nove has joined #linux-sunxi
afaerber has quit [Quit: Ex-Chat]
tkaiser has joined #linux-sunxi
tkaiser has quit [Client Quit]
tkaiser has joined #linux-sunxi
tkaiser has quit [Client Quit]
tkaiser has joined #linux-sunxi
<tkaiser> KotCzarny: Armbian uses 1296MHz on all H3 boards that are equipped with SY8106A voltage regulator and therefore able to exceed 1.3V when necessary. On other boards (OPi One/Lite/Zero, NanoPi M1, BPi M2+) we limit this to 1200 MHz since there VDD_CPUX is 1.3V (max). So we've to fear reliability problems. It's still 100% unrelated to what you're thinking
<lvrp16> tkaiser: you're not supporting my liquid nitrogen setup though, please support ln2 cooled orange pi ones capable of 2.0ghz
<tkaiser> lvrp16: :P and same 'wrong' focus as KotCzarny. It's mostly about VDD_CPUX and realibility
reinforce has joined #linux-sunxi
<lvrp16> everybody has access to LN2. your focus is too narrow
<lvrp16> plus 2.0ghz performs way faster
<lvrp16> ;)
<tkaiser> It's still about reliability. If you can increase VDD_CPUX so that 2.0 GHz are possible with liquid cooling (and longevity minimized to 14 days). Why not?
<tkaiser> But you can't increase VDD_CPUX that much without getting in trouble. And that's the reason 1536 MHz are a problem and not temperature in the first place
<lvrp16> but i want to have the highest score on the sunxi benchmark wiki
<lvrp16> my life depends on it
<lvrp16> sunxi wiki benchmark page
<lvrp16> nvm
<lvrp16> tkaiser: i didn't check myself but can you ssh as root/1234 after imaging?
<lvrp16> to setup the user account?
<lvrp16> or is it restricted to local login only?
<tkaiser> lvrp16: Always SSH enabled, you just need a DHCP server or are able to deal with link local addresses ( ;)
<lvrp16> so root login is enabled by default right?
<Shirasaka-Hazumi> yeah
<lvrp16> ok thanks ;)
<tkaiser> Sure, root/1234 and then new password, then new sudo enabled user account.
jernej has joined #linux-sunxi
Blauapause has joined #linux-sunxi
<lvrp16> awesome, a lot of users complain about no video
<lvrp16> i'm trying to see why it failed to negotiate the right res
<lvrp16> vizio TVs are terrible...
<Shirasaka-Hazumi> which version?
<wens> oliv3r: still wonder if the pinmuxes actually have 8bit for sdc2
<wens> oliv3r: i guess you could try it, since the signal traces are there on the board
<lvrp16> this was on armbian 5.05, i will have them upgrade to 5.10
<tkaiser> lvrp16: We use 720p50 or 720p60 (changed that back at 5.03). Some people experience massive overscan issues. But 'no display' is new
<Shirasaka-Hazumi> caused by new kernel?
<tkaiser> lvrp16: And people are asked on 1st boot to change display resolution to their needs using h3disp. It seems it's only an issue with first boot since they don't even see that they should login due to overscan issues.
<Blauapause> Qucik (stupid) question: I am on a cubietruck running ubuntu LTS 14.x (with root on /dev/sda ) - would like to migrate to Debian (to get updates, etc) .. Any recipe on how I can do this? (booting with the Debian Installer image on sdcard seems to ignore sdcard, waits for sda)...
<lvrp16> tkaiser: thanks, they are using a hdmi->dvi adapter, i told them about the -d switch
vagrantc has joined #linux-sunxi
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
<lvrp16> tkaiser: did you fix the usb hub detection code between the plus and the one?
<lvrp16> so that if you plug in a usb hub, it doesn't mistake it for a plus? in armbian 5.10?
<Blauapause> ok.. I understand my sdcard is not working right, so cubietruck tries to fallback on sda
ganbold has quit [Ping timeout: 244 seconds]
<tkaiser> lvrp16: Nope, we're still prone to 'auto detection gone wrong'. Also attached WiFi dongles create a mess. Will be fixed with one of the next releases. Simply recommend to not attach this stuff on first boot
<lvrp16> ok thanks
<jelle> hmm anyone got some clue if there is more info about the HDMI controller in the H3
cosm has joined #linux-sunxi
lemonzest has joined #linux-sunxi
zuikis has joined #linux-sunxi
tkaiser has quit [Ping timeout: 244 seconds]
<oliv3r> wens: we decided to add the signal traces for 8 bits because the drop in replacement for the a20 might have all 8 lines, so no harm in adding them
<oliv3r> wens: you might recall the image i posted on the wiki of the eMMC module we hand-solderd on a lime2, we used all 8 lines but failed to get it to work with those 8 bits. I posted it on the linux-sunxi mailing list as well
<oliv3r> wens: and I think mmc-prwseq-emmc is what i want to add for the GPIO reset line
<oliv3r> i'll see if i have time to test it, though i'm not quite sure yet as to how i want to test it
tkaiser has joined #linux-sunxi
IgorPec has joined #linux-sunxi
mossroy has joined #linux-sunxi
tipo has quit [Read error: Connection reset by peer]
tipo has joined #linux-sunxi
tkaiser has quit [Ping timeout: 252 seconds]
longsleep has joined #linux-sunxi
tkaiser has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
jernej has quit [Ping timeout: 246 seconds]
jernej has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
tkaiser has quit [Ping timeout: 244 seconds]
enrico_ has quit [Quit: Bye]
p1u3sch1 has quit [Ping timeout: 240 seconds]
tkaiser has joined #linux-sunxi
massi_ has quit [Quit: Leaving]
p1u3sch1 has joined #linux-sunxi
apritzel1 has quit [Ping timeout: 244 seconds]
apritzel has quit [Ping timeout: 244 seconds]
ojn has quit [Ping timeout: 260 seconds]
ojn has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
staplr has joined #linux-sunxi
simosx has joined #linux-sunxi
<tkaiser> KotCzarny: It's 1296 ;)
<KotCzarny> see line 734
<KotCzarny> unless this line doesnt play any role
<tkaiser> 733 jumps in. You could also delete 733 and increase the value in 734 and get 20 support requests more since a message appears when querying dmesg about 'missing extremity_freq'
<KotCzarny> umkay
ricardocrudo has quit [Ping timeout: 246 seconds]
<KotCzarny> :)
<KotCzarny> its like they just got lazy and just releasing alpha code for droid
<KotCzarny> otoh it will make putting linux on those tablets harder
tkaiser has quit [Ping timeout: 244 seconds]
<longsleep> I just rebased all Pine64 BSP Kernel fixes to the BSP 2.0 tree, if anyone wants to help testing if it would make sense to use that or rather stick with the 1.2 based tree check https://github.com/longsleep/linux-pine64/tree/pine64-hacks-2.0 and let me know please
Amit_T has quit [Ping timeout: 260 seconds]
apritzel has joined #linux-sunxi
tkaiser has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
Blauapause has quit [Ping timeout: 250 seconds]
<montjoie> what is the exact sequence of cabling to do FEL for pine64, I got nothing in lsusb
<ssvb> montjoie: have you checked https://linux-sunxi.org/Pine64#FEL_mode ?
<montjoie> yes
<montjoie> with sdcard it boot but whithout it I got nothing
<ssvb> what kind of USB cable are you using?
<montjoie> USE male A-A
<montjoie> one side connected to upper pine64 usb the other on my USB hub
<KotCzarny> try other port?
avph has quit [Ping timeout: 260 seconds]
<ssvb> be sure to power off the board first, and also disconnect the UART cable
<montjoie> I have disconnect all
<montjoie> then FEL cable then power
<ssvb> hmm, no idea then, normally this should work
<montjoie> I am near sure to have seen an usb device on my last try, one month ago
avph has joined #linux-sunxi
<ssvb> one more thing, I'm powering the board from the same powered USB hub when doing FEL experiments just to be sure that the 5V and GND voltage levels are perfectly matched
<montjoie> same hub for both cable
tipo has quit [Remote host closed the connection]
<ssvb> I don't feel very happy about the Pine64 board serving 5V to the VBUS pin of the upper USB receptacle by default
<ssvb> maybe a bad USB cable? or defective/damaged board?
<montjoie> it boot perfectly from sdcard, I will try another USB hub at work
<tkaiser> ssvb: Is the upper the OTG?
<tkaiser> ssvb: Consulted wiki, yes.
<montjoie> I tried both upper and down
<ssvb> montjoie: I mean the USB OTG part of the hardware, which might be potentially broken on your board (as one of the possible explanations)
<ssvb> does the upper USB port at least work correctly as USB HOST in Android or with longsleep's Ubuntu images?
<longsleep> i have never tried
* longsleep searches an OTG adapter
<tkaiser> ssvb: Just tried with an Apple keyboard and optical mouse: Nope. The lower does
reinforce has joined #linux-sunxi
<NiteHawk> ssvb: got a couple of minutes? if so, it would be nice if you could activate Travis CI for the sunxi-tools repo, see https://github.com/linux-sunxi/sunxi-tools/pull/40#issuecomment-216454309
<ssvb> longsleep: the upper USB receptacle is expected to be configured as USB HOST in normal operating systems, I think the whole point of arranging it this way was to have 2 USB HOST receptacles
<ssvb> tkaiser: hmm, I hope it's just a software problem and nothing is broken on the hardware side
<ssvb> NiteHawk: can't you do this yourself?
<longsleep> wasnt able to find an OTG adapter .. i guess it was in the bag i lost earlier this year ..
<longsleep> the upper port works just fine with keyboard though
<ssvb> longsleep: what are you going to do with an OTG adapter?
IgorPec has quit [Ping timeout: 240 seconds]
<NiteHawk> ssvb: i would, but that requires administrative rights - if you temporarily grant me those, i'm happy to do it
<NiteHawk> (travis needs an authorization/access token from github)
<ssvb> longsleep: oh, it's good to know that it's working correctly as a USB host for you
<longsleep> ssvb: connect it with the laptop - so the laptop becomes host
<longsleep> ssvb: but for that i need a cable, or my fancy adapter
<KotCzarny> longsleep, make one?
<ssvb> longsleep: but there is no ID pin or anything that would be able to signal the switch to the device mode?
<longsleep> ssvb: yes, both ports work just fine
<longsleep> ssvb: mhm 5v on the extra pin - no?
<KotCzarny> tkaiser: got a minute?
<longsleep> KotCzarny: yeah, not in the mood for cable stuff right now
<tkaiser> ssvb: Looks like it's 'just' power related and therefore hardware. I tried out the lower port, rebooted and only 1 out of 5 times the peripherals worked. And now with another try also the upper port works. This Apple USB stuff is crap
<tkaiser> I remember that I was able to power off several SBCs when connecting both keyboard + optical mouse. So maybe it's just related to peak power requirements.
<tkaiser> KotCzarny: ?
<longsleep> funny A64 BSP 2.0 added CONFIG_RTL8723CS but the driver does not compile ..
<KotCzarny> tkaiser: i cant get hdmi to work using armbian kernel of own compile. armbian pkgd one works, my compile doesnt, same uboot, same cmdline. cant find anything related different in .configs and dmesgs. do you know what it takes to get hdmi working?
<KotCzarny> longsleep: alpha quality code ftw?
<tkaiser> KotCzarny: optimize for size yes or no?
<KotCzarny> let me check, but i think 'no'
<longsleep> yeah, and the g2d stuff has undefines ..
<KotCzarny> # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
Netlynx has quit [Quit: Leaving]
<KotCzarny> anything else before i recompile?
Amit_T has joined #linux-sunxi
<ssvb> libv, Turl: what do you think about granting NiteHawk admin rights for linux-sunxi on github?
<longsleep> goooal
<KotCzarny> tkaiser, interesting, i wonder what is the cause. some code being too big or just miscompiled
<tkaiser> KotCzarny: It's kernel 3.4. Who cares?
<ssvb> NiteHawk: I tried to set you as admin for the sunxi-tools repository, hope that this helps
montjoie has quit [Ping timeout: 246 seconds]
<KotCzarny> tkaiser, yeah. but until 4.7 i'm stuck with legacy
<NiteHawk> ssvb: thanks! i'll check it out - i expect you can revoke that one that travis is set
<ssvb> NiteHawk: I'm reading https://docs.travis-ci.com/user/github-oauth-scopes and trying to understand if all these access permissions could harm us in any way
montjoie has joined #linux-sunxi
<longsleep> g2d driver only for g2d_bsp_sun8iw11.c ... :/
<NiteHawk> ssvb: i think the user/oauth token would be mine (logging into travis itself with my github account)? the repo is just read for group membership / access rights. travis rightfully refuses you to activate build testing for repos that you don't have admin access to
<tkaiser> longsleep: That's the new A20E thingie I want to run headless only ;)
<KotCzarny> tkaiser: are there any confirmed news about a20e?
<KotCzarny> apart from bsp2.0
<tkaiser> KotCzarny: Nope
<NiteHawk> ssvb: but i'll also cross-check on github as to what rights travis requested / might have now
<ssvb> longsleep: But there is still the 'transform' accelerator in A64, right? It implements a useful subset of what G2D did (pixel format conversion/rotation/scaling) and just gets rid of the ROP
<NiteHawk> ssvb: travis has set a hook (you can check it under "Settings", "Webhooks&services") for sunxi-tools - i think that's about all it does
<ssvb> longsleep: I did not try to experiment with it though, just checked the source code
<ssvb> longsleep: the comment says "display engine 2.0 transform processing base functions implement", is it included in every device which has DE 2.0 hardware?
afaerber has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
<ssvb> diego71: if eMMC costs as much as NAND, then what's the point of having NAND in the first place?
<ssvb> oliv3r: have you tried to run any benchmarks for this eMMC? how does it perform compared to NAND?
p1u3sch1 has quit [*.net *.split]
orly_owl_ has quit [*.net *.split]
mpmc has quit [*.net *.split]
Andy-D_ has quit [*.net *.split]
a|3x has quit [*.net *.split]
willmore has quit [*.net *.split]
Uninstall has quit [*.net *.split]
pietrushnic has quit [*.net *.split]
kivutar has quit [*.net *.split]
juri_ has quit [*.net *.split]
sigjuice has quit [*.net *.split]
indy has quit [*.net *.split]
jernej has quit [*.net *.split]
longsleep has quit [*.net *.split]
mossroy has quit [*.net *.split]
cosm has quit [*.net *.split]
JohnDoe_71Rus has quit [*.net *.split]
arossdotme has quit [*.net *.split]
Nyuutwo has quit [*.net *.split]
al1o has quit [*.net *.split]
lerc has quit [*.net *.split]
akaizen has quit [*.net *.split]
jernej has joined #linux-sunxi
longsleep has joined #linux-sunxi
mossroy has joined #linux-sunxi
cosm has joined #linux-sunxi
arossdotme has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
Nyuutwo has joined #linux-sunxi
al1o has joined #linux-sunxi
lerc has joined #linux-sunxi
akaizen has joined #linux-sunxi
orly_owl_ has joined #linux-sunxi
p1u3sch1 has joined #linux-sunxi
mpmc has joined #linux-sunxi
Andy-D_ has joined #linux-sunxi
a|3x has joined #linux-sunxi
willmore has joined #linux-sunxi
Uninstall has joined #linux-sunxi
pietrushnic has joined #linux-sunxi
kivutar has joined #linux-sunxi
juri_ has joined #linux-sunxi
sigjuice has joined #linux-sunxi
indy has joined #linux-sunxi
bonbons has joined #linux-sunxi
adj__ has quit [Ping timeout: 276 seconds]
<KotCzarny> tkaiser: thx for the tip, it was exactly what was needed
adj__ has joined #linux-sunxi
cosm has quit [Ping timeout: 240 seconds]
<lennyraposo> lol pain64
<lennyraposo> just noticed that pine wiki lists an older image of mine
<lennyraposo> before the 2gb ethernet fix
<lennyraposo> :S
<KotCzarny> add autoupdate ? ;)
<lennyraposo> next release will have a the latest and greatest an no longer putting out LXDE
<lennyraposo> just stickign with base mate and xfce
<lennyraposo> also it's gonna be set to 720p
<lennyraposo> well a script
<lennyraposo> for fbset
<longsleep> fbset does not change hdmi resolution and thus does not help
<lennyraposo> it does for me
<KotCzarny> look harder
<lennyraposo> I have
<KotCzarny> scaling pixels
<lennyraposo> it works
<longsleep> its just scaled afaik
<longsleep> tv is still at 1080p
<KotCzarny> at least on h3(opipc)
<lennyraposo> hmmm
<longsleep> lennyraposo: check your tv, i am pretty sure it is impossible for fbset to change HDMI resolution
<longsleep> it is just scaled
<lennyraposo> my tv is an rca 32 inch with a max 720p
<lennyraposo> I will chekc again to confirm but it did work
<longsleep> mhm, it probably has built in down scaling
<lennyraposo> could be
<tkaiser> longsleep: It has for sure
<KotCzarny> also, check info in tv
<lennyraposo> if that's the case then my bad
<KotCzarny> some tvs can show you what resolution is on
<lennyraposo> tested against 2 rcas
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
<longsleep> btw - for now i see no point to go through the hassle with BSP 2.0
<lennyraposo> one 46 inch with 1080p support and the 32 has 720p
<lennyraposo> ya chekced last night
<longsleep> network speed is unchanged, HDMI driver stopped working and codec needs DTB updates
<longsleep> only trouble no gain
<lennyraposo> not much changed
simosx has quit [Quit: Leaving]
<lennyraposo> getting tired of internet throughput speeds being used as report cases in contrast to lan speed tests
<longsleep> i have pushed everything to github, so people can try themselves and then try to convince me to give it another look that whatever works better with the 2.0 kernels
<longsleep> lennyraposo: well, i am very good at ignoring things :)
<KotCzarny> tkaiser: btw. hdmi works, and temperature is now 39C in idle with xorg loaded (xdm login screen)
<KotCzarny> though my board is in horizontal position
<lennyraposo> I htink routers switches used by most can be quite troublesome too
<tkaiser> longsleep: Do you expect that one single individual on this planet will check out the BSP 2.0 changes?
<diego71> ssvb: i think that emmc is slighter expensive than nand. But it should be easier to use (having a embedded controller)
<longsleep> tkaiser: well, i still have some hopes for the people having network issues
<longsleep> tkaiser: personally i think its just their PSU
<longsleep> tkaiser: but who knows :)
<lennyraposo> with the 1gb a64+ it's been pretty reliable headless
<lennyraposo> but not production worthy
<tkaiser> longsleep: Yeah, also my thought. But it's useless to repeat that again and again :)
<ssvb> diego71: I guess, it depends on the volume, if emmc is produced in much larger quantities, then it may be even cheaper
<longsleep> lennyraposo: why not - it works for me without any issue many weeks at heavy load
<tkaiser> ssvb: diego71: How do you define 'storage performance'?
<ssvb> diego71: still, this olimex board seems to be using SLC for eMMC, which makes it a better choice than MLC NAND at least as far as reliability is concerned
<ssvb> tkaiser: run some benchmarks and compare results?
<diego71> tkaiser: usually if you talk about performance, you talk about bandwidth, latency eventually
<diego71> http://linux-sunxi.org/Replace_NAND_with_eMMC_howto -> found the relevant wiki page
<ssvb> tkaiser: btw, do you know if anyone has had a chance to try Orange Pi Plus 2E boards already?
<lennyraposo> forgot to add for some others at the end of that
<lennyraposo> got interrupted by th elittle one ;)
<tkaiser> I'm talking about the difference between sequential speeds and random I/O. And found most recent eMMC implementations freaking fast regarding the latter even if sequnetial througput wasn't that high
<ssvb> tkaiser: did Xunlong send any prototypes to anyone?
<lennyraposo> for running a website it does the trick
<ssvb> tkaiser: the sequential speeds can be also better for eMMC
<tkaiser> ssvb: Not that I know. But Steven contacted me recently so should I ask him for linuzx-sunxi staff donations
<lennyraposo> random i/o is the mmost important
<tkaiser> ssvb: I know, especially when boards only implement the slow SDIO mode with 4 bit @ 50 MHz
<ssvb> tkaiser: I think that Orange Pi Plus 2E looks very interesting, but we need to confirm if they are using a decent eMMC in it
<KotCzarny> ssvb, ask them directly?
<tkaiser> ssvb: If it's the same as on Plus 2 (WTC) then it's pretty fast.
<tkaiser> I ask Steven for samples. You, wens, someone else? :)
<KotCzarny> :)
<jelle> moarr samples
<KotCzarny> me, but im not an essential dev ;)
<tkaiser> eMMC used on Plus 2
<tkaiser> Random writes with 16K blocksize approx. 100 times faster than with a usual PNY SD card :)
<longsleep> tkaiser: btw, i sent tllim a list of things how they should apporach making a good official linux image - lets see what comes out of it
<jelle> nice
<lennyraposo> ya
<lennyraposo> focus on 1 at most 2 variants
<KotCzarny> tkaiser: you should only compare to decent sd card
<tkaiser> longsleep: Good to know. I don't think that my 'approach' helps that much. As ssvb already said: Too much negativity :)
<lennyraposo> ubuntu and debian as they are related
<lennyraposo> I saw someone was attempting unity on ubuntu
<tkaiser> KotCzarny: No, since no one knows what to buy. We did some tests and found that on the average sunxi board the cheap Samsung EVO perform best (since sequential speed is limited to 23 MB/s anyway)
<lennyraposo> some sort of install script
<lennyraposo> for gui
<lennyraposo> btw longsleep I must say your work is great
<jernej> longsleep: This works for resolution switching on the fly on H3: http://forum.armbian.com/index.php/topic/617-wip-orange-pi-one-support-for-the-upcoming-orange-pi-one/?p=5305
<jernej> should be same on pine64
mossroy has quit [Quit: Quitte]
<lennyraposo> still no word on mali binaries from allwinner
<lennyraposo> was suppose to be in the bsp hence why I looked
<lennyraposo> but apprently not
zuikis has left #linux-sunxi [#linux-sunxi]
<longsleep> jernej: interesting thanks - i have not enabled debugfs for disp - will certainly try it
<jernej> longsleep: It can be done also through ioctl
<longsleep> jeah but for that i need to read docs and write code
bonbons has quit [Quit: Leaving]
<lennyraposo> major problem is that the pine marketing convinved the community at large that this is a viable unit for GUI usage
<jelle> wutt
<lennyraposo> it can be but not form the get go
<lennyraposo> most peopel are expecting a gui linux distro for desktop type usage
<lennyraposo> and watching videos etc
<lennyraposo> which longsleep was correct in stating that android or remix is the only choices for that at the moment
<longsleep> i marged the 2.0 bsp kernel tree as experimental and abandon it for now
<lennyraposo> did they update the gmac
<lennyraposo> nm
<lennyraposo> will check for it myself
<longsleep> yes, but i doubt that the changes have any effect - its just compatibility for whatever SoCs they have added
<longsleep> at least i see no difference in speeds or anything with the new kernel
<nove> don't forget about the "license issues", which are stoppers in progressing the mainline work
<longsleep> yeah sure, kernel has two closed source libs, both related to hdmi
<nove> for gui, hdmi is essential, how can a mainline driver be written, if the only hardware information source is the bsp driver which has no license, making default to "all rights reserved"
<longsleep> i did not pay attention to the state of hdmi in mainline
<longsleep> i am more concerned about the dram initialization which seems that they are unwilling to release
<longsleep> so - blob boot0 is it for now
<lennyraposo> and they are not budging anytime soon on that
<longsleep> but hey, i do not need any display output :) - but booting without blobs would be nice
<lennyraposo> for my purposes I do not need display
<nove> what i am saying, is if the user wants gui, is not "US" that have to work harder, (we cant, because of the "license issues")
<longsleep> really i think nobody does :)
<longsleep> the only thing which i would need in a GUI is accellerated Chromium with hardware video decode and encode and full v4l and audio support
<longsleep> fullscreen 1080p@60hz with 1080p uvc camera video grab without lags and no overheating
<longsleep> that would be awesome
<longsleep> for a 20USD board
<longsleep> or any arm linux board for that matter
paulk-collins has quit [Quit: Leaving]
<nove> that is possible, only the software (drivers) has to be written, and the reason why not is been done, you all know already
pmattern has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
fdcx has quit [Read error: Connection reset by peer]
<oliv3r> ssvb: not any heavy benching, but its faster then regular sd (slightly) https://lkml.org/lkml/2015/9/9/210
<oliv3r> ssvb: but nand has the advantage (with a good driver) that you have full control and open source. emmc is a 'black box' which requires firmware etc
<oliv3r> diego71: that's pretty awesome :D
<oliv3r> unfortunatly they keep calling it slc emmc, it is really just mlc afaik
<ssvb> oliv3r: yes, that's a good point, some vendor really needs to start selling emmc with an open source firmware to get this issue resolved :)
<ssvb> oliv3r: and we also need open source processors to eventually replace ARM
vagrantc has quit [Quit: leaving]
<ssvb> oliv3r: hmm, why are they advertising this eMMC as SLC then?
<apritzel> ssvb: U sure you really want _yet another_ architecture?
<oliv3r> its wrong
<oliv3r> the datasheet says mlc
<apritzel> ssvb: looking at the effort it took to get arm or arm64 properly supported ...
<oliv3r> i'll send an email to olimex to notify them
<oliv3r> but in any case, we switched to emmc from nand as nand driver was still a no go and nand performance was very horrible
<oliv3r> also the problem with the firmware of the mmc is, i know android has hotfixes for firmwares to fix problems
<oliv3r> because, the firmwares can cause problems :(
<apritzel> ssvb: speaking of other architectures: any idea why or1k-elf-objdump does not work properly for me on scp.bin?
<apritzel> ssvb: I get:
<apritzel> 100: f2 38 00 00 *unknown*
<apritzel> 104: 00 00 00 15 l.nop 0x0
<apritzel> so the nop is right, but why is the jump not disassembled?
<apritzel> same for lot of other instructions later in the real code
staplr has quit [Remote host closed the connection]
fdcx has joined #linux-sunxi
<apritzel> I tried -EB as well, but it only gets "wronger"
orly_owl_ has quit [Quit: leaving]
orly_owl has joined #linux-sunxi
<ssvb> apritzel: the firmware needs to be byteswapped first, see https://github.com/skristiansson/ar100-info/blob/master/Makefile#L36
<ssvb> apritzel: then it's better to convert the binary file into elf format, I'm doing this with https://gist.github.com/ssvb/8b7072f3eb8b7a837b2e
p1u3sch1 has quit [Ping timeout: 252 seconds]
<ssvb> apritzel: only substitute "arm-none-eabi-" with "or1k-elf-"
<apritzel> ssvb: mmh, thanks for that info, but I thought that -EB would do the byte-swapping
<apritzel> I read about the endianness swap on the bus ...
p1u3sch1 has joined #linux-sunxi
nove has quit [Quit: nove]
<lennyraposo> tkaiser you kill me man
<ssvb> apritzel: that's an interesting question, still avoiding byteswapping and pretending that we have a little endian openrisc processor does not work well, considering that we still have funny looking string constants
<lennyraposo> some of your posts are so blunt and to the point
<lennyraposo> "C'mon guys, in the upper right corner of your browser window is a search field. Try to do the obvious...."
<lennyraposo> should use that as my signature
<lennyraposo> had ot explain to someone how to use apt-cache search
<lennyraposo> to check for nginx and php7
<ssvb> apritzel: so byteswapping the firmware binary is the right thing to do and get it exactly in the same way how it looks on the openrisc side
<lennyraposo> hey longsleep
<lennyraposo> have you ever attempted loading the rootfs on usb sata drive?
<lennyraposo> if not I will let you know how it goes
<lennyraposo> ;)
<ssvb> apritzel: as for _yet another_ architecture, https://www.youtube.com/watch?v=mD-njD2QKN0 looks quite convincing
<ssvb> apritzel: the main point is that FPGA and ASIC have become a lot more affordable nowadays, so the hobbyists now have a chance to challenge the proprietary IP vendors
<ssvb> apritzel: and unless the ARM architecture license eventually becomes royalty free, it does not seem to have a bright future to me
<ssvb> apritzel: but it still may take a decade or something like this :)
<apritzel> I am not so much concerned about silicon, more about the software ecosystem
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
<apritzel> looking back at _how much_ work it was to get arm (or arm64) to the current state
<apritzel> where it is still missing things compared to x86
aballier has quit [Ping timeout: 260 seconds]
aballier has joined #linux-sunxi
<apritzel> frankly: you need more than a toolchain and a kernel port to get a good architecture support
<ssvb> what else do you need?
<apritzel> support for runtime stuff like JITs or VMs
<ssvb> well, this stuff is not strictly necessary
<apritzel> optimization for all those packages that have assembly optimizations
<apritzel> Linaro really spend a lot of time on this
<apritzel> *spent* and is still spending
<lvrp16> property right expiration for instruction sets?
reinforce has quit [Quit: Leaving.]
<ssvb> apritzel: frankly speaking, Linaro is not particularly good at doing this work
<apritzel> lvrp16: some early ARM stuff is already free, AFAIK
<apritzel> ssvb: Linaro has many issues, but at least the porting stuff they did quite well
<apritzel> ssvb: I know a lot of _really_ good guys working for Linaro
<ssvb> apritzel: all that is really needed is the affordable hardware availability, which now has eventually happened for ARM64 after the introduction of PINE64, ODROID C2 and Raspberry Pi 3
<apritzel> ssvb: agreed
<apritzel> and having open firmware for that
<ssvb> the ATF license encourages closed source implementations though
<ssvb> let's see how long it will take to be hardcoded in the boot ROM
<lvrp16> i mean all it takes is some lobbying for darpa funds...
<lvrp16> isn't opensparc free?
<lvrp16> and risc-v
<apritzel> speaking of which, how do you like: $ ./boot0img -o pine64_atf_sram.img -u /src/u-boot.git/u-boot-dtb.bin -e -d trampoline64:0x44000 -s /src/arm-trusted-firmware.git/build/sun50iw1p1/debug/bl31.bin -a 0x44008
<apritzel> ssvb: ^^
<apritzel> or better readable: ./boot0img --output ... --uboot ... --embedded-header --dram trampoline64:0x44000 --sram ... --arisc_entry 0x44008
<apritzel> this creates an image which you can write to 19096K of an SD card and combines upstream 64-bit U-Boot and a heavily stripped ATF running in SRAM A2
<ssvb> is SRAM C still buggy and makes the use of SRAM A2 necessary?
<apritzel> so far on this board: yes
<apritzel> ssvb: I can use 0x2.0000 till 0x2.8000 just fine
<apritzel> but a debug build is bigger than 32K, I get weird errors then
<apritzel> also since boot0 load (what it thinks is the) scp.bin to 0x40000, this works just fine for me
<ssvb> :)
<apritzel> that --arisc-entry argument of my tool creates an OpenRISC jump to the entry point, which consists of 3 instructions to halt the arisc
<apritzel> also I put the code for "ldr x9, =0x44000; br x9" to the part where boot0 assumes the ATF code
<apritzel> this is the "--dram trampoline64:0x44000" part
<apritzel> lennyraposo: longsleep: where is the best place to put a Pine64 Linux image these days?
<apritzel> I guess something around 70 MB (compressed)
<lvrp16> any1 know if the armbian orange pi plus image works for the plus 2?
<lvrp16> apritzel, are you distributing it to customers?
<apritzel> if you can live with "customers" being "everyone interested" ;-)
<apritzel> it will be an image with upstream 64-bit U-Boot, (almost) upstream kernel and Ubuntu Core 14.04.4
ricardocrudo has quit [Remote host closed the connection]
<lennyraposo> I have my own downloads section
<lvrp16> apritzel: i have a image hosting server if you want to put it there, 50T bandwidth/month
<lvrp16> i use like 100GB/month
<lvrp16> if you will be using it for lots of images, i can set you up on it
<apritzel> lvrp16: thanks, but ideally I hope to not add too much to that flood of images
<apritzel> actually eventually it should work out of the box by just using some distro installer
<apritzel> this "here is an image for you xyz ARM board" approach is getting really messy
<lvrp16> thats something I want to tackle once i quit my formal job
<apritzel> well, you don't need to quit for that ;-)
<lvrp16> running a business and having a full time is too much, no spare time
<apritzel> for arm64 it sounds doable
<lvrp16> i gave notice yesterday, still have to give the 2 week courtesy
<apritzel> no day jobs sounds great, but then there is this money thing ;-)
<ssvb> apritzel: btw, could you try the addresses range from 0x1C000 to 0x28000 for the ATF?
<apritzel> ssvb: doesn't that conflict with the FEL stack backups?
<apritzel> or do they end at 0x1c000 already?
<lvrp16> married to a rich wife, money's just a means now
<apritzel> I wanted to keep that range free to make it FEL compatible
<ssvb> we only need 16KiB for FEL
<ssvb> at least this works on A13
<apritzel> ssvb: oh, OK, but currently we use more?
<apritzel> (I think I checked this and decided to start 32K into SRAM C)
<ssvb> not really, currently FEL only uses SRAM up to 0x1B000 on A64 with the https://github.com/ssvb/sunxi-tools/commit/dc77476014669a6f9010a3160357391450a5196e patch
<ssvb> but if we try to enable the MMU for faster data transfers, then we probably need a little bit more than 16KiB because we can't get away with just section mapping
<ssvb> so if 0x1D000 is good enough, then it would be probably the best choice for the ATF
<apritzel> ssvb: right, either I missed a zero or I generously rounded up to 32K ;-)