<cosm>
because it passes a NULL pointer, and then this is dereferencing it without checking if != NULL
<cosm>
and since ehci-sunxi is built by default (at least with the orangepi config) and ehci_usb_probe is called when u-boot starts up, it just gets stuck in a reset loop
<cosm>
ehci_register is called by ehci-sunxi from line 65 in drivers/usb/host/ehci-sunxi.c
<tkaiser>
The Pine64 people refuse to collect the scathered informations in one place and also spread wrong information on their own. So pretty useless to answer the same questions again and again, isn't it?
<ssvb>
and it can have references to all the important information or additional wiki pages
ricardocrudo has joined #linux-sunxi
<ssvb>
Allwinner based boards have a lot of similarities, so scattering the information all over the Internet on many http://some-random-board.com sites does not make much sense :-)
<ssvb>
lennyraposo: what about the mali binary install?
<ssvb>
in fact, I'm curious if the allwinners BSP has the suitable mali blobs for gnu/linux
<ssvb>
if yes, then we can get something up and running in a reasonable timeframe
<ssvb>
and the buffers management (ump, dma-buf, ion, cma and a bunch of other buzzwords) kept changing over time, but that's just a minor annoyance because the basic principles are all the same
<lennyraposo>
what am I looking for?
<ssvb>
the mali-something files with the .so extension :-)
<lennyraposo>
they have lichee kernel 3.10 and 3.4 sources
<oliv3r>
hey; i have to catch up on my sunxi-ism; but what is required to run the latest 4.6 kernel in sense of the axp209; right now my kernel just hangs after axp init. I recall running into this a while ago, and I think it was related to u-boot having to set certain ldo's
<lennyraposo>
in module smore than likely
<plaes>
lime2?
<plaes>
oliv3r: ^^
<NiteHawk>
oliv3r: yes, likely related to the regulator nodes in DT. iirc there were quite a few changes related to axp209 recently
<oliv3r>
plaes: yeah :)
<oliv3r>
plaes: well it's a secret lime2 :p but the axp part is defualt
<topi`>
I'm trying to hook up a SHARP memory display (an Adafruit module)... anyone give a hint how to connect the CS (chip select) pin? the rest are easy, like SPICLK and MOSI
<plaes>
michael haas had some patches
<topi`>
since Banana PI uses the older RPI gpio layout (26pin), the guide I found out for RPI2 is not valid, right?
<topi`>
it says to connect the CS to a pin (27) that does not exist on BPi
<lennyraposo>
searching for mali
<oliv3r>
NiteHawk: but what was the quick fix :) i'll check my branch logs :)
<lennyraposo>
looks like they have something here
<lennyraposo>
narrowing it down
<NiteHawk>
oliv3r: no (immediate) idea, sorry - i'm still behind on mainline kernel, only got around to updating to current u-boot recently (which had issues on it's own with the ehci-hcd breakage :P)
paulk-collins has joined #linux-sunxi
<lennyraposo>
found it I think
<lennyraposo>
even a nice little readme to go with it
<lennyraposo>
Building the Mali Device Driver for Linux
<plaes>
oliv3r: search the list for Michael Haas and lime2
<tkaiser>
lennyraposo: That's the kernel part, isn't it?
apritzel1 has joined #linux-sunxi
<tkaiser>
ssvb: Agreed, but I've been talking about different stuff. The many reasons why the Pine64 backers spend hours to get the thing booting the first time.
<tkaiser>
ssvb: There exist a couple of reasons all well known in the meantime. But the Pine64 people seem to don't like the idea providing a quickstart guide to their users
<plaes>
oliv3r: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS
<ssvb>
tkaiser: add a linux-sunxi wiki page link to your forum signature, sooner or later they will know where to find the information and will help each other :-)
<oliv3r>
i think i saw/did a patch also to set the correct values in u-boot directly
<oliv3r>
plaes: but this works
libv_ is now known as libv
mane has joined #linux-sunxi
<ssvb>
tkaiser: just give them some slack
<oliv3r>
btw, are you guys aware of the lime2 + gbit ethernet problems?
<tkaiser>
lennyraposo: That's the kernel part, ssvb was talking about the other one ;)
<plaes>
oliv3r: those are fixed in u-boot
<NiteHawk>
topi`: you sure it's CON6 P27, not 24 or 26? the latter would seem more natural, as thore are SPI0_CS0 and SPI0_CS1 - and they are available on BPi's 26-pin connector (CON3) too
<oliv3r>
plaes: well not 'fixed' :p work around :)
<oliv3r>
plaes: your board now is always forced in master mode
<plaes>
I don't actually have lime2 :(
<ssvb>
tkaiser: also a few advanced users will learn the basic tricks and will help the others, right now is just a rough start when everyone got his board and did not have much time to play with it yet :-)
<ssvb>
tkaiser: if the pine64 people are actively making troubleshooting more difficult, then it's their choice and their problem
HeavyMetal has quit [Ping timeout: 268 seconds]
<ssvb>
tkaiser: there will be other a64 hardware too (from olimex and maybe xunlong)
<tkaiser>
oliv3r: Maybe the Lime2 hardware rev. E is the 'fix'? There they replaced NAND with eMMC and maybe the PHY
<lennyraposo>
mali.ko
<lennyraposo>
that owuld be kernel nm
<tkaiser>
ssvb: I know, but it's a bit sad to see all the poor people suffering from the same problems. But agreed, not my problem :)
<oliv3r>
tkaiser: i have a few rev D and rev E's here and no, it does not fix this
<oliv3r>
tkaiser: the proper fix is to replace the PHY :)
<tkaiser>
oliv3r: Yes, I thought that might have changed with rev E. Thx for confirmation that it's not :(
<oliv3r>
tkaiser: with rev D and E they changed the mdio traces a bit to make them 'more' balanced or something which improves performance
<tkaiser>
lennyraposo: 's/ko/so/'
<oliv3r>
or rather, reduces packet loss
<lennyraposo>
found 2 ko
<oliv3r>
but it doesn't fix the master/slave issue
<lennyraposo>
and 1 o
<tkaiser>
oliv3r: Sad, since I really like the Lime2. But when used with mainline kernel I had 40KB/s in one direction (well, just 1000 times slower than with 3.4)
<oliv3r>
yeha but there is a u-boot 'hack' that fixes it
engidea-vr has joined #linux-sunxi
engideavr has quit [Ping timeout: 248 seconds]
<lennyraposo>
what am I saying here
<lennyraposo>
it's the mali.ko
<lennyraposo>
they ave it in the output folder
<tkaiser>
lennyraposo: It's still about .so
apritzel1 has quit [Ping timeout: 244 seconds]
Andy-D has quit [Ping timeout: 248 seconds]
<lennyraposo>
no .so file found
vpeter has joined #linux-sunxi
<lennyraposo>
so that basically tells me they didn't pack the binary at all with this so called BSP
ddc has joined #linux-sunxi
<tkaiser>
lennyraposo: If you want to waste a few hours go to Orange Pi forums and read through the whole story. At some point in time, Steven sent some folks the mali.so blob via email (version 4.0.0). And then a few OS images have been made by community members that used this.
<tkaiser>
lennyraposo: AFAIK you get these blobs if you get a DDK from ARM ('you' is not Lenny but Allwinner instead)
<tkaiser>
lennyraposo: Googling for 'arm ddk mali' might help
<lennyraposo>
I am reading it now actually
<tkaiser>
lennyraposo: And afterwards off to Guangdong to get mali.so? ;)
<lennyraposo>
just reading arm's site info about the DDK
<tkaiser>
lvrp16: I used ssvb's cpuburn-a7 together with SinoVoip's defaults to get all cores killed but one and then started the test. Next test is with Armbian and 'corekeeper' service that brings back CPU cores, then with heatsink and then heatsink+fan
<ssvb>
tkaiser: btw, this corekeeper stuff probably belongs to the kernel
<tkaiser>
ssvb: ?
<ssvb>
littering the userland with various hacks and tools is IMHO not the right way to go
<ssvb>
somebody just needs to fix the damn kernel
<tkaiser>
ssvb: And who's this somebody? :) (I lack the skills)
<tkaiser>
ssvb: The 'right way to go' is to drop this 3.4 thingie anyway...
apritzel1 has joined #linux-sunxi
<ssvb>
tkaiser: exactly
Nyuutwo has quit [Quit: No Ping reply in 180 seconds.]
<tkaiser>
plaes: Yes, ugly hack but works and prevents Michael Larabel (Phoronix) from measuring crap as usual
<tkaiser>
LOL, and right this moment when running the phoronix stuff on BPi M2+ without heatsink it happened: kernel:[12862.186922] thermal_sys: Critical temperature reached(0 C),shutting down
<plaes>
haha
<plaes>
moronix
olerem_ has joined #linux-sunxi
<tkaiser>
Nice, SinoVoip cloned the M2+ very carefully. With jernej's RGMII settings for GMAC on OrangePi Plus I get exactly the same 461 Mbits/sec on BPi M2+ like him on OPi Plus
<tkaiser>
Kernel 4.6.0-rc1 using wens' h3-emac branch + jernej's patches
olerem_ has quit [Ping timeout: 260 seconds]
<mane>
tkaiser: does that mean that pine64 could run kernel 4.6.0-rc1?
<mane>
sorry for hat silly question but I'm quite new to these things
<mane>
*that
<tkaiser>
mane: I was talking about H3 but A64 can also run mainline kernel. Have a look in the wiki please
<tkaiser>
montjoie: With these patches a bidirectional iperf3 run results in 461 Mbits/sec in both directions and using the older iperf (version 2) you can kill reliably network :)
<tkaiser>
plaes: I do know not that much about it, only that Martin started working on it a while ago and that I've been responsible for him rebasing his patches multiple times :\
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<plaes>
um.. it's i2c
<tkaiser>
plaes: True, but he got SPI also working (4.4 IIRC)
<tkaiser>
plaes: But I might be wrong
<plaes>
if only he had submitted those patches... :)
IgorPec has joined #linux-sunxi
Turl has quit [Remote host closed the connection]
Turl has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 260 seconds]
libv_ has quit [Ping timeout: 244 seconds]
libv has joined #linux-sunxi
ddc has quit [Ping timeout: 250 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
tomboy64 has quit [Ping timeout: 276 seconds]
Amit_T has joined #linux-sunxi
libv has joined #linux-sunxi
<Amit_T>
Hello: Default boot order of organe pi one is from flash or I have to prepare SD card for it?
cnxsoft has quit [Quit: cnxsoft]
* apritzel
tries to get the association to "organ pie" out of my head
libv_ has quit [Ping timeout: 244 seconds]
tomboy64 has joined #linux-sunxi
libv has quit [Ping timeout: 246 seconds]
libv has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
<apritzel>
Amit_t: Isn't it that the Orange Pi One does not have eMMC flash at all?
<Amit_T>
apritzel: oh Thanks but how do I confirm it?
<Amit_T>
I just try to boot it without using sd card and serial interface I just see ?????
<Amit_T>
Yes I got your point , I was thinking It was same like cubietrack
<Amit_T>
ok sure
bwarff has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
IgorPec has quit [Ping timeout: 276 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 264 seconds]
libv_ has quit [Ping timeout: 246 seconds]
libv has joined #linux-sunxi
vagrantc has joined #linux-sunxi
bwarff has quit [Ping timeout: 276 seconds]
PietreLinux has joined #linux-sunxi
oneinsect_ has joined #linux-sunxi
<oneinsect_>
friends any tutorial on how enable fel mode usb boot on allwinner h3 board
<apritzel>
which one?
<oneinsect_>
nanopi m1
<oneinsect_>
its similar to orange pi one
<oneinsect_>
with 512 MB ram
<apritzel>
oneinsect_: for boards without eMMC it's usually having no uSD card in the slot
<oneinsect_>
sorry for being a noob...meaning?
<oneinsect_>
they dont have a sdcard slot you mean?
<apritzel>
no, if the board does not find an uSD card, it goes into FEL mode
<apritzel>
or more generally: if none of the checked storage options works, it goes into FEL mode
<oneinsect_>
okie so once in FEL mode
<oneinsect_>
can it boot from USB?
<oneinsect_>
assuming i flash a usb with bootloader, script.bin etc
avph has quit [Ping timeout: 246 seconds]
<apritzel>
yes, FEL mode means it uses the USB OTG port to listen for commands from a host (PC)
cosm_ has joined #linux-sunxi
lennyraposo has quit [Ping timeout: 264 seconds]
<oneinsect_>
hmmm
<tkaiser>
oneinsect_: you can boot through FEL but have to think about where your rootfs then will be (NFS for example, which requires approriate kernel settings and so on)
<oneinsect_>
i want it to be on the usb itself
<apritzel>
oneinsect_: so you mean an USB mass storage device like a USB pendrive?
zuikis has joined #linux-sunxi
<oneinsect_>
yesss
<oneinsect_>
correct
<oneinsect_>
is it possible apritzel:
Andy-D has joined #linux-sunxi
<apritzel>
well, you cannot load the boot loader from an USB stick, I think
<oneinsect_>
hmmm
<oneinsect_>
only from a microsd card i guess then
avph has joined #linux-sunxi
<apritzel>
so you can use the FEL mode (with another computer connected via USB) to get the boot loader, kernel & co loaded
<oneinsect_>
oooh
<oneinsect_>
understood
<apritzel>
from then on you can use any USB storage media for your rootfs
<tkaiser>
oneinsect_: You're still trying to avoid unreliable SD cards, true? If so wait a bit for Orange Pi PC Plus (Turbo Advanced Extreme...)
jernej_ has joined #linux-sunxi
jernej_ has quit [Client Quit]
<oneinsect_>
yes tkaiser:
jernej has joined #linux-sunxi
<oneinsect_>
i badly want to run linux in live like puppylinux
<oneinsect_>
i managed to compile uImage, script.bin...i am trying to see how to connect it a live image
<apritzel>
so you could put the loader and kernel on a SD card, which will effectively never written to
<oneinsect_>
from armbian
<tkaiser>
oneinsect_: Then choose a board with eMMC (and one that does not overheats like NanoPi M1)
<apritzel>
and then run the rootfs from USB storage
<oneinsect_>
oooh
<oneinsect_>
Nanopi M1 is overheating
<oneinsect_>
in just a few minutes even without load it started climbing
<oneinsect_>
i noticed that
<jernej>
tkaiser: Why did you revert wens changes on ethernet driver? Because my patch didn't apply or ethernet didn't work on opi+?
<tkaiser>
oneinsect_: That's due to the SoC always being fed with 1.3V, an idle OPi PC will reduce voltage.
<tkaiser>
jernei: Since I obviously made a mistake then?
<oneinsect_>
hmmm
avph has quit [Ping timeout: 246 seconds]
<oneinsect_>
tkaiser: are dtbs kernel and rootfs independent?
<oneinsect_>
is it possible for me ask u-boot to load kernel/rootfs from fat32 instead of ext4?
<tkaiser>
Sure, it's fatload then
<jernej>
tkaiser: I'm just curious. At the time I develop the patch, I didn't bother to update ethernet driver source. So I thought that you downgrade for a reason.
<tkaiser>
oneinsect_: And you don't want to even think about .dtb with H3 at the moment, especially with your board until thermal throttling in mainline kernel is working
<oneinsect_>
oooh
<tkaiser>
jernej: Simply a mistake made by me. I got lost in patches today
<oneinsect_>
how do i go about then? any advise
avph has joined #linux-sunxi
<tkaiser>
oneinsect_: You can use Armbian build system, adjust it to let a FAT partition being created and then replace the rootfs with whatever you want
JohnDoe_71Rus has joined #linux-sunxi
<oneinsect_>
adjust it to let a fat partition being created?
lennyraposo has joined #linux-sunxi
<oneinsect_>
dont hate me...but I am trying to make sense of what to do to achieve
<tkaiser>
Then you get 2 partitions, the 1st being FAT and the second ext4 (maybe btrfs/f2fs as well but you don't want to use these with kernel 3.4)
<oneinsect_>
well cant it just one big FAT partition?
avph has quit [Ping timeout: 246 seconds]
IgorPec has joined #linux-sunxi
<tkaiser>
oneinsect_: You can change the scripts to whatever you like, but I won't spend time on this. Think about apritzel's idea to use a read-only bootloader on SD card and everything else on USB storage
<apritzel>
22 MB/sec on 1M block size? Indeed not bad.
<tkaiser>
apritzel: That's where SDIO is the bottleneck (same with Pine64). I was more talking about random I/O
<tkaiser>
apritzel: And a crappy no-name card has been 385 times slower than any of the EVOs I tested (16K random writes)
<apritzel>
yeah, that's what I was thinking: I suppose it's easier to find decent USB drives than decent SD cards
<tkaiser>
apritzel: I tried 3 thumb drives and they were magnitudes slower than the quality SD cards when testing random I/O
<apritzel>
really?
reinforce has joined #linux-sunxi
<apritzel>
I heard people preferring USB drives over SD cards on the RPi a few years back
<tkaiser>
apritzel: Yes. And one of them a counterfeit stick (16 GB real capacity instead of 32)
<apritzel>
but this could be due to the RPi SD interface as well
<tkaiser>
apritzel: IMO random I/O is way more important when using storage with a SBC and cards with high IOPS were rather expensive a few years back.
Gerwin_J has quit [Ping timeout: 244 seconds]
<tkaiser>
apritzel: That was one of the reasons I bought the 4 Samsung cards. To get an idea what you get today. And when the SDIO implementation is the real bottleneck regarding sequential transfer speeds then the cheap EVOs outperform even the more expensive Samsung Pro.
<tkaiser>
Would be interesting how Transcend and SanDisk cards perform. But I have no need for more cards at the moment
<topi`>
odd. I just downloaded the newest Armbian for BPi, 5.04 it seems, but it tries to boot via PXE and gets nowhere (no ethernet :)
<topi`>
but /boot is populated with vmlinuz and friends, how do I force it to boot from mmc?
<topi`>
it seems u-boot is quite new, march 2016
<topi`>
it *does* seem to support MMC, since I can do "ext4ls mmc 0 boot"
<topi`>
*** Warning - MMC init failed, using default environment
<topi`>
hmmm??
<topi`>
maybe this is too bleeding edge :) I'll look for an older image
edolnx has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 246 seconds]
<apritzel>
topi`: I think you can ignore the warning, it's about the U-boot environment only
mane has quit []
<apritzel>
if ext4ls works, you should be able to use ext4load as well
olerem_ has joined #linux-sunxi
<topi`>
I was able to boot with "run mmc_boot"
<topi`>
however, after loading kernel, nothing came up in serial. And the green led stopped blinking
<topi`>
so some serious issue with the kernel
Netlynx has joined #linux-sunxi
<topi`>
it seems I have to run manually "run mmc_boot" every time...
<tkaiser>
topi`: Or some serious issues with the hardware (SD card)?
<topi`>
I'll try another card
<NiteHawk>
topi`: then probably the device enumeration / boot target selection by distro_bootcmd is effed up. try setting (reducing) the available targets in the "boot_targets" env var
<topi`>
I hate this prolific PL2303 driver on OSX, it crashes my Yosemite, if I leave minicom open and unplug the usb-uart cable
<topi`>
NiteHawk: setenv && saveenv ?
JohnDoe5 has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
<topi`>
switched to a new SD card, now it boots automatically
jemk_ has quit [Ping timeout: 260 seconds]
<topi`>
strange effects... the SD card "almost" worked, but somehow not autodetected
<tkaiser>
topi`: Never ever use any flash based storage without testing before.
<topi`>
:)
JohnDoe_71Rus has quit [Ping timeout: 268 seconds]
<tkaiser>
topi` How does this look like: defaults read /System/Library/Extensions/ProlificUsbSerial.kext/Contents/Info
<Amit_T>
What are minimum images needs to write on SD card in order to bring u-boot on orangepie(I was trying booting with only u-boot.spl compiled for a20 based soc)
<topi`>
I think osx kernel drivers are botched by default, because they are written in C++ ;)
<tkaiser>
topi`: I use "ProlificUsbSerial v1.5.0, Copyright 2013 Prolific Technology Inc." -- worth a try
<Amit_T>
Actually I have only 1 Mb of internet bandwidh remaining with me and on my machine I have few prebuilt u-boot images are there(Built for a20)
<Amit_T>
so can't download any orange pi firmware images
<Amit_T>
NiteHawk: Thanks but we don't need any other image apart from what you suggested to boot and reach to u-boot prompt ?
<oneinsect_>
tkaiser:
<oneinsect_>
can armbian support
<oneinsect_>
nano pi m1
<Amit_T>
even this 167kb is taking so much time to download :(
<NiteHawk>
Amit_t: nope - that .bin file contains both SPL and the main u-boot binary and should get you to the prompt
libv has joined #linux-sunxi
massi has quit [Quit: Leaving]
<NiteHawk>
btw: i've deliberately pick one from early januar since after that some sunxi gmac weirdness was around for a while, and it unfortunately seems to affect release v2016.03 too
<Amit_T>
ok but isn't it one image from this tar u-boot-sunxi-with-spl.bin enough to reach to u-boot ?
<tkaiser>
oneinsect_: A H3 board that feeds the SoC constantly with 1.3V is nothing I want. $30 according to their CEO. We'll see.
libv_ has joined #linux-sunxi
<NiteHawk>
Amit_t: it is. i didn't disagree with that? i'd expect/assume you know how to extract the tar.xz ...
<oneinsect_>
hmmm
<Amit_T>
Yes I already extracted it
olerem_ has quit [Ping timeout: 248 seconds]
<tkaiser>
oneinsect_: What's wrong with Orange Pi PC?
libv has quit [Ping timeout: 264 seconds]
<oneinsect_>
i dont have it
<oneinsect_>
there is nothin wrong
<oneinsect_>
i would love to have it
<oneinsect_>
unfortunately without thinking further
<oneinsect_>
or enquiring further
<oneinsect_>
i purchased
IgorPec has joined #linux-sunxi
<oneinsect_>
nanopi m1
enrico_ has quit [Quit: Bye]
<oneinsect_>
there was nobody to guide me
<willmore>
tkaiser, that M2+ looks horrible.
<tkaiser>
willmore: Please keep in mind that the other results provided by lvrp16 were with active cooling.
<tkaiser>
willmore: Won't repeat it once more since the Moronix Test Suite really sucks.
<tkaiser>
But it's obvious that the 1.3V render throttling somewhat useless and with ssvb's cpuburn-a7 even when adjusting maximum cpufreq to 504MHz I was able to get all CPU cores killed but one. No thanks
<willmore>
tkaiser, LOL, yeah. These SoCs shipping on boards with no HS is a joke. And they require active cooling to run at full clocks and all cores.
<willmore>
What was the temp on that one core at 504?
<tkaiser>
willmore: Don't know, but it exceeded the 'start to kill CPU cores' treshold after a ~15 seconds. No need to further investigate since the decision is easy.
<tkaiser>
Unfortunately they did only send the board and not the camera module (OV5460). That would've been interesting whether the camera works. With Banana Pi no one got more than 640x480 pixel out of OV5460 so I would suspect it will be the same here. And then OPi PC or Plus are still the winners
libv has joined #linux-sunxi
<ssvb>
tkaiser: then the lowest cpu frequency needs to be reduced even more
<oneinsect_>
why isnt nanopi m1 listed on the menu that asks for user to select the board?
<willmore>
tkaiser, I was just curious to see if it could even keep one core running at that voltage without critically overheating.
<oneinsect_>
while starting to compile
pmattern has joined #linux-sunxi
<tkaiser>
ssvb: I allowed it to decrease down to 240MHz and won't spend any more time on this board (just testing GbE to help montjoie, wens et al.)
<ssvb>
at 600mhz the temperature still kept growing above 100C when running cpuburn-a53
libv_ has quit [Ping timeout: 244 seconds]
<tkaiser>
ssvb: Yeah, I changed it to 240-1200MHz
<willmore>
ssvb, is that for the Pi3?
<willmore>
Oh, sorry, context, yes it was.
<tkaiser>
oneinsect_: We only differentiate between 2 sorts of H3 boards: GbE capable or fast Ethernet, therefore choose either orangepiplus or orangepih3.
<ssvb>
tkaiser: yes, 240mhz seems to be reasonable, nobody is going to normally stress the board that much, but it's best to be prepared just in case :-)
<oneinsect_>
aha
<oneinsect_>
got it
<tkaiser>
And then you have to relink script.bin to nanopim1.bin
<willmore>
I'd be willing to do power measurements on a Opi1 at various clocks. What do I need to change to get the cpu freq lowered like that?
<tkaiser>
ssvb: But with SinoVoip settings and without heatsink even the boring PTS stuff managed to downclock the M2+ to 648MHz most of the times. And this isn't that demanding
<oneinsect_>
fex to bin using sunix tools
<tkaiser>
So my conclusion: Stay away from any H3 device with fixed VDD_CPUX
khuey|away is now known as khuey
<oneinsect_>
what if you could have proper heatsinks?
<tkaiser>
oneinsect_: After image creation it's /boot/bin/nanopim1.bin
<oneinsect_>
even if i select KERNEL_ONLY to yes?
<tkaiser>
oneinsect_: Nope / I don't know. Use fex2bin then. And keep in mind that thermal settings needs adjustment (have a look at bananapim2plus.fex)
<oneinsect_>
i wish i had gone to some board that was supported by mainline
<NiteHawk>
Amit_t: 1. you do not need any partitioning for this. it's safest not to do any filesystem formatting (mkfs.ext2 or similar) either
<oneinsect_>
guys what does FORCE_USE_RAMDISK=yes mean?
<NiteHawk>
Amit_t: 2. you do realize that ${card} is a placeholder and needs to be replaced by the actual device name in use? (depends on your host system where you write the image with dd)
<willmore>
Nice to see work on 4.6 progressing so well for the H3. :)
cosm_ has quit [Quit: Leaving]
<NiteHawk>
Amit_t: retry the dd command, don't touch anything else (no partitioning, no mkfs). normally you should at least get some output from the SPL (initializing clock/dram) after a reset
<Amit_T>
All I can see is ???? characters on serial console
<NiteHawk>
Amit_t: if that fails, you might still try an alternative: usb boot of u-boot via http://linux-sunxi.org/FEL
<NiteHawk>
are you sure you setup the serial parameters correctly? (baudrate etc.)
PietreLinux has quit [Quit: Page closed]
<Amit_T>
And when I remove the power these char just go on
<Amit_T>
yes
<Amit_T>
115200 and /dev/ttyUSB0 using it from gtkterm
<NiteHawk>
you should detach the serial to power down properly. current leaking from the uart is a common design flaw for these boards, and might keep the device in a "semi-working" state
<Amit_T>
Nitehawk: there is no power connection and these char are still going on
<Amit_T>
ok
<Amit_T>
I will do it now
<NiteHawk>
i'll have to leave in a short while. if you still fail at getting some sensible output, i'd suggest you first get an orange pi image that's known to work, copy it to your sd and check that the device boots. that should give you some serial output too, so you can at least assure that your (uart) setup is working. from there on you could start experimenting on your own
<NiteHawk>
(i'll check back later to see if you made any progress)
<lennyraposo>
was digging around for the mali binary in the BSP package and didnt' spot anything. Did Allwinner package it? If not I will ask tllim about it
mossroy has joined #linux-sunxi
libv has joined #linux-sunxi
nove has joined #linux-sunxi
libv_ has quit [Ping timeout: 260 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
Amit_T has quit [Quit: Page closed]
jernej has joined #linux-sunxi
tkaiser has joined #linux-sunxi
oneinsect_ has quit [Quit: Page closed]
avph has joined #linux-sunxi
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 264 seconds]
<apritzel>
lennyraposo: haven't looked, but I guess they don't ship it in the BSP
<apritzel>
and since they don't provide a real Linux image, I wouldn't expect to find it somewhere else
matthias_bgg has quit [Ping timeout: 276 seconds]
<apritzel>
(in the Pine64 provided images, that is)
libv has quit [Ping timeout: 260 seconds]
libv has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
libv has quit [Ping timeout: 244 seconds]
<lennyraposo>
yep
<lennyraposo>
you are right
<lennyraposo>
tllim is addressing that next week
<lennyraposo>
fingers crossed
<lennyraposo>
also
<lennyraposo>
figured out what is buggering the bloody audio for the Pine64
<lennyraposo>
the audio offset in output needs to be great than 0.00 ms. Its interesting as when I apply the offset in pavucontrol and keep the window open Audio plays beautifully for hours on end (wathced a lot of youtube and played stuff from my mp3 library) with no issues
<lennyraposo>
even 1.00 ms is good
<lennyraposo>
her eis the silly issue
<lennyraposo>
the moment the window is closed for pavucontrol (grr pulseaudio) audio goes to crap once again. Don't know why the settings are not being used once changes are made. Strange n'est pas?
libv has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 264 seconds]
libv_ has quit [Ping timeout: 248 seconds]
libv has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
zuikis has left #linux-sunxi [#linux-sunxi]
iamfrankenstein has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
IgorPec has quit [Ping timeout: 240 seconds]
iamfrankenstein has joined #linux-sunxi
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 246 seconds]
libv_ has joined #linux-sunxi
<tkaiser>
longsleep: For your helpdesk job: dd as present in OS X needs small letters for block size (bs=10m instead of bs=10M) and you were right, /dev/rdiskX speeds up things a lot
<tkaiser>
longsleep: And may I ask one more time for SanDisk Extreme Plus performance numbers :)
libv has quit [Ping timeout: 276 seconds]
pmattern has quit [Quit: Genug für heute.]
libv_ has quit [Ping timeout: 244 seconds]
libv has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
<willmore>
lennyraposo, you editing the linux-sunxi wiki?
libv_ has joined #linux-sunxi
<lennyraposo>
not yet
<lennyraposo>
I am working on comprehensive tutorials at the moment
<lennyraposo>
got a nice reply from tllim about allwinner meeting next week
libv has quit [Ping timeout: 244 seconds]
<willmore>
Okay, I was going to mention that there is an issue where video resolutions are being treated as email addresses and being redacted. Sort of makes the video decode hardware pages less useful. :(
cosm has quit [Read error: Connection reset by peer]
cosm has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 264 seconds]
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 244 seconds]
scream has quit [Remote host closed the connection]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 244 seconds]
<willmore>
tkaiser, I just did a simple test on four ARM SBCs. Pi2B, Pi1B+, Opi1, and a C2. Each has the same model of samsung 16GB EVO card (the pi1 has the full sized SD version).
<willmore>
They all get the same sequential read speed--except for the C2. :) So, your point about being faster than the slow speed uSD interface is a waste of performance.
<willmore>
23MB/s for three and then 35MB/s for the C2.