<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
<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>
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.
<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
<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
<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/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>
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 -"
<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_>
*** 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
<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
<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_>
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