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
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #linux-sunxi
iamfrankenstein has quit [Read error: Connection reset by peer]
iamfrankenstein has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
<MoeIcenowy> lvrp16: many of the sunxi boards are made in China
<MoeIcenowy> thus the certification needed is neither FCC nor CE
<MoeIcenowy> but CCC in China
<willmore> But, if you import them....
hpeter has joined #linux-sunxi
<hpeter> hello seniors, I'm had modified the OrangePI PC(Allwinner H3) DTB to add i2c entry
<hpeter> I had use "scripts/get_maintainer.pl arch/arm/boot/dts/sun8i-h3.dtsi -f" to get maintainers
<hpeter> but it's seems 3 different subtree OPEN FIRMWARE/ARM PORT/ARM/Allwinner sunXi SoC support
<hpeter> wihich source tree should I based ? Thanks
<apritzel> hpeter: Allwinner sunXi
arossdotme has quit [Ping timeout: 252 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 276 seconds]
apritzel1 has joined #linux-sunxi
<hpeter> apritzel: thanks, I'll try it
apritzel1 has quit [Ping timeout: 244 seconds]
apritzel has quit [Ping timeout: 244 seconds]
arossdotme has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
reev has joined #linux-sunxi
JohnDoe4 has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
<MoeIcenowy> if I want to access PLx on A23/33 in device tree, should I use <&r_pio 11 x GPIO_ACTIVE_HIGH>?
<MoeIcenowy> and should pinctrl be defined in &r_pio ?
<MoeIcenowy> @wens
p1u3sch1 has quit [Ping timeout: 240 seconds]
p1u3sch1 has joined #linux-sunxi
tipo has joined #linux-sunxi
<KotCzarny> woo hoo, opi+2e arrived!
IgorPec has joined #linux-sunxi
<KotCzarny> and now another wait for shipping.
fredc has joined #linux-sunxi
reev has quit [Read error: Connection reset by peer]
fredc has quit [Ping timeout: 265 seconds]
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
IgorPec11110 has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
<plaes> KotCzarny: one possibility is this: https://linux-sunxi.org/SY8106A
IgorPec11111 has joined #linux-sunxi
IgorPec11110 has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
<plaes> can someone with access to dl.linux-sunxi.org add datasheet for https://linux-sunxi.org/SY8106A
apritzel has joined #linux-sunxi
reev has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
reinforce has joined #linux-sunxi
oneinsect has joined #linux-sunxi
<wens> more sites picking up the news
IgorPec11111 has quit [Ping timeout: 260 seconds]
tkaiser has joined #linux-sunxi
IgorPec has joined #linux-sunxi
<ssvb> wens: this is very bad :(
<plaes> :(
<MoeIcenowy> :-(
<ssvb> lots of "witch hunt style" news badmouthing Allwinner mean that the closed source proponents inside of Allwinner will likely gain even more power
<ssvb> this might throw a really big wrench into the efforts of the Pine64 folks, who are trying to convince Allwinner that open sourcing libdram and other code for A64 would be a good thing for everyone
dave0x6d has quit [Ping timeout: 250 seconds]
<ssvb> couldn't these f*ckers at least write something positive about having the kernel sources and being able to audit them?
dave0x6d has joined #linux-sunxi
TheLinuxBug has quit [Ping timeout: 276 seconds]
TheLinuxBug has joined #linux-sunxi
vickycq has quit [Ping timeout: 276 seconds]
dave0x6d has quit [Ping timeout: 250 seconds]
dave0x6d has joined #linux-sunxi
orly_owl has quit [Ping timeout: 276 seconds]
orly_owl has joined #linux-sunxi
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
IgorPec has joined #linux-sunxi
yann has quit [Ping timeout: 276 seconds]
vickycq has joined #linux-sunxi
<plaes> yeah.. there were comments about allwinner phones :(
<KotCzarny> otoh leaving such hole in production is bad
<montjoie> does anyone here with Gigabit EMAC needed to tweak tx/rx delay ?
<wens> bpi m3 does
<wens> cubietruck plus doesn't
lemonzest has joined #linux-sunxi
<NiteHawk> montjoie: bpi-m1 is emac, or? it uses GMAC_TX_DELAY=3
<NiteHawk> argh... gmac
<NiteHawk> nvm
<montjoie> wens: I have updated http://linux-sunxi.org/Sun8i_emac for instructions but we need a proper way to do it
ninolein has joined #linux-sunxi
ninolein_ has quit [Ping timeout: 276 seconds]
<wens> montjoie: it's probably going to be a couple of dt properties
<mripard> but that can change from one board to another right?
<montjoie> mripard: yes it is why it need to be in dt, but currently the only one way is devmem
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
lennyraposo has quit [Ping timeout: 260 seconds]
<mripard> montjoie: sorry, what I meant was can it change between two orange pi pc for example
yann has joined #linux-sunxi
apritzel has joined #linux-sunxi
lennyraposo has joined #linux-sunxi
<montjoie> mripard: since it is written in fex I think no
vickycq has quit [Ping timeout: 264 seconds]
vickycq has joined #linux-sunxi
vickycq has quit [Ping timeout: 260 seconds]
vickycq has joined #linux-sunxi
<mripard> didn't we have some issues with this in the past on the A20?
<mripard> I thought so
<plaes> we had
vickycq has quit [Ping timeout: 252 seconds]
vickycq has joined #linux-sunxi
<plaes> linksprite nano, cubietruck, banana pi..
<plaes> these boards have workaround in u-boot
<mripard> yeah, I know
tipo has quit [Remote host closed the connection]
<NiteHawk> but that was rx/tx delay between different hardware (devices), not variation among the same board/model
tipo has joined #linux-sunxi
<mripard> ok, so I was wrong
<plaes> o_O
<wens> mripard: it shouldn't unless they redesigned the board
<wens> then we get problems like a dt for revision A that doesn't work for revision E
<wens> or vice versa
<mripard> but it turned to be a phy issue, not a delay one
<mripard> then yeah, the DT seems like the right solution
Worf has joined #linux-sunxi
fredc has joined #linux-sunxi
reev has quit [Read error: Connection reset by peer]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
matthias_bgg has joined #linux-sunxi
<NiteHawk> hmm... kernel 4.6-rc7 sunxi_defconfig is missing "CONFIG_SYSVIPC=y", while multi_v5_defconfig and multi_v7_defconfig have it
<apritzel> NiteHawk: isn't there some config overlay feature in the kernel?
luoyi has joined #linux-sunxi
<luoyi> sun4i-codec driver is working correctly in 4.5.3 ?
<oliv3r> mripard: where is the arm git tree that i can use to extract the hash for the proper commit reference?
<luoyi> I enabled the codec and aplay a wav file give me : aplay: pcm_write:2004: write error: Input/output error
<NiteHawk> apritzel: i'm building my own config based on that using scripts/kconfig/merge_config.sh - not a problem. but i just ran into a quirk using a gentoo-flavored kernel that 'silently' introduced a dependency on SYSVIPC, and ended up with a linking failure (undefined references) for vmlinux :P
<NiteHawk> so i just wondered if it should be set by default across all three *_defconfigs provided
<apritzel> yeah, I was wondering whether we should base sunxi_defconfig on top of multi_v7_defconfig to avoid those issues
<apritzel> arnd was asking for something like this for kvm_defconfig for ARMv7
<apritzel> NiteHawk: and to answer your question: yes, it should be set
<NiteHawk> apritzel: guess that means i'm supposed to submit a patch... :D
<apritzel> NiteHawk: well, I think so, but the question is whether it's worth to keep sending patches to keep the sunxi_defconfig up-to-date (for instance if multi_v7_defconfig gains something)
<mripard> oliv3r: it depends on where the commit has been applied
<apritzel> or whether we should make sunxi_defconfig some kind of diff against multi_v7_defconfig
<oliv3r> mripard: well you asked me to fix my commit reference, and I didn't know which commit reference i needed so only used the subject :( sorry!
<mripard> NiteHawk: if it's missing, please send a patch
<apritzel> NiteHawk: so that sunxi_defconfig takes multi_v7_defconfig, adds features and possible removes others
<mripard> apritzel: the point of sunxi_defconfig all along has been to not pull all the bloat multi_v7 brings
<mripard> so it would kind of defeat the purpose
<wens> oliv3r: the proper format is """commit <git hash> ("first line of commit message")"""
<wens> oliv3r: and you'd use the hash from a tree that is destined for mainline, such as mripard's tree, or arm-soc
<apritzel> mripard: I see that idea, I am just wondering if we miss something useful by doing so and whether it's really still useful (read: non-bloated compared to multi_v7) these days
<apritzel> mripard: all sunxi SoCs are ARMv7, right?
<apritzel> with the smallest one being based on a Cortex-A8?
<luoyi> mripard: why can't we just set the sun4i-codec's dts status to okay by default. does the sun4i-codec driver or the dts file needed to be modified for every different boards ?
<oliv3r> wens: yeah but i don't know the git hash, and using my local hash probably is wrong :)
<wens> oliv3r: git.kernel.org has cgit, please look it up
<wens> or fetch the related trees from git.kernel.org directly
<NiteHawk> mripard, apritzel: to reflect that idea, the multi_v?_defconfig files should probably based on a 'minimalistic' sunxi_defconfig. unfortunately it looks like there's no simple way to "include" these configs into each other?
<wens> luoyi: boards might not use it, instead opting for I2S for "better" sound
<NiteHawk> ..be based
Worf has quit [Quit: Konversation terminated!]
ricardocrudo has joined #linux-sunxi
<apritzel> NiteHawk: this is the question, I dimly remember there was something
<wens> luoyi: one good example would be the A20 based guitar effects pedal on kickstarter
<oliv3r> wens: but it's not applied on kernel.org as far as I understood, but i'll double check
<wens> oliv3r: i not talking about linus' tree
<luoyi> wens: the i2s driver is still not in the mainline kernel tree now.
<wens> oliv3r: git.kernel.org hosts a whole bunch of peoples repositories, including mripard's
<wens> luoyi: that is another problem
<luoyi> wens: and I'm using a bpi m1+, want to enable the integrated codec
<oliv3r> wens: but i think mripard ment the upstream branch on which it was applied, my guess now is armsoc
<wens> luoyi: then (send a patch to) enable it in the board dts?
<wens> oliv3r: yes
<luoyi> wens: I've add status='okay' in the m1+'s dts file
<wens> oliv3r: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
<luoyi> but can't work correctly
<oliv3r> wens: yeah that's the one i'm looking at right now
<luoyi> aplay -l can list the sound card, but it can't work.
<oliv3r> wens: found it! thanks for the help :)
<wens> luoyi: try opening the mixer and unmuting some of the controls
<NiteHawk> mripard: would you agree that "CONFIG_SYSVIPC=y" is not considered bloat, and should be in sunxi_defconfig?
<luoyi> wens: I've tried alsamixer and amixer, it can give me some mixer but can't adjust them.
premoboss has joined #linux-sunxi
<luoyi> aplay a wav file just give error like this:
<luoyi> [root@alarm ~]# aplay Yamaha-TG100-Whistle-C5.wav Playing WAVE 'Yamaha-TG100-Whistle-C5.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo aplay: pcm_write:2004: write error: Input/output error
<wens> luoyi: what mixer controls do you see?
<wens> everything is muted, nothing will play (ALSA will block)
<wens> unmute Power Amplifier DAC and Power Amplifier Mute
<mripard> luoyi: some boards might or might not use it, so, yeah, we have to enable it on all the boards that make use of it
<luoyi> in the alsamixer , I can just tuning 'Power Amplifier', I can't tuning anything other
<wens> luoyi: press 'm' to toggle mute
<mripard> NiteHawk: I don't really know what that option is about to be honest, so I can't really say
<wens> luoyi: you should check the manpage
<luoyi> m just give me 00, and up / down doesn't work
<wens> mripard: SYSV IPC is ancient version of shared memory , semaphores , (and one other thing i forgot)
<wens> luoyi: OO is unmuted, MM is muted
<mripard> oh, so it is what it obviously is
<mripard> then yeah, we should add it
<wens> luoyi: as i said, read the manpage for alsamixer
<luoyi> wens: okay. I understand. I should unmute 'Power Amplifier Mixer' , and adjust the volume through 'Power Amplifier'
<wens> it helps if you could look at the audio codec diagram in the A10 or A20 user manual to understand what the controls are
<wens> you need an unmuted path from the DAC to the output
<luoyi> OK. it sounds good now. thank you for your explaination.
<wens> :)
<luoyi> and I just find the integrated codec sounds really bad ......
<luoyi> hope we can have a mainline i2s driver quickly
<wens> i'm using an earphone, seems ok
<luoyi> I've used a rpi2+es9023 dac board as my music playbox for some time now, and want try to make use of the allwinner board replace it
<luoyi> I can hear some noise while playing music
<luoyi> I'll try to change music file and give it retry
<wens> montjoie: half way through my emac/ephy rework
<KotCzarny> luoyi: noise is usb activity mostly
<KotCzarny> bad separation
<luoyi> KotCzarny: you mean usb power noise ?
<KotCzarny> nope, usb activity noise
<luoyi> usb port is empty now
<KotCzarny> onboard wifi?
<luoyi> yes
<luoyi> I'm using onboard wifi
<KotCzarny> onboard wifi is usb?
<luoyi> i
<luoyi> it's sdio
<KotCzarny> Processing Time remaining: 10 days 23 hours 59 minutes
<KotCzarny> 11 days, hrm, it will arrive when im not available :/
<KotCzarny> unless its only processing ie. making and packing
<wens> sdio clock frequencies are still in the audible range though
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
premoboss has quit [Quit: Sto andando via]
<KotCzarny> try observing if wifi activity correlates with the noise
Andy-D has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
TheSeven has quit [Remote host closed the connection]
TheSeven has joined #linux-sunxi
<speakman> Now running kernel 4.3 on A20. First wierd thing I encounter is the unability to change direction of an gpio pin.
<speakman> I've exported gpio19 (echo 19 > export) but trying to change direction on it fail with "Unknown error 517"
<speakman> Any idea what may cause that?
<speakman> It even fail when trying to gpio_direction_input() in a kernel driver
<speakman> (even though it seems to already be an input)
leio has quit [Ping timeout: 260 seconds]
<speakman> Oh, pin enum has changed severely.
Worf has joined #linux-sunxi
fl_0 has quit [Quit: STRG + Q]
pmattern has joined #linux-sunxi
fl_0 has joined #linux-sunxi
fredc has quit [Ping timeout: 244 seconds]
IgorPec has quit [Ping timeout: 246 seconds]
<willmore> speakman, I know very little about that subject, but one thing I did notice from others who have discussed something similar here in the past is that you need to make sure the pins you want to use aren't used by anthing else in the DT.
<willmore> But that's about all I know.
engideavr has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
Worf has quit [Quit: Konversation terminated!]
IgorPec11111 has joined #linux-sunxi
adj__ has quit [Quit: Leaving]
adj__ has joined #linux-sunxi
IgorPec11112 has joined #linux-sunxi
IgorPec11111 has quit [Ping timeout: 252 seconds]
<MoeIcenowy> speakman: I'm afraid there's no gpio 19
IgorPec11113 has joined #linux-sunxi
<MoeIcenowy> (Bank No. - 1 ) * 32 + Pin No. seems to be a common calculation for all the mainline SoCs...
IgorPec11113 has quit [Read error: Connection reset by peer]
<MoeIcenowy> for example, my tablet's gsl1680 touchscreen should be enabled at PH1
IgorPec11113 has joined #linux-sunxi
<MoeIcenowy> PH1 is gpio225.
IgorPec11112 has quit [Ping timeout: 250 seconds]
oneinsect has quit [Ping timeout: 250 seconds]
IgorPec has joined #linux-sunxi
oneinsect has joined #linux-sunxi
IgorPec11113 has quit [Ping timeout: 250 seconds]
cnxsoft has quit [Quit: cnxsoft]
<plaes> heh.. kinda strange place to post it..
<KotCzarny> plaes: maybe the worker responsible didnt have anything else available ;)
Net147 has quit [Ping timeout: 260 seconds]
Net147 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 252 seconds]
JohnDoe_71Rus has joined #linux-sunxi
Amit_t_ has joined #linux-sunxi
tach_ has joined #linux-sunxi
cosm_ has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
vagrantc has joined #linux-sunxi
reinforce has joined #linux-sunxi
nove has joined #linux-sunxi
lennyraposo has quit [Ping timeout: 250 seconds]
engideavr has quit [Quit: Konversation terminated!]
tipo has quit [Remote host closed the connection]
engideavr has joined #linux-sunxi
tipo has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
IgorPec11113 has joined #linux-sunxi
jernej has joined #linux-sunxi
<NiteHawk> ssvb: gimme a minute - i've only just come back home
<KotCzarny> someone learning github?
<NiteHawk> dafuq? o.O
tipo has quit [Remote host closed the connection]
<NiteHawk> KotCzarny: more like someone learning git :P the pull request seems to consist of nothing but a merge commit??
<KotCzarny> :)
tipo has joined #linux-sunxi
<NiteHawk> ssvb - your answer is: i don't have the faintest idea. looks like utter nonsense...
<ssvb> NiteHawk: just sent a e-mail to this person
zuikis has joined #linux-sunxi
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
<KotCzarny> Senior Linux Kernel Engineer, Broadcom, North Carolina
<KotCzarny> hehe
<KotCzarny> broadcom
<ssvb> something like this has also happened in the past - https://github.com/linux-sunxi/linux-sunxi/pull/248
<NiteHawk> btw: pine64 has arrived. a big thank you to apritzel! :)
<ssvb> NiteHawk: congrats, this was really fast
<NiteHawk> i'll test your fel support patch later and plan to merge it afterwards - do you consider it stable / 'final' enough for that?
<apritzel> NiteHawk: enjoy, looking forward to your USB, Ethernet and HDMI support patches :-P
<NiteHawk> X)
<montjoie> crypto engine aes support complete, now working on hash
<montjoie> will I resist to bench it...
<ganbold> montjoie: which SoC?
<montjoie> H3
<KotCzarny> bench with cpuburn!
<ganbold> nice
<montjoie> but A83T is a bit similar
IgorPec11113 has quit [Ping timeout: 265 seconds]
<montjoie> A64 is same as H3 (just +/- some algos)
<ganbold> montjoie: updated benchmark page would be nice
<montjoie> yes even for A20 I need it
<ssvb> montjoie: Cortex-A53 in A64 has roughly twice faster NEON per MHz compared to Cortex-A7 in H3, so the software crypto should have a nice speed boost
<ganbold> someone should make arm64 board with 2 ethernet that can be used in networking
<KotCzarny> allwinner is bad for bandwidth related stuff
<apritzel> ssvb: montjoie: also would be interesting to see how the crypto extensions perform on the A53
<montjoie> ssvb: I dont think the crypto engine use neon
<ssvb> apritzel: that's a good point
<montjoie> I speak only about the CryptoEngine no crypto extention
<montjoie> I clearly dont have the expertise on assembly
<apritzel> montjoie: I got this, I am just afraid that the A53 crypto instructions are faster than Allwinners crypto engine
<KotCzarny> apritzel: free cpu
fabo has joined #linux-sunxi
<montjoie> apritzel: 4 channel of DMA task (8 if I can use also the Secure CE)
afaerber has quit [Quit: Ex-Chat]
afaerber has joined #linux-sunxi
<ssvb> montjoie: and the use of special crypto instructions on ARM64 - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/crypto/aes-ce.S?id=refs/tags/v4.6-rc7
<apritzel> that's the point: the kernel knows about all the ARMv8 crypto extensions already and you get support for it for free
<apritzel> not sure if that was already in 3.10, though ;-)
rellla has quit [Ping timeout: 276 seconds]
<oneinsect> montjoie: i cant seem to apply that patch
<oneinsect> to the latest lichee
reinforce has joined #linux-sunxi
tkaiser has joined #linux-sunxi
rellla has joined #linux-sunxi
<tkaiser> ssvb: I want to encourage users of Orange Pi Plus 2/2E to start DRAM reliability testing on their boards since those do not use Samsung as on all other OPi but Hynix instead. Can you please correct me if I'm wrong regarding the last sentence here: http://forum.armbian.com/index.php/topic/1193-orange-pi-plus-2e-now-available/?view=getlastpost
fredy has quit [Excess Flood]
zuikis has left #linux-sunxi [#linux-sunxi]
<KotCzarny> tkaiser: there are more differences between opipc and opi+2e
zuikis has joined #linux-sunxi
yann has quit [Ping timeout: 246 seconds]
<ssvb> tkaiser: it's best to compare the schematics and/or fex files to be sure
engideavr has quit [Quit: Konversation terminated!]
<ssvb> tkaiser: but yes, the dram vendor is different and also the placement of the dram chips is different on the pcb
<tkaiser> ssvb: Hmm... it took Steven always some time to release schematic for a new board. Lets hope the best.
fredy has joined #linux-sunxi
<tkaiser> ssvb: And I'm not aware that Xunlong released fex files for new boards (at least none for OPi One)
<tkaiser> Figuring out what was needed to drive the new voltage regulator was trial&error and now we have a fex file in Armbian Github repo
<ssvb> did they make any statements about the software compatibility with other boards?
<tkaiser> Fortunately the rest remained the same compared to Orange Pi PC (minus 2 USB ports that are still there as solder points)
<tkaiser> ssvb: Nope. Unfortunately not. Not even mentioned whether the new WiFi chip is compatible: 8189ETV vs. 8189FTV now
<ssvb> the first users will probably have some fun trying to make these boards work properly, as usual
<KotCzarny> :)
<KotCzarny> my guess opipc fex will work out of the box
<tkaiser> ssvb: I'm not that concerned since Steven is smart. All 9 (or 10?) H3 based Orange Pi share most pin mappings. Only expections: network and USB hub or not
<tkaiser> KotCzarny: Nope, different Ethernet PHY.
<KotCzarny> tkaiser, apart those changed parts
<tkaiser> Read the link to Armbian forum link above.
staplr has joined #linux-sunxi
<KotCzarny> tkaiser: for now its waiting game, 7-15 days of delivery
<KotCzarny> we will see what's up when the boards arrive
<tkaiser> KotCzarny: I'll watch linux-sunxi wiki, you'll create the device page and submit first memtester result. Thx ;)
<KotCzarny> unless you took some speedier shipping
<KotCzarny> tkaiser: sure, will do
<KotCzarny> if it boots ;)
<KotCzarny> and i hope he didnt make any mistakes or had time testing it before offering on ali
dev1990 has joined #linux-sunxi
<KotCzarny> and i belive 2e could be just a note on opi+2 page
<tkaiser> KotCzarny: I'll prepare a fex file for OPi Plus 2E in the meantime and if you don't mind it would be great if you could give an Armbian image based on that a try then.
<KotCzarny> sure
<dave0x6d> KotCzarny: did allwinner contact you?
<KotCzarny> dave0x6d: huh? why? nope
<dave0x6d> KotCzarny: their press team contact me.
<dave0x6d> *contacted
<tkaiser> dave0x6d: Me2
<KotCzarny> i dont have any blog, and there are no allwinner employees on irc here
<KotCzarny> direct them here
<dave0x6d> tkaiser: did they do the same thing and copy-paste the press release from their github repo?
<KotCzarny> it would be intersting ;)
<dave0x6d> KotCzarny: one sec, will do.
<KotCzarny> ask for someone speaking at least basic english ;)
<tkaiser> dave0x6d: Maybe the other way around. First sent the press release and then opened an issue with it in their own Github repo ;)
<dave0x6d> oh oops, you're right.
<dave0x6d> not sure why my mail lagged by so much.
<dave0x6d> tkaiser: oh yeah there's no way this is a malicious backdoor. Just a very stupid debugging backdoor.
<tkaiser> dave0x6d: Do you call this a 'backdoor'? Not a simple local privileges escalation?
<dave0x6d> tkaiser: heh, imo it is a backdoor because they should be using su.
<nove> i like this one, "Isn't this what Android users have always wanted?"
<dave0x6d> the front door (su) works fine.
<tkaiser> nove: But isn't it true? That's the first thing they ask for...
<dave0x6d> I'm not an Android guy, but can't you just flash any ROM you want with su?
<nove> yes is true, but this only got in the news because of the keywords "backdoor" and "root", and so
<tkaiser> dave0x6d: No idea. I used Android once to test out Pine64 boot showstoppers. And that's it :)
<willmore> montjoie, I have H3 and A64 boards, let me know if you want me to do any soak testing or anything.
rellla has quit [Ping timeout: 244 seconds]
<dave0x6d> tkaiser: I asked jduck and he didn't know of any reason why they couldn't use su.
<dave0x6d> nove: of course =)
<dave0x6d> that wasn't accidental.
<dave0x6d> brb, food.
<KotCzarny> dave0x6d: laziness
rellla has joined #linux-sunxi
<KotCzarny> also, it makes a real hole in the system, where su is a legitimate and secure (if configured right) tool
<dave0x6d> KotCzarny: but... but.. how is using 'su - root' harder than 'echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug'?
Amit_t_ has quit [Quit: Page closed]
<KotCzarny> because you should have to authenticate
<KotCzarny> whereas that /proc/ file was wiritable by ANYONE
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
<tkaiser> KotCzarny: Just FYI. Someone mailed me that all OS images he used prior to Armbian on his Orange Pi PC had sudo enabled without authentication.
<tkaiser> And IIRC this is also the case on the original Raspbian. But I might be wrong here
<KotCzarny> tkaiser, yeah, laziness
<KotCzarny> but its easier to reconfigure os than recompile kernel
<KotCzarny> (and rebuild image as its often the case with those vendor provided ones)
<tkaiser> KotCzarny: With Armbian it was 'apt-get upgrade && reboot'
<KotCzarny> yes
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
<apritzel> longsleep: can you try if my boot0img can assemble an image with a BSP firmware chain?
<apritzel> your use case should be the first one under the Examples section here: https://github.com/apritzel/pine64/blob/master/tools/README.md
lemonzest has quit [Quit: Leaving]
<apritzel> agraf: similar request to you: the last example should cover what your pine64_image does ^^^
Gerwin_J has quit [Read error: Connection reset by peer]
Gerwin_J has joined #linux-sunxi
IgorPec11113 has joined #linux-sunxi
<longsleep> apritzel: sure - looking into it now
<apritzel> longsleep: thanks!
<longsleep> apritzel: what is u-boot-dtb.img ? u-boot combined with dtb?
<apritzel> yes
<apritzel> I think that's what upstream U-Boot uses a make target
ricardocrudo has quit [Remote host closed the connection]
<apritzel> the BSP U-Boot may not have it, so just use whatever you get out of your U-Boot compliation
<longsleep> in my postprocess i do that last, before that i have already added bl31 and scp though
<longsleep> ah no, sorry last i add the compiled fex file
<apritzel> ah
<longsleep> its the second last
<longsleep> $SUNXI_PACK_TOOLS/update_uboot_fdt $BUILD/u-boot-merged2.bin $BUILD/pine64.dtb $BUILD/u-boot-with-dtb.bin
<vagrantc> in recent versions of u-boot they've merged the u-boot-dtb.* back into u-boot.*
<vagrantc> mainlne u-boot, anyways
<longsleep> so let me try this
<apritzel> vagrantc: well, they still have both: |$ cmp u-boot{,-dtb}.bin" shows me that one is a copy of the other
<vagrantc> apritzel: yes, think they left that for backwards compatibility ...
<apritzel> vagrantc: so u-boot.bin should always be the one to care about?
<apritzel> from now on
<vagrantc> with newer versions, yes.
<vagrantc> if, for some reason, you want a split one, i think they made a new u-boot-nodtb.bin or some such
<longsleep> update_fdt:genrate /home/longsleep/Dev/a64/u-boot/build-pine64-image/u-boot-postprocess/../u-boot-with-dtb-nothing-else.bin ok
<longsleep> at least that worked, now combining the stuff with boot0img
<apritzel> vagrantc: do you know if U-Boot can use an externally provided .dtb for its own purposes? Say loaded from some flash?
<vagrantc> apritzel: don't really know ... surely very board-specific
<apritzel> yeah, that's the confusing part with U-Boot, even those things are potentially different per board
<longsleep> U-Boot: ../../../build-pine64-image/u-boot-with-dtb-nothing-else.bin: 798720 Bytes
<longsleep> DRAM : ../../../../arm-trusted-firmware/arm-trusted-firmware/build/sun50iw1p1/release/bl31.bin32820 Bytes
<longsleep> SRAM : ../../../build-pine64-image/blobs/scp.bin: 104660 Bytes
<longsleep> looks good?
<longsleep> got a 20M firmware.img now
* longsleep finds another sdcard
<apritzel> longsleep: looks OK
<apritzel> do they really have an 800KB U-Boot???
<longsleep> yes, 712K
<longsleep> rest is DT
<apritzel> ah right, this monster DT
<apritzel> upstream Pine64 U-Boot is 350KB
<longsleep> apritzel: image booted to a shell http://paste.ubuntu.com/16379994/
<longsleep> u-boot shell
<longsleep> put i guess that is expected, as my default environment loads stuff from first partition
<apritzel> Nice!
<longsleep> do you have a vfat partion there?
<apritzel> well, as nice as this bloody code can get ;-)
<apritzel> longsleep: I was toying with "./boot0img -p" to create one
<longsleep> apritzel: no partitions in the image it created
<apritzel> I know
<apritzel> "this was left as an exercise to the reader"
<longsleep> heh ok
<longsleep> let me see what happens if i just create a partition table :P
<apritzel> actually you can omit the "-b boot0.img" part
<apritzel> then it creates just the U-Boot part glued with ATF and SCP
<apritzel> which you can then dd to 19096 KB
<longsleep> where does the boot0 come from then?
<longsleep> ah
<apritzel> do you somehow protect U-Boot on the SD card?
<longsleep> no
<apritzel> I made a partition ranging from 1MB till 20MB, type 0xda (non-FS data)
<longsleep> if you create a partition on top of it - meh :)
<longsleep> good idea
<apritzel> that prevents tools from clobbering this area
<apritzel> and: make it the second partition
<apritzel> in the partition table ordering, that is
<longsleep> does need other u-boot environment though
<longsleep> ah
<longsleep> ok
<longsleep> sure
<apritzel> so that /dev/sda1 or /dev/mmcblk0p1 is still the boot partition
<longsleep> yeah got it
<longsleep> i can integrate that stuff on the weekend
<apritzel> or even better: use a GPT ;-)
<longsleep> if the BSP u-boot supports that
<longsleep> apritzel: any chance that the boot0img tool can learn to add the DTB to U-Boot as well
<longsleep> apritzel: i would love to get rid of the update_uboot_fdt as well
<apritzel> sure, I am happy to make it as versatile as possible
<longsleep> yeah it would be awesome if you could just pass a dts file :)
<longsleep> dtb file would be ok too :P
<longsleep> safk
<apritzel> can you provide me a pointer to that update_uboot_fdt.sh?
<apritzel> that's not in your repo, but in the BSP, right?
<longsleep> its not .sh - its a binary
<longsleep> i have that in a repo somewhere
<longsleep> hold on
wvualphasoldier has joined #linux-sunxi
<longsleep> apritzel: extracted them from the BSP a while ago
<apritzel> ah, cheers
<longsleep> apritzel: your built u-boot is a little smaller than the one built with all the allwinner tools, 928K vs 944K
<apritzel> from a first glance integrating update_uboot_fdt looks doable, it's bascially an aligned concatenation plus entering the start address
<apritzel> longsleep: I use 512 Byte padding, I think they use a bigger alignment
<longsleep> apritzel: yeah all the tools are pretty trivial but _very_ ugly
<apritzel> indeed!
<longsleep> and do not ask me about character encoding
<apritzel> I put some chinese comments from github into the google translator the other day - and it was actually useful
<longsleep> hehe nice
<longsleep> apritzel: all right, boot0img works fine with the rest of my image building gear - full bootlog at http://paste.ubuntu.com/16380400/
<longsleep> command i used: ./boot0img -o u-boot-with-dtb.img -u ../../../build-pine64-image/u-boot-with-dtb-nothing-else.bin -e -s ../../../build-pine64-image/blobs/scp.bin -d ../../../../arm-trusted-firmware/arm-trusted-firmware/build/sun50iw1p1/release/bl31.bin
<longsleep> and ./sunxi-pack-tools/update_uboot_fdt/update_uboot_fdt ../build/u-boot.bin ../build/pine64.dtb ../u-boot-with-dtb-nothing-else.bin
<longsleep> Means if boot0img learns to add the dtb file into u-boot.bin then bye bye ugly sunxi-pack-tools
IgorPec11113 has quit [Ping timeout: 276 seconds]
<apritzel> yes, that was my goal
<apritzel> not sure I get to it today still, though
lennyraposo has joined #linux-sunxi
<longsleep> no worries - i will update the docs and the build process when its ready
<longsleep> apritzel: boot0img already gets rid of the empty fex file - so i assume you implemented the u-boot checksum so boot0 is fine?
IgorPec has joined #linux-sunxi
<apritzel> yes, boot0img calculates the checksum
<apritzel> which is horribly trivial, btw
<longsleep> yeah i figured that much - but the write complicated code for it
<apritzel> "just add every 32-bit word and don't care about overflows"
apritzel has quit [Ping timeout: 244 seconds]
paulk-collins has joined #linux-sunxi
oneinsect has quit [Ping timeout: 250 seconds]
cosm_ has quit [Quit: Leaving]
avph has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
zuikis has left #linux-sunxi [#linux-sunxi]
ricardocrudo has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
JohnDoe9 has joined #linux-sunxi
avph has joined #linux-sunxi
bmeneg has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Ping timeout: 240 seconds]
nove has quit [Quit: nove]
reinforce has quit [Quit: Leaving.]
susan33 has joined #linux-sunxi
apritzel has joined #linux-sunxi
IgorPec has quit [Ping timeout: 252 seconds]
al1o has joined #linux-sunxi
leio has joined #linux-sunxi
vickycq has quit [Ping timeout: 260 seconds]
vickycq has joined #linux-sunxi
Gerwin_J_ has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 244 seconds]
Gerwin_J_ is now known as Gerwin_J
susan33 has quit [Quit: Quitte]
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
JohnDoe9 has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
wvusoldier has joined #linux-sunxi
wvus has joined #linux-sunxi
wvualphasoldier has quit [Ping timeout: 265 seconds]
iamfrankenstein has quit [Quit: iamfrankenstein]
wvusoldier has quit [Ping timeout: 276 seconds]
pitelpan has joined #linux-sunxi
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
wvusoldier has joined #linux-sunxi
pmattern has quit [Quit: Genug für heute.]
wvus has quit [Ping timeout: 265 seconds]
paulk-collins has quit [Quit: Leaving]
Gerwin_J has quit [Quit: Gerwin_J]
ricardocrudo has quit [Remote host closed the connection]
tach_ has quit [Ping timeout: 244 seconds]
curlybracket has joined #linux-sunxi
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
vagrantc has quit [Quit: leaving]