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
bwarff has joined #linux-sunxi
TheSeven has quit [Ping timeout: 248 seconds]
TheSeven has joined #linux-sunxi
kdubious has quit [Ping timeout: 250 seconds]
apritzel has quit [Ping timeout: 244 seconds]
orly_owl has joined #linux-sunxi
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 268 seconds]
orly_owl has quit [Ping timeout: 276 seconds]
orly_owl has joined #linux-sunxi
khuey is now known as khuey|away
tomboy65 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 244 seconds]
tsuggs has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
cnxsoft has joined #linux-sunxi
kdubious has joined #linux-sunxi
<kdubious> wens: or anyone, really... I'm lookikng at the board schematics (not the PDF) and it does seem that ITEAD uses a pull-up resistor to 3.3
<kdubious> 31 EMDIO to VDD33
<kdubious> ^ screen shot of the KiCAD is here
wazzup has quit [Quit: Leaving]
<willmore> kdubious, that trace doesn't go anywhere else.
<kdubious> I think it goes to 3.3?
<willmore> Yeah, but it doesn't go to the serial RX line.
<kdubious> i didn't turn on the VCC layer
<willmore> There's no via's.
<kdubious> wens said from the schematic, MDIO (not MDI - 0) was missing a pull-up resistor
<willmore> Oh, gotcha. Sorry, I was thinking something else. That's not really a pullup, that's a signal dead ending into a resistor to 3.3V.
<kdubious> if I turn on: Through Via... there's one to the right of the green squareVDD33
<willmore> What wens was talking about was a signal that ran from the SoC to the ....
<kdubious> I don't think the PDF showed that...
<willmore> You don't have drills on?
<kdubious> I don't know what IO'm doing is more accurate
<kdubious> I'm a software guy
<willmore> Where did you find that board file? I can go take a look. I have layed out boards.
<willmore> brb, got to tuck the wife into bed first...
<kdubious> or somewhere in ITEAD's repos
<kdubious> I'm shooting in the dark... but, Banani Pi Pro uses a gmac_phy_power_en on PH23 in their FEX file
<willmore> kdubious, What file do you see that in? I only see the carrier module in there.
<willmore> No, wait, that's different from what you said earlier.... Looking.
<kdubious> what file do I see what in? sorry
<willmore> The board layout that you took the screen shot of.
<willmore> I take it back, that's the same repo you mentioned earlier.
<kdubious> willmore: you can't open that file?
<willmore> Not the bannana pro pdf, the ITEAD file showing the daughter board with a pull up.
fdcx has quit [Remote host closed the connection]
<kdubious> it seems to go from teh SOM board to the Realtek chip
<kdubious> and branches off, through a resistor, to 3.3v
<willmore> What file were you looking at when you took this screen shot: http://apps.welshtechnologies.com/mdio_pull_up.jpg
<kdubious> so I'm wondering if there is some sort of "sense" or "enable" pin that needs to be set... and somehow, piping 3.3 to UART0 RCV does the trick...
<kdubious> I opened the .pro file with KICAD
<kdubious> then opened core_evb.kicad_pcb
<willmore> That only gives me the core board.
fdcx has joined #linux-sunxi
<kdubious> the Eval board
<willmore> Oh!
<kdubious> not the SOM
<willmore> You're looking near the GMAC!
<willmore> one sec.
<kdubious> I don't have a drawing for the SOM
<kdubious> far right... "49"
<kdubious> that's a realtek chip
<kdubious> on the right side, middle, I see EMDIO
<willmore> I don't think that's the line you're looking for. It's labeled LED0 on the board.
<kdubious> go up from there to 31 EMDIO
<willmore> I think you need to look at the MDI0-3 lines.
<kdubious> LED0 is 34
<kdubious> I thought he meant MDIO, not MDI0
<willmore> I'm not sure of that. If so, then, yeah, you're right. Clearly a pullup there.
<willmore> Take the module out and check the board for resistance there to see what the pullup is.
<willmore> From the PCB, that looks like an 0204, so there won't be markings on it.
<kdubious> "check the board for resistance there "
<kdubious> resistance scross the resistor?
<kdubious> or from a 3.3 v pin
<willmore> On a powered off board. Test from the 3.3V rail to the pin on the SO_DIMM connector for MDIO.
<lennyraposo> alrighty
<lennyraposo> time to fix the pulseaudio issue and then call it a day ;)
<willmore> You should see from between 10K to 1K, I'm guessing. I don't know anything about that buss, but if it's a 3.3V OC buss, it can't be much higher than that.
<willmore> Go, go, lennyraposo!
<willmore> Where on the globe are you, lennyraposo?
<willmore> Or Carmen Sandiago....
<kdubious> 550?
<kdubious> its quite hard to be accurate with those SO_DIMM pins
<willmore> That seems fine.
<willmore> Sorry, wens, there's a proper pullup.
<willmore> kdubious, looks like you did a proper investigation. Not sure what's still wrong. but you did your part.
<kdubious> :(
<willmore> it works!
<willmore> Why is left to the student....
<willmore> ?:
<kdubious> it works if I jump 3.3v to UART RCV
<willmore> Yeah, still not sure why that helps....
<willmore> Sorry.
<kdubious> do you know what PHYRST# is?
<willmore> PHY reset?
<willmore> # normally means active low.
<willmore> As compared to active high.
p1u3sch1 has quit [Ping timeout: 252 seconds]
<kdubious> and teh banana pi pro has settings for a regulator for the GMAC.. any chance I need those settings?
* willmore has no idea. That's above my pay grade.
p1u3sch1 has joined #linux-sunxi
<willmore> Maybe wens and I can do a mind meld.....
<willmore> My mind to your mind, my thoughts to your thoughts....
<kdubious> do you still have the schematic?
<willmore> yes.
<kdubious> below the Realtek chip...
<kdubious> ENSWREG
<kdubious> N-00000217
<willmore> Only has two nodes to it. That doesn't sound like a real regulator. should have three nodes.
<willmore> night!
<kdubious> thanks... good night
<willmore> np.
orly_owl has quit [Ping timeout: 260 seconds]
orly_owl has joined #linux-sunxi
oneinsect has joined #linux-sunxi
IgorPec has joined #linux-sunxi
zuikis has joined #linux-sunxi
cptG has joined #linux-sunxi
cptG_ has quit [Ping timeout: 276 seconds]
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
umiddelb has quit [Ping timeout: 250 seconds]
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Changing host]
JohnDoe_71Rus has joined #linux-sunxi
umiddelb has joined #linux-sunxi
umiddelb has quit [Quit: Page closed]
<oneinsect> okie I was doing a quick test for booting u-boot it says *** Warning - bad CRC, using default environment
<oneinsect> on nanopi
<oneinsect> missing environment variable: bootfile
<oneinsect> i have already given /boot/extlinux.conf
<oneinsect> okie never mind
<oneinsect> found the error it should be in /boot/extlinux/extlinux.conf
Net147 has quit [Ping timeout: 240 seconds]
vishnup has joined #linux-sunxi
Net147 has joined #linux-sunxi
<oneinsect> okie u-boot is picking up extlinux.conf
<oneinsect> but its not picking up /boot/vmlinuz-4.6.0-rc1-sunxi
<oneinsect> Retrieving file: /boot/vmlinuz-4.6.0-rc1-sunxi reading /boot/vmlinuz-4.6.0-rc1-sunxi **Unable to read file /boot/vmlinuz-4.6.0-rc1-sunxi
<oneinsect> any ideas?
Net147 has quit [Ping timeout: 244 seconds]
Net147 has joined #linux-sunxi
apritzel has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
kdubious has quit [Quit: Page closed]
kdubious has joined #linux-sunxi
<kdubious> my boot.scr (boot.cmd) looks like this:
<kdubious> load mmc 0:1 0x42000000 boot/uImage
<kdubious> no / before boot
<kdubious> oneinsect: maybe you need to get rid of the initial /
kdubious has quit [Client Quit]
<oneinsect> oho
<oneinsect> i am not using boot.scr
<oneinsect> just trying to see if it can work with extlinux
<oneinsect> yes let me try your idea
cnxsoft has quit [Ping timeout: 246 seconds]
<oneinsect> reading boot/vmlinuz-4.6.0-rc1-sunxi 5732576 bytes read in 383 ms (14.3 MiB/s)
<oneinsect> let me try loading it
<oneinsect> bootm 0x42000000 Wrong Image Format for bootm command ERROR: can't get kernel image!
<oneinsect> strange
<NiteHawk> oneinsect: with a zImage, use "bootz" instead
<oneinsect> trying
<oneinsect> Kernel image @ 0x42000000 [ 0x000000 - 0x5778e0 ] Starting kernel ... Uncompressing Linux... done, booting the kernel. Error: unrecognized/unsupported machine ID (r1 = 0x000 ffferf
<oneinsect> nanopi m1 has a different machine id?
<NiteHawk> no, that should be provided by u-boot and is soc-specific (so H3 in your case) - not sure what's wrong there
<NiteHawk> is that an up-to-date u-boot?
<oneinsect> U-Boot 2016.03-armbian (Apr 08 2016 - 01:09:18 +0530) Allwinner Technology
<NiteHawk> hmmm
<oneinsect> it was for Orange pi pc ...i am trying it out on nanopi m1
<NiteHawk> i'm not sure if that would affect it
<oneinsect> strange
<NiteHawk> what's the exact r1 value? the one you posted above looks very wrong
<oneinsect> but it gets struck there...doesnt go beyond
<oneinsect> may be i can set the machine id
<oneinsect> followed by bootm_boot_mode=sec
<oneinsect> NiteHawk: can you tell if this is correct
<oneinsect> machid 1029
apritzel has quit [Ping timeout: 244 seconds]
<oneinsect> okie this seems to work
<oneinsect> setenv machid orangepi-pc
<oneinsect> however
<oneinsect> Kernel image @ 0x42000000 [ 0x000000 - 0x5778e0 ] resetting ...
<oneinsect> its resetting
<NiteHawk> oneinsect: i'm not familiar with H3, as i don't own that hardware. been looking into u-boot source and am puzzled that include/configs/sun8i.h doesnt seems to specify a CONFIG_MACH_TYPE
<oneinsect> hmmm
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
<oneinsect> NiteHawk: is boot.scr still required
<oneinsect> even if the extlinux.conf
<oneinsect> is present
<oneinsect> strangely u-boot is not picking up /boot/vmlinuz-4.6.0-rc1-sunxi even after i changed the directories
<oneinsect> in extlinux.conf
<NiteHawk> i'm not sure. afaik boot.scr is still "the u-boot way" of doing things. it depends on configuration of the environment vars if and when extlinux.conf will be considered
<NiteHawk> if there a chance that you might have been loading the wrong kernel (a 3.4.x one?) that could explain the "unrecognized/unsupported machine ID"
<oneinsect> no i am loading a 4.6 RC1
<oneinsect> got it fresh of my vmware compilation
<oneinsect> i mean i solved the unrecognized ID
<oneinsect> i set the environment variable to setenv machid orangepi-pc
<oneinsect> so it loads the kernel but seems to immediately reset it
<oneinsect> if i do all that manually
<NiteHawk> which may easily indicate a wrong machid?
<oneinsect> hmmm
<oneinsect> correct
<oneinsect> you could be correct
<oneinsect> what to do
<oneinsect> i am anway setting the machine id to emulate an orange pi pc
<oneinsect> why cant it just take it from there
<oneinsect> nanopi m1 is almost same as orange pi pc
<oneinsect> okie it is now booting
<oneinsect> successfully
<oneinsect> upto a point where it cant find
<oneinsect> the rootfs
<oneinsect> one quick question
<NiteHawk> gz. what did you change to achieve that?
<oneinsect> yes this is what i did
<oneinsect> setenv machid 1029
<oneinsect> setenv bootargs root=/dev/mmcblk0p2 rootwait panic=10
<oneinsect> load mmc 0:1 0x43000000 sun8i-h3-orangepi-pc || load mmc 0:1 0x43000000 boot/dtbs/sun8i-h3-orangepi-pc.dtb
<oneinsect> load mmc 0:1 0x42000000 vmlinuz-4.6.0-rc1-sunxi || load mmc 0:1 0x42000000 boot/vmlinuz-4.6.0-rc1-sunxi
<oneinsect> bootz 0x42000000 - 0x43000000
<oneinsect> i could the line bootm_boot_mode=sec
<oneinsect> and see what it does
<oneinsect> also
<oneinsect> whats the option to set uInitrd
tkaiser has joined #linux-sunxi
<oneinsect> NiteHawk: any ideas
Netlynx has joined #linux-sunxi
<oneinsect> tkaiser: thanks seems u-boot mainline is working fine
<oneinsect> and it is seeing /boot/extlinux/extlinux.conf
<oneinsect> however it is not picking up the options from there
<oneinsect> any ideas why?
<tkaiser> oneinsect: Maybe, won't read the whole stuff, this is an image that works so maybe comparing what's different between your and the working approach helps.
<oneinsect> i downloaded it form
<oneinsect> from
<oneinsect> is the mirror same as yours?
<tkaiser> oneinsect: The Armbian build system is prepared to create Linux images of any kind. There's a customize functionality you can use to wipe out the rootfs and replace it with anything you want as last step
<oneinsect> indeed i read about it
<tkaiser> Nope, that's not identical. My builds are more recent but it's the same build system.
<NiteHawk> normally you don't want "bootm_boot_mode=sec" with a 4.x kernel. and if you load an initrd, it's address would be the second parameter to bootz, so e.g. instead of "bootz 0x42000000 - 0x43000000" you'd have "bootz 0x42000000 ${ramdisk_addr_r} 0x43000000"
<oneinsect> aha
<tkaiser> oneinsect: Load the image, let it boot, record serial console output and use this as a step by step tutorial
heffer has quit [Read error: Connection reset by peer]
<oneinsect> my problem has been the u-boot mainline simply refuses to load /boot/vmlinuz-4.6.0-rc1-sunxi when enabled in the /boot/extlinux/extlinux.conf
heffer has joined #linux-sunxi
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
<oneinsect> LABEL Linux Mailine 4.6RC2
<oneinsect> LINUX boot/vmlinuz-4.6.0-rc1-sunxi
<oneinsect> INITRD boot/uinitrd
<oneinsect> FDT boot/sun8i-h3-orangepi-pc.dtb
<oneinsect> APPEND BOOT_IMAGE=/boot/vmlinuz-4.6.0-rc1-sunxi modules=loop,squashfs,sd-mod,usb-storage console=${console}
<oneinsect> it is supposed to work
<oneinsect> wonder whats wrong
<oneinsect> NiteHawk: quick question with what do i replace this setenv bootargs root=/dev/mmcblk0p2 rootwait panic=10 ..... my root is a vfat
<oneinsect> i mean i dont have rootfs ext4.... just fat partition
<oneinsect> i am gonna write a wiki tutorial after i succesfully do this...man we should have more tutorials...will help newbies like us a lot
<NiteHawk> there's nothing fs-specific (rootfstype=...) to those bootargs, so as long as your kernel supports vfat (compiled-in, not a module!) and partition #2 is of suitable type it should work
<NiteHawk> check the kernel output on the serial console. in case of a rootfs panic, it should list the partitions that it detected
bwarff_ has joined #linux-sunxi
<oneinsect> alrite
<oneinsect> and when you say
<oneinsect> bootz 0x42000000 ${ramdisk_addr_r} 0x43000000
<oneinsect> do i have load it some place?
<oneinsect> the ramdisk?
bwarff has quit [Ping timeout: 240 seconds]
<oneinsect> got it
<NiteHawk> yes, of course. u-boot should provide a 'boilerplate' adress for that in ${ramdisk_addr_r} (check "pr ramdisk_addr_r"), so you probably want "load mmc 0:1 ${ramdisk_addr_r} myinitrd"
<oneinsect> okie almost nearing
<oneinsect> Target filesystem doesn't have requested /sbin/init...
<oneinsect> Begin: Running /scripts/local-bottom ... done.
<oneinsect> Begin: Running /scripts/init-bottom ... mount: No such file or directory
<oneinsect> No init found. Try passing init= bootarg.
<NiteHawk> btw: vfat for the rootfs might be less than optimal. i could imagine you'd run into some issues with file permissions and/or (symbolic) links
<oneinsect> i know
<oneinsect> mmcblk0: mmc0:aaaa SL08G 7.40 GiB...it does recognize it
<oneinsect> just need to pass the right
<NiteHawk> it might work, as long as you're aware/careful about the pitfalls involved
<oneinsect> the files are there in /apks/armhf/ folder ....how do i tell it to look there
<oneinsect> setenv bootargs root=/apks/armhf rootwait panic=10
<oneinsect> would do?
<oneinsect> let me try
<oneinsect> Rebooting automatically due to panic= boot argument...
<oneinsect> wonder what should we give for the bootargs
<NiteHawk> you mean the "top" of your root filesystem is in a vfat subfolder? i doubt that will work properly
<NiteHawk> you should relocate it to the vfat root. other files present on the vfat partition might go into suitable folders, e.g. "boot", "data", ...
<NiteHawk> root= takes a partition, never a "logical" filesystem entry
<oneinsect> alrite
<oneinsect> yes its a vfat subfolder
<oneinsect> let me try a logical partition
vishnup has quit [Quit: Connection closed for inactivity]
apritzel has joined #linux-sunxi
arossdotme has quit [Ping timeout: 260 seconds]
arossdotme has joined #linux-sunxi
mossroy has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
bwarff_ has quit [Quit: Leaving]
apritzel has joined #linux-sunxi
<oneinsect> any tutorial on how to make rootfs load into memory and keep itself in read only mode?
cnxsoft has joined #linux-sunxi
mossroy has quit [Quit: Quitte]
reinforce has joined #linux-sunxi
<NiteHawk> oneinsect: you mean an initramfs? i think that's r/w by default. maybe a "ro" kernel parameter will work, or try "mount -o remount,ro ..."
tomboy65 has quit [Ping timeout: 276 seconds]
<oneinsect> i was trying to load alpine linux initramfs with vmlinuz-4.6.0-rc1-sunxi but
<oneinsect> Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid...that is what u-boot says ...when i ask it to load initramfs
<oneinsect> NiteHawk: is initramfs specific to a particular kernel and does u-boot accept only a certain kind of initramfs ?
tomboy65 has joined #linux-sunxi
<camh> oneinsect: google for [uboot mkimage "-T ramdisk"]
<oneinsect> i got mkimage -n 'Ramdisk Image' -A arm -O linux -T ramdisk -C gzip -d initramfs.cpio.gz initramfs.uImage
<oneinsect> however i was told initramfs-grsec is already a gzipped cpio
<camh> that looks right
<camh> but you'll need to add the uboot header to it - hence mkimage
<NiteHawk> oneinsect: nevertheless you need to "wrap" it with mkimage
<oneinsect> so initramfs-grsec is supposed to load...(scratching my head...wonder why u-boot complains).....ooooh
<oneinsect> is it
<oneinsect> got it
<oneinsect> let me try
tomboy65 has quit [Ping timeout: 248 seconds]
apritzel has quit [Read error: Connection reset by peer]
tomboy65 has joined #linux-sunxi
<oneinsect> what does this signify
<oneinsect> -d initramfs.cpio.gz initramfs.uImage
<NiteHawk> the -d is a gzip option (decompress), i think your example tries to unpack the .gz before passing it to mkimage. however, to my knowledge that's not required
<NiteHawk> ah, no sorry - my bad
<NiteHawk> forget that. just check "mkimage" without options for help / a list of options
<NiteHawk> try: mkimage -n 'Ramdisk Image' -A arm -O linux -T ramdisk -d initramfs.cpio.gz initramfs.uImage
tomboy65 has quit [Ping timeout: 246 seconds]
<NiteHawk> (if that fails, maybe "-C none" will work)
tomboy65 has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 260 seconds]
apritzel has joined #linux-sunxi
jernej has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
<oneinsect> let me try
oneinsect has quit [Ping timeout: 250 seconds]
tomboy64 has quit [Ping timeout: 250 seconds]
megi has joined #linux-sunxi
bwarff has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
oneinsect_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
<oneinsect_> load address and entry point are 000000
<oneinsect_> is that okie?
<NiteHawk> for the ramdisk? yes, you're not gonna "execute" it ;)
<oneinsect_> hmmm
<oneinsect_> let me try now
<oneinsect_> still same problem
<oneinsect_> Wrong Ramdisk Image Format
<oneinsect_> Ramdisk image is corrupt or invalid
<NiteHawk> what file(name) did you start with?
<oneinsect_> okie seems initramfs was built using mkinitfs initramfs
<oneinsect_> sorry mkinitfs utility
<oneinsect_> can it used for mkimage
<oneinsect_> well this is what i did
<oneinsect_> mkimage -n initramfs-grsec -A arm -O linux -T ramdisk -C none -d initramfs-grsec vmlinuz-4.6.0-rc1-sunix
<oneinsect_> is that wrong?
<NiteHawk> show the output of "file initramfs-grsec"
<oneinsect_> gzip compressed data, from unix, max compression
cosm_ has joined #linux-sunxi
<NiteHawk> that's fine. now do "gzip -dc initramfs-grsec | file -"
<oneinsect_> i found something strange
<oneinsect_> file vmlinuz-4.6.0-rc1-sunix shows
<oneinsect_> u-boot legacy uImage, initramfs-grsec, Linux/Arm, RAMDisk Image (not compressed)
<oneinsect_> did i by mistakenly change vmlinux file?
<NiteHawk> you have selected that as the output name of mkimage, so you replaced it with the initrd uImage - probably not what was intended?
<oneinsect_> darn
<oneinsect_> must be
<oneinsect_> mkimage -n initramfs-grsec -A arm -O linux -T ramdisk -C none -d initramfs-grsec initramfs-grsec
<oneinsect_> so that be the right one?
<NiteHawk> no!
<NiteHawk> you'd be overwriting the original
<NiteHawk> mkimage -n initramfs-grsec -A arm -O linux -T ramdisk -C none -d initramfs-grsec initramfs-grsec.uImage
apritzel has quit [Ping timeout: 244 seconds]
kivutar has quit [Ping timeout: 276 seconds]
<oneinsect_> got it
<oneinsect_> i will try once i come back
<oneinsect_> be back in a while
<oneinsect_> thanks NiteHawk: for everything
<oneinsect_> i hope to finish this and write
kivutar has joined #linux-sunxi
<oneinsect_> a tutorial
cnxsoft has quit [Quit: cnxsoft]
Andy-D has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Changing host]
JohnDoe_71Rus has joined #linux-sunxi
uwe_ has quit [Ping timeout: 260 seconds]
apritzel has joined #linux-sunxi
avph has quit [Ping timeout: 246 seconds]
fredy has quit [Excess Flood]
avph has joined #linux-sunxi
fredy has joined #linux-sunxi
uwe_ has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
apritzel has quit [Ping timeout: 244 seconds]
kaspter1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
apritzel has joined #linux-sunxi
jernej has quit [Quit: Konversation terminated!]
jernej_ has joined #linux-sunxi
jernej_ is now known as jernej
apritzel has quit [Ping timeout: 244 seconds]
mossroy has joined #linux-sunxi
vagrantc has joined #linux-sunxi
mossroy has quit [Read error: Connection reset by peer]
vagrantc has quit [Quit: leaving]
vagrantc has joined #linux-sunxi
JohnDoe7 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 276 seconds]
vagrantc has quit [Quit: leaving]
<ssvb> 9 hours left until the qualification round of https://code.google.com/codejam is over :-)
<adj__> ssvb, what's codejam?
<ssvb> adj__: a kind of programming competition, solving simple and not so much algorithmic puzzles
<jelle> nice
* ssvb is an amateur, participating just for fun
<ssvb> jelle: you can still sign up if you are interested, it is not difficult to get the required 30 points to qualify
orly_owl has quit [Ping timeout: 252 seconds]
<jelle> ssvb: yeah already busy at a debian meetup :-)
<adj__> ssvb, you are a pro!
vagrantc has joined #linux-sunxi
<ssvb> adj__: there are kids who are training day and night for this kind of competitions, and I'm clearly not one of them
IgorPec has joined #linux-sunxi
<oneinsect_> NiteHawk: can i kiss you
<oneinsect_> atleast now alpine is booting
apritzel has joined #linux-sunxi
<oneinsect_> ofcourse with some error ERROR: modloop failed to start
<oneinsect_> i had passed the following arguments setenv bootargs modules=loop,squashfs,sd-mod,usb-storage
<oneinsect_> may be i cannot find the modloop file
olerem has joined #linux-sunxi
<oneinsect_> modloop-grsec contains some directory modules
<oneinsect_> in which there a dir called 4.1.20-0-grsec
<oneinsect_> and some firmware
<oneinsect_> folder
<oneinsect_> may be i need to generate modloop for vmlinuz-4.6.0-rc1-sunxi
<megi> hey, if anyone is interested in testing mainline kernel dts configuration for passive cooling of h3 based boards with fixed voltage regulator, here's info on how to modify your dts file: https://github.com/megous/linux/wiki/Fixed-voltage-regulator-test
<megi> I was able to test it on orange pi one, when treating it as if it had a fixed voltage regulator and it was limiting temperature to ~75°C while running openssl speed -multi 4
olerem has quit [Ping timeout: 248 seconds]
<oneinsect_> megi: will these make it to mainline?
apritzel has quit [Ping timeout: 244 seconds]
orly_owl has joined #linux-sunxi
afaerber has joined #linux-sunxi
<megi> hopefully
<megi> THS patches are not originally mine, I just cleaned them up a bit, I can ask the author about what he wants to do with them, if he still wants to mainline them himself
<jelle> DTS file for the orange pi one was posted today I think
p1u3sch1 has quit [Ping timeout: 276 seconds]
<megi> If not I would try, they already had one round of review
p1u3sch1 has joined #linux-sunxi
olerem has joined #linux-sunxi
<oneinsect_> hmm
<megi> oneinsect_: I sent him email, so we'll see
<oneinsect_> great
<oneinsect_> [thumbs up]
<lvrp16> ssvb: thanks that was a quick fun test
<ssvb> lvrp16: cool, what is your nick there?
<oneinsect_> megi: does the above dts also work with nanopi m1
<oneinsect_> it has a horrible fixed voltage regulator
<oneinsect_> board is almost same as orange pi pc
<megi> yes, it should work on it, I meant it for this board
<megi> does it use 1.3V all the time?
valkyr1e has quit [Quit: Bye.]
<megi> I tested it on orange pi one, because it is similar (it has switchable 1.1V/1.3V voltage regulation options for CPU), but I didn't enable the switching for the test
<megi> oneinsect_: do you have nanopi m1? did you try mainline kernel on it?
<oneinsect_> yess it uses 1.3V all the time...within just 5 minutes it started climbing upto 80 degrees and above
<oneinsect_> without any load
<oneinsect_> i have nanopi m1
<oneinsect_> i did try mainline u-boot and kernel with it
<oneinsect_> heating is the major issue
<oneinsect_> infact without the heatsink the heat seems to spread across all the components including the usb connectors, rj-45, hdmi etc
<oneinsect_> so i have shut it off
<oneinsect_> at that moment
<oneinsect_> other it works fine
<megi> oneinsect_: that's somewhat strange, because u-boot sets 408MHz CPU frequency which mainline kernel should not touch later, I think
<oneinsect_> well i shows me an error
valkyr1e has joined #linux-sunxi
<oneinsect_> Failed to set core voltage! Can't set CPU frequency
<megi> oneinsect_: I mean the overheating you experienced on mainline
<oneinsect_> U-Boot 2016.03-armbian (Apr 08 2016 - 01:09:18 +0530) Allwinner Technology
<oneinsect_> *** Warning - bad CRC, using default environment
<oneinsect_> yes
<oneinsect_> i use orange pi pc dts
<oneinsect_> rather
<oneinsect_> sun8i-h3-orangepi-pc.dtb
<oneinsect_> you see i use armbian and it still doesnt have nanopi m1 dtb ...no nanopi m1 target yet
<oneinsect_> although the fex file is there i dont use it
<oneinsect_> i only use u-boot with extlinux.conf file
<ssvb> megi: it's 1008MHz
<megi> Failed to set core voltage! Can't set CPU frequency this is because u-boot tries to set voltage on your board like it would on pc, which fails, so it bails out on setting frequency to 1008MHz
<oneinsect_> hmmmm
<megi> ssvb: it would be if it would be able to set the voltage
<oneinsect_> you will need a monster size heatsinks
<oneinsect_> to contain the damage
<megi> ssvb: ant this fails, thus the message on the serial console https://github.com/megous/u-boot/blob/master/board/sunxi/board.c#L538
<ssvb> megi: ok
<megi> oneinsect_: that sucks
<megi> oneinsect_: I'm not sure what voltage my opi one used while running the test, so perhaps it doesn't cool so well passively on 1.3V/408MHz
<willmore> megi, heatsink on your Opi1?
<megi> I just measured that default is 1.3V, so it was that
<megi> willmore: no heatsink, almost nothing fits :D
<megi> opi pc is much better for heatsinks
<megi> more space
vagrantc has quit [Ping timeout: 268 seconds]
<willmore> lvrp16, has a nice heatsink for the Opi1. Same size as the SoC.
<willmore> Even does some good when you have a little airflow. :)
<willmore> Nothing like the C2's heatsink. That thing is great.
<ssvb> willmore: is there a problem if the heatsink is bigger than the SoC?
<megi> I have some on my way from china too..., but opi pc can take 4x4cm heatsink, beacuse there's nothing sticking above the soc on that board
<willmore> ssvb, there is an XTAL that it could run into and some other bits a little farther away.
<megi> opi pc is much easier to cool
<ssvb> willmore: ok, just on the opi pc and the pine64 there is nothing tall sticking out around the SoC
<willmore> Nice. Not a lot of room on the Opi1 :)
<ssvb> opi pc is almost a perfect board
<willmore> Does it have a nice programmable regulator?
<megi> I agree!
<ssvb> yes
<willmore> The Opi1 at least has the dual voltage. That's nicer than the fixed ones at least.
<megi> i think it shows in the number of orders on aliexpress, opi pc is way ahead of anything else xulong does
<megi> oneinsect_: did you try to measure the CPU voltage, to verify it's 1.3V?
libv has quit [Ping timeout: 240 seconds]
libv has joined #linux-sunxi
<oneinsect_> hmm no
<oneinsect_> but i can
<oneinsect_> or i can quickly look at the published schematics
<megi> hopefully there are testpoints on the board for that
<oneinsect_> let me
<megi> H3 on opi one with 1.3V and default frequency set by u-boot doesn't heat that much as you described
<megi> it stays around 45-50°C with ambient temperature around 25°C
<oneinsect_> megi: MP2143DJ 1.32V/3A goes directly to VCC-CPUX
<oneinsect_> they are using it in a fix voltage fashion i guess
<oneinsect_> here is the schematic
<oneinsect_> refer to page 2
<oneinsect_> rather page 3 megi:
<megi> yeah, but it's not a fixed voltage regulator, so it depends on how precise the resistor divider is on your board
<oneinsect_> correct
premoboss has joined #linux-sunxi
<megi> oneinsect_: are you sure that the temperature rose while idle? I have my opione connected to ampermeter and no matter what frequency I set the current draw doesn't change while idle
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
<oneinsect_> well i have tested it on nanopi m1 with the following nanopi-m1-debian-sd4g.img got from their own site
<oneinsect_> and i use the following to measure tempature
<megi> I also found out that only frequency that doesn't push passively cooled H3 above 75°C on 1.3V under full load is 240MHz
<megi> I run it under full load for a few minutes
<oneinsect_> cat /sys/class/thermal/thermal_zone0/temp
<oneinsect_> and kept rising
<oneinsect_> physically i could feel the usb connectors etc also getting hot
<oneinsect_> i can use a fluke meter
<oneinsect_> and test
<oneinsect_> later tomorrow?
<megi> I run: it's openssl speed -multi 4 rsa4096 in a loop
<ssvb> megi: ok, I'll try to measure it too
<oneinsect_> "no matter what frequency I set the current draw doesn't change while idle"
<oneinsect_> are you sure megi: ?
<megi> yes
<megi> it stays at 400mA
<oneinsect_> that is strange
<ssvb> megi: 400mA is way too much
<ssvb> megi: normal idle current draw is around 200-250mA
<megi> I have USB dongle connected
<oneinsect_> its only 2 watts right?
<megi> it's just a baseline
<ssvb> megi: oh, that explains it :-)
<oneinsect_> i will test it with meter tomorrow
<oneinsect_> may be becoz of the regulator?
<ssvb> oneinsect_: http://linux-sunxi.org/Cpufreq#The_.22performance.22_governor
<ssvb> oneinsect_: clock gating and stuff
<megi> on full load I measured: 500mA 240MHz/1.3V 64°C / 580mA 480MHz/1.3V 75°C
<oneinsect_> oooh yes
<megi> the second measurement was thorttling
<megi> so it would probably heat up even more
premoboss has quit [Quit: Sto andando via]
<megi> so the only sensible frequency for passive cooling is 240Mhz
<megi> if you have to live with 1.3V, that is
<megi> oneinsect_: you may try editing the file in u-boot that sets the cpu frequency and change it from 408000000 to 240000000, it may help even without any other patches to the kernel
<oneinsect_> oooh
<oneinsect_> thanks
<megi> np :)
<oneinsect_> i will download it and compile it tomorrow
<oneinsect_> was just watching H - Human Target - Season 1 Episode 9 - Corner Man
<oneinsect_> loved 24 ...and person of interest
<oneinsect_> i wish they renew them
<ssvb> megi: just checked it, the openssl current draw is around +380mA, and the cpuburn-a7 current draw is around +570mA
<megi> wow, that's quite a diff
<megi> did you use -mulit 4 ?
<megi> multi
<ssvb> yes, of course, the command line that you have provided
<megi> I'll try the cpuburn :)
<ssvb> but there may be differences in the openssl version, its configuration, etc.
<lvrp16> ssvb: my finding factors function wasn't quick enough :( i forgot to test the large scenario before
<lvrp16> beforehand*
<lvrp16> couldn't generate the output BLAH
<lvrp16> took 10 minutes to run on my laptop lol...i only had 8 minutes
<lvrp16> damn it should have gotten an i7.... lol
<lvrp16> be funny if i ran it on a sbc
VargaD has quit [Ping timeout: 244 seconds]
<megi> ssvb: it eats slightly more, 540mA and heats up to 73°C at 240MHz, so 240MHz may still be safe for passive cooling at 1.3V
<megi> with openss it ate 500mA
<megi> 73°C is not that much
<ssvb> megi: hmm, that's good to know, looks like you have a more power hungry openssl than mine
VargaD has joined #linux-sunxi
<megi> did you fix frequency to some value?
<megi> maybe it's just the frequency difference
<megi> 240Mhz is pretty low and it's below what I've found in fex files
<ssvb> I'm just looking at the cpuburn vs. openssl numbers (your and mine)
<megi> ok :)
<megi> the lowest freq in fex file is 480MHz, and u-boot runs by default on 408MHz, so i'm pusshing it pretty low - there's not much difference between load and idle on 240MHz anyway
<ssvb> the CPU can run at the low clock speeds just fine, and A10 had 60MHz as the lowest clock frequency in FEX
<oneinsect_> megi: is audio working in console (without gui) has anyone tested it?
<oneinsect_> does it needs to have any specific drivers?
<megi> ok
<ssvb> having the lowest clock frequency set not too low helps to make the desktop more responsive
apritzel has joined #linux-sunxi
<ssvb> when used with the ondemand governor
<megi> oneinsect_: yes, it works with 3.4 kernel
<oneinsect_> hmmm
<megi> I've made an audio player for my gf, with opi pc :D
<ssvb> megi: about the current draw, was it in fact +140mA for cpuburn-a7 vs. +100mA for openssl when running at 240MHz (relative to your 400mA idle current draw)?
<megi> yes
<ssvb> oh, then this makes sense
<ssvb> my numbers were measured for running at 1.3GHz, so +570mA / +380mA is roughly the same as +140mA / +100mA
<megi> ok
<ssvb> lvrp16: yeah, I had the same problem last year (18 minutes for the large set, exceeding the 8 minutes limit)
<lvrp16> it was stupidity on my part
<lvrp16> they even gave me the test set
<lvrp16> i just didn't both to test it, i was doing increment and % to find prime factors
<lvrp16> bother*
<oneinsect_> megi: i wanted to do the same albiet for my kid... just wanted to know if its mainline yet
<oneinsect_> mgp123 works well in mainline
<megi> it's not in mainline
<oneinsect_> (sad)
<megi> but people are working on it according to this: http://linux-sunxi.org/Linux_mainlining_effort
kdubious has joined #linux-sunxi
<oneinsect_> may be i could try how x264 encoder
<oneinsect_> works
<oneinsect_> encoding from usb webcam (mjpg)
<kdubious> wens: did you mean MDI-0 or MDI-O
<kdubious> from what I can tell looking at the KICAD files, there is a pull up resistor on the MDIO line
<kdubious> currently, if I put a 560 OHm resistor in between a 3.3v pin and the UART-1 Rx, I'm getting consistent network functionality on boot
<kdubious> is there some signal, immediately after power connect, that turns on the Eth chips?
apritzel has quit [Ping timeout: 244 seconds]
mosterta has joined #linux-sunxi
<lennyraposo> hey longsleep
<lennyraposo> I started up a make shift Bug Report for the pine on the forum
vagrantc has joined #linux-sunxi
zuikis has left #linux-sunxi [#linux-sunxi]
<kdubious> lennyraposo: who is an "expert" on the eth chip or the power-up process?
<lennyraposo> not me mate
<lennyraposo> I am still learning
olerem has quit [Ping timeout: 260 seconds]
<willmore> lvrp16, finding factors?
<kdubious> willmore: on one of the boards + SOM combos, 560 Ohms works 100% of the time
<kdubious> but on the others (I have 3 here)... no luck
<kdubious> one gets an IP, but then network traffic is flaky
<kdubious> starting to think this product is just not the right fit
JohnDoe7 has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
jernej has quit [Quit: Konversation terminated!]
<lvrp16> willmore: the codejam
kdubious has quit [Ping timeout: 250 seconds]
alain__ has joined #linux-sunxi
alain__ has left #linux-sunxi [#linux-sunxi]
apritzel has joined #linux-sunxi
oneinsect_ has quit [Ping timeout: 250 seconds]
iamfrankenstein has joined #linux-sunxi
<willmore> lvrp16, ahh, okay. factoring numbers? How big of numbers?
lerc has quit [Read error: Connection reset by peer]
lerc has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
mosterta has quit [Ping timeout: 276 seconds]
nieuwbie has joined #linux-sunxi
<nieuwbie> hey I'm just checking inet - 3f and that number in MHZ is a dram clock, right?
kdubious has joined #linux-sunxi
kdubious has quit [Client Quit]
reinforce has quit [Quit: Leaving.]