<habs>
NiteHawk: Thanks for the suggestion. OK, so if I start from 0x4a100000 that gives me "write 0x4A100000 zImage" "write 0x55100000 sun8i-a33-sinlinx-sina33.dtb" and "write 0x43100000 boot.scr" I think? And a bootz of "bootz 0x4A100000 - 0x43100000" ?
<habs>
The only thing I'm not sure about is whether I should also shift the boot.scr location, or if that should stay as I left it?
<apritzel>
habs: why are you embedding the initrd in the first place?
<apritzel>
habs: can't you just load it via a separate write command and just reference the address as the second parameter in the bootz command?
<apritzel>
that's the usual way of doing it, I don't see any advantage of embedding the initrd if your bootloader is capable of handling initrds
jstein has quit [Remote host closed the connection]
ErwinH has joined #linux-sunxi
The_Loko has quit [Quit: Leaving]
<habs>
apritzel: Thanks, I agree, but I'm just not sure how to do that. How can I remove the size of the initrd from the zImage and just use the one generated by mkinitrd? Or do I have to recompile the kernel to do that?
LargePrime has quit [Ping timeout: 248 seconds]
LargePrime has joined #linux-sunxi
<habs>
and is there some memory map available, so I can know where to write the initrd and what to put in the bootz command?
perr has joined #linux-sunxi
ErwinH has quit [Ping timeout: 256 seconds]
popolon has quit [Quit: WeeChat 1.4]
<apritzel>
a sane U-Boot config comes with proper predefined values: $kernel_addr_r, $ramdisk_addr_r, $fdt_addr_r
<apritzel>
so the bootz command is pretty generic: bootz $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
<apritzel>
habs: doesn't Debian have some tool to generate a (foreign) initrd archive?
<apritzel>
just from the top of my head I would do: (cd /path/to/rootfs; find ./ | cpio --create -H newc --make-directories | gzip -c9) > initrd.gz
TheLinuxB is now known as TheLinuxBug
<apritzel>
scratch that --make-directories, that's only for extracting
<apritzel>
habs: if you don't need a special initrd, I usually pick some installer initrd, for instance from Debian
perr has quit [Ping timeout: 264 seconds]
perr has joined #linux-sunxi
leio has quit [Read error: Connection reset by peer]
leio has joined #linux-sunxi
KotCzarny has quit [Ping timeout: 258 seconds]
mhlavink has quit [Ping timeout: 256 seconds]
perr has quit [Ping timeout: 272 seconds]
jbrown has quit [Ping timeout: 246 seconds]
perr has joined #linux-sunxi
perr has quit [Changing host]
perr has joined #linux-sunxi
mzki has quit [Ping timeout: 246 seconds]
mzki has joined #linux-sunxi
jbrown has joined #linux-sunxi
interrobangd has quit [Ping timeout: 246 seconds]
Ntemis has quit [Remote host closed the connection]
dave0x6d has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
interrobangd has joined #linux-sunxi
apritzel has quit [Ping timeout: 272 seconds]
mzki has quit [Quit: leaving]
mzki has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 256 seconds]
Andy-D has joined #linux-sunxi
ninolein has quit [Ping timeout: 258 seconds]
ninolein has joined #linux-sunxi
ErwinH has joined #linux-sunxi
jbrown has quit [Ping timeout: 246 seconds]
ErwinH has quit [Ping timeout: 258 seconds]
ErwinH has joined #linux-sunxi
interrobangd has quit [Read error: Connection reset by peer]
ErwinH has quit [Ping timeout: 246 seconds]
ssvb has joined #linux-sunxi
jbrown has joined #linux-sunxi
KotCzarny has joined #linux-sunxi
victhor has quit [Ping timeout: 252 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 246 seconds]
leio has quit [*.net *.split]
cptG_ has quit [*.net *.split]
KotCzarny has quit [*.net *.split]
ssvb has quit [*.net *.split]
cnxsoft has quit [*.net *.split]
leio has joined #linux-sunxi
cptG_ has joined #linux-sunxi
KotCzarny has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
ssvb has joined #linux-sunxi
a|3x has quit [Remote host closed the connection]
a|3x has joined #linux-sunxi
dave0x6d has quit [Quit: Connection closed for inactivity]
chomwitt has quit [Read error: Connection reset by peer]
pg12 has quit [Ping timeout: 256 seconds]
pg12 has joined #linux-sunxi
<habs>
apritzel: Sorry, but I just have so many questions --
<habs>
How can I get the values of these u-boot environment variables, so I can use them in my sunxi-fel command?
<habs>
I'm guessing $kernel_addr_r corresponds to zImage, $ramdisk_addr_r to initrd, and $fdt_addr_r to sun8i-a33-sinlinx-sina33.dtb? but then where does the boot.scr go?
perr has quit [Ping timeout: 264 seconds]
perr has joined #linux-sunxi
<habs>
This is my current sunxi-fel command then, but I'm not sure a) how to get the u-boot env variables, and b) where boot.scr should go (it's 5 lines): http://sprunge.us/DIAM
<habs>
When I run this it finally flashes successfully and I get a uboot prompt, but even if I try "bootz ${kernel_addr_r} 0x4A100000:${filesize} ${fdt_addr_r}" manually from there I just get no output and no sign of linux :-( :-(
<habs>
So what have I done wrong, and what can I do to fix it? Note that my only interface (besides FEL mode) with this NESmini is serial, so I need for the I/O to Linux to be over serial.
scream has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<plaes>
habs: enable early printk
<plaes>
to see where it breaks
<plaes>
um... Nintendo_NES_Classic_Edition_defconfig vs sun8i-a33-sinlinx-sina33.dtb ??
<habs>
plaes: I thought I already enabled early printk by doing "setenv bootargs console=ttyS0,115200 loglevel=8 earlyprintk panic=10"? Or is that something I also need to do in the kernel config and recompile?
<plaes>
yes, you need to enable low-level debugging in kernel
<habs>
plaes: OK, going by wiki/Mainline_Kernel_Howto right now, do I want "Kernel low-level debugging messages via sun9i UART0" or should I change that to "Kernel low-level debugging messages via sunXi UART0" because it's similar to to the sun8i-a33-sinlinx-sina33?
scream has quit [Remote host closed the connection]
jbrown has quit [Ping timeout: 260 seconds]
<plaes>
dunno
<plaes>
I haven't actually played with A33/R16 yet :(
<habs>
plaes: So I get this output on serial when after flashing via the sunxi-fel command: http://sprunge.us/SDXc
IgorPec has joined #linux-sunxi
<habs>
What does this indicate needs to be fixed? And how can I do that?
<ElBarto>
habs: why do you want to use a uboot script ?
<ElBarto>
habs: can't you use bootm/bootz directly ?
<habs>
ElBarto: It doesn't matter, even if I enter the text of my kernel script manually I just get no output?
<habs>
ElBarto: As a reminder here are the commands I've run up to this point: http://sprunge.us/eUhQ?sh
f0xx has joined #linux-sunxi
<ElBarto>
habs: mhm ok, others have suggested early_printk but I can't help you on that as I don't know much linux
<ElBarto>
habs: and btw there is a dts in the u-boot repo for the nes classic
<ElBarto>
but it's totally incomplete
<ElBarto>
I'll send a patch today or tomorow with stuff added
<habs>
ElBarto: That would be fantastic, thank you so much
<ElBarto>
does someone have a a33 device with nand and not the nes ?
<ElBarto>
I must have forgotten something when adding support to uboot because the controller doesn't seems to take the writes ...
<ElBarto>
or maybe it's different than a10/a20
a1d3s has joined #linux-sunxi
<habs>
OK so just tried with the other "Kernel low-level debugging messages via sunXi UART0" option, still same output and if I run "bootz 0x42000000 0x4A100000 0x43000000" from the uboot cmdline I get no output again :-( I'm going to rest on this one and try again tomorrow
<habs>
If anyone wants to take a look at this and see what could be wrong in the mean time, I am 100% all-ears: http://sprunge.us/aUWb?sh Good night all
<plaes>
habs: how did you create the boot.scr data?
<plaes>
it looks like the contents for that are invalid
<habs>
./tools/mkimage -C none -A arm -T script -d boot.cmd boot.scr
<habs>
and definitely will do, but until I get a working system I want to make sure what I am writing in the docs is correct first, haha
jbrown has quit [Ping timeout: 260 seconds]
<plaes>
and what's this: 0x4A100000 ?
<plaes>
on line 18?
<plaes>
try this instead: bootm 0x42000000 - 0x43000000
<plaes>
to get kernel booting
<habs>
plaes: 0x4A100000 is the location of my initrd.gz, I don't think I can just put a dash there because then uboot / the kernel would have no way of knowing how to load that?
<plaes>
but you currently don't manage to load even kernel?
<habs>
plaes: Yes, you make a good point so I'll try that tomorrow
<plaes>
read through the mainline u-boot page first
<plaes>
and then FEL/USBBoot
<habs>
OK, I'll read those pages again, thanks for the help
<plaes>
and point the guy on reddit to actually use linux-sunxi stuff ;)
<plaes>
s/stuff/wiki
<beeble>
without reading all of the backlog. for bringup i would just load the uimage and dtb by hand, set the bootargs and bootm
<beeble>
less things that can go wrong inbetween
jbrown has joined #linux-sunxi
maz has joined #linux-sunxi
ErwinH has quit [Read error: Connection reset by peer]
ErwinH has joined #linux-sunxi
areuready_ has joined #linux-sunxi
areuready_ has quit [Client Quit]
<plaes>
beeble: yup
leviathanch has quit [Remote host closed the connection]
leviathanch has joined #linux-sunxi
msevwork has joined #linux-sunxi
foxx has joined #linux-sunxi
florianH has joined #linux-sunxi
LargePrime has quit [Ping timeout: 260 seconds]
<plaes>
MoeIcenowy: cw1200 driver is 95% xradio
LargePrime has joined #linux-sunxi
popolon has joined #linux-sunxi
apritzel has joined #linux-sunxi
jbrown has quit [Ping timeout: 246 seconds]
<MoeIcenowy>
plaes: ok...
<MoeIcenowy>
maybe we can add xradio support to existing cw1200 driver?
DullTube has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
<plaes>
I actually did some work to see what's different
<plaes>
you can check the differences between cw1200 and this repo ^^
The_Loko has joined #linux-sunxi
<plaes>
there actually isn't much
<plaes>
some of the debugging stuff (manufacturing and calibration) has been removed from the mainline
jbrown has joined #linux-sunxi
lemonzest has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
Mr__Anderson has quit [Quit: Leaving.]
Mr__Anderson has joined #linux-sunxi
premoboss has joined #linux-sunxi
mhlavink has joined #linux-sunxi
kaspter has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 258 seconds]
popolon has quit [Quit: WeeChat 1.4]
paulk-collins has joined #linux-sunxi
jbrown has quit [Ping timeout: 246 seconds]
chomwitt has joined #linux-sunxi
scream has joined #linux-sunxi
jbrown has joined #linux-sunxi
tsuggs has quit [Quit: No Ping reply in 180 seconds.]
tsuggs has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
scream has quit [Remote host closed the connection]
paulk-collins has quit [Remote host closed the connection]
<plaes>
apritzel: o/
<plaes>
cw1200 driver in mainline is 95% xradio
Pepe has joined #linux-sunxi
_whitelogger_ has joined #linux-sunxi
Turl has joined #linux-sunxi
TheLinuxBug has joined #linux-sunxi
zerotri has joined #linux-sunxi
nihcas_ has joined #linux-sunxi
arnd has joined #linux-sunxi
yann-kaelig has joined #linux-sunxi
<NiteHawk>
plaes, habs: The address 0x4A100000 was chosen arbitrarily from the initial error message (http://sprunge.us/RXWV?l), which states that the loaded U-Boot ends at 0x4A05FB2F. Anything "above" that address should work. Note that this non-standard address is only required for the "oversize" kernel that would otherwise collide with other information loaded (U-Boot, DTB, boot script)
<beeble>
i should definitely read the full text, but just saying something is a lot easier :)
<beeble>
isn't u-boot reloacting itself at the end of DRAM. so loading something behind it should fail?
apritzel has quit [Ping timeout: 246 seconds]
<NiteHawk>
that offset is ~161MiB into memory, shouldn't be "at the end". I'm not entirely sure if U-Boot relocates itself on startup. nevertheless the first thing you need to do is to come up with a memory layout where the various pieces won't clash with each other. separating the ramdisk from the kernel should also help with that
reinforce has quit [Ping timeout: 256 seconds]
RIDDICC has joined #linux-sunxi
<beeble>
ok sunxi-common.h defines the load address for u-boot with 0x4a000000. but it will relocate itself. leaving a bit space for the framebuffer if video is defined.
<beeble>
but you are right. has nothing to do with that
foxx has quit [Quit: terminated!]
<MoeIcenowy>
oh... shit... systemd has raised its systemd version requirment to 3.12...
<RIDDICC>
hi! where can i find a DTS for my BPi M2+EDU, that enables the gigabit ethernet device (the sun8i-h3-bananapi-m2-plus.dts in u-boot's git does not help)?
<KotCzarny>
MoeIcenowy: that's good!
<KotCzarny>
:)
<MoeIcenowy>
allwinner's 3.10 died again ;-) :-(
<KotCzarny>
or systemd on allwinner's legacy kernels ;)
<MoeIcenowy>
oh I cannot use any emotion to describe my feeling
foxx has joined #linux-sunxi
<KotCzarny>
but i think allwinner will just release something newer for new socs
<KotCzarny>
(and ignore everything made before ;)
<jelle>
MoeIcenowy: died?
<beeble>
last time i checked android didn't use systemd. so they won't care at all :)
foxx has quit [Client Quit]
<KotCzarny>
that too
<KotCzarny>
yay!
<MoeIcenowy>
jelle: oh I mean "cannot survive"
<jelle>
MoeIcenowy: of course it can not :P
<MoeIcenowy>
it cannot survive the latest systemd
<NiteHawk>
They wouldn't care even *if* Android used systemd... X)
<jelle>
this is why we make it work on mainline ;-)
<MoeIcenowy>
there's a time when the 3.10 barely can survive systemd
<MoeIcenowy>
but not now.
<jelle>
oh you mean you can't use a new distro with an ancient kernel
<jelle>
sure
<KotCzarny>
you can, you just have to use something that was used for the last 10-30 years
foxx has joined #linux-sunxi
<KotCzarny>
jessie still allows for systemd removal
<jelle>
KotCzarny: but systemd is here to stay :)
<jelle>
also the problem is not systemd imo
<KotCzarny>
not in my house ;)
<MoeIcenowy>
jessie is not a new distro at all ;-)
jbrown has quit [Ping timeout: 260 seconds]
<KotCzarny>
details. ;)
<MoeIcenowy>
the standard of "new" to me is Arch ;-)
<RIDDICC>
*yawn* is there really no support for that thingy?
<MoeIcenowy>
although myself is a maintainer of a rolling distro ;-)
<MoeIcenowy>
a distro with less user than the sunxi images I provided ;-)
<MoeIcenowy>
of course our images use mainline ;-)
<KotCzarny>
those boards are 'dev' boards anyway, knowing things is required
<plaes>
:)
<RIDDICC>
and is there any chance that cpufreq will work for it again in ALARM? (i dont like to use a 3.4 kernel in public inet... *giggle*)
<plaes>
and then comes NES ;)
<KotCzarny>
and part of the knowing is 'use mainline if possible'
<MoeIcenowy>
but for A64 it still misses a display ;-)
<KotCzarny>
details. ;)
<jelle>
I know that the archlinux arm guys are against all sunxi sadly
<MoeIcenowy>
are you interested to get display working on A64?
<apritzel>
wens: it's definitely 256M x 16, and two of them on the Opi PC 2
<MoeIcenowy>
and have you read my AXP803-related U-Boot patch?
<apritzel>
MoeIcenowy: sure, why not?
msevwork has quit [Quit: Leaving]
reinforce has joined #linux-sunxi
<apritzel>
MoeIcenowy: I think you know my opinion on exposing the AXP to anything other than ATF ;-)
<MoeIcenowy>
;-)
<MoeIcenowy>
but it seems that we need more things to be initialized
<apritzel>
wens: I checked the data sheets, also all the boards I have here use the full 32 bits
<MoeIcenowy>
and the "poweroff" function currently will also only be available when U-Boot come with AXP support
<apritzel>
wens: so it's as easy as 32 / <number of chips>
<apritzel>
MoeIcenowy: wrong
<apritzel>
MoeIcenowy: recent U-Boot support using PSCI for reset and power off
<apritzel>
MoeIcenowy: as a PSCI user, that is
* jelle
wants to look into PSCI power off
<MoeIcenowy>
ok...
<MoeIcenowy>
but we need functions to enable more and more regulators...
<apritzel>
MoeIcenowy: we just need to enable power off in U-Boot
<apritzel>
MoeIcenowy: which ones?
<jelle>
apritzel: you make it sound easy
<apritzel>
jelle: it is: just enable it in some config
<montjoie>
anybody here with A10 A13 A31 A33 who can test something with sun4i-ss ?
<MoeIcenowy>
for example, DLDO1 for HDMI, DLDO4 for Wi-Fi (already done in ATF)
<MoeIcenowy>
montjoie: ?
<MoeIcenowy>
I have A10,13,33
<apritzel>
MoeIcenowy: I checked all regulators a while ago and came up with exactly those
<MoeIcenowy>
and I thinkALDO2 is more important
<apritzel>
MoeIcenowy: also I have some patches ready to use SCPI regulators
<ErwinH>
tkaiser: the stability of the soc using xhpl can be improved a bit more by checking the residual and comparing it to other tests. I get a consistent value of 0.0047983 when testing N=10240 and 0.0048903 when testing N=6000. Anything above that should be considered a fail, in my opinion.
<MoeIcenowy>
ALDO2 is VCC-PL
<apritzel>
MoeIcenowy: PortL should not be exposed in the first place
<MoeIcenowy>
yes
<MoeIcenowy>
but at least I think some PLx should be set for using Wi-Fi
leviathanch has quit [Remote host closed the connection]
valkyr1e has quit [Ping timeout: 248 seconds]
ErwinH has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
valkyr1e has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
ErwinH has quit [Ping timeout: 245 seconds]
IgorPec has quit [Ping timeout: 245 seconds]
tgaz has quit [Ping timeout: 272 seconds]
<plaes>
ssvb: o/
<plaes>
is there a way to run the uart0-helloworld-sdboot.sunxi using sunxi-fel?
ErwinH has joined #linux-sunxi
<ssvb>
plaes: yes, just run it as "sunxi-fel spl uart0-helloworld-sdboot.sunxi"
ErwinH has quit [Ping timeout: 245 seconds]
<plaes>
ah.. indeed
<plaes>
I thought it will continue to write that message
<plaes>
in a loop
|Jeroen| has quit [Quit: dada]
<plaes>
but thanks :)
foxx has quit [Ping timeout: 248 seconds]
<plaes>
woot.. nice
<plaes>
ssvb: thanks, u-boot on SPI works :)
popolon has joined #linux-sunxi
<willmore>
Yay!!!
<willmore>
My chips finally came in and now I need to solder one onto my zero.
<willmore>
And I ordered some smaller packaged 16MB ones as well. So, I can see how much I can stuff on there.
<KotCzarny>
solder a socket?
<KotCzarny>
how many write cycles do they survive?
deskwizard has quit [Ping timeout: 245 seconds]
<KotCzarny>
it might be last command that switches led color from red to greenish after all fs' are umounted/ro
<KotCzarny>
oops. wrong chan
<willmore>
KotCzarny, 100K or so. Should be fine unless we really pound on them.
apritzel has joined #linux-sunxi
tgaz has joined #linux-sunxi
yann-kaelig has quit [Quit: Leaving]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
<tuxillo>
hi fellas
<tuxillo>
I have received my orange pi zero :D
fire219 has joined #linux-sunxi
<premoboss>
tuxillo, did you alreadi test it?
<tuxillo>
i'm writing the image
<tuxillo>
opi0 can be powered just with a usb port right?
<premoboss>
i am curisou to know wifi range, if it can play as access point with hostapd
<tuxillo>
no clue
<TheLinuxBug>
um considering that most of those with built on have SDIO wifi
<TheLinuxBug>
range usually isn't much more than maybe 20-30ft?
<TheLinuxBug>
maybe if you have one with an antenna
<TheLinuxBug>
like the OPi's you get a bit better
<TheLinuxBug>
but if you want to use one for AP you would do better to buy a larger IPX antenna
<premoboss>
tuxillo, do you receive OPZ (OrangePi Zero) with or without antenna?
<premoboss>
i suppose you can power it just with ORG usb cable. OPZ run a H2 SoC, that is less energy drinker of energy compared to H3, and NPN (NanoPi NEO) run a H3 and it is powered with ORG usb cable.
<tuxillo>
it brings an anthena
<tuxillo>
Debian GNU/Linux 8 OrangePizero ttyS0
<tuxillo>
OrangePizero login:
<tuxillo>
yay!
<willmore>
tuxillo, 512MB one? With SPI NOR FLASH?
<tuxillo>
[ 0.000000] Memory: 512MB = 512MB total
<tuxillo>
no clue what spi nor flash is
<willmore>
tuxillo, on the bottom of the board is there an 8 pin chip right in the middle or just 8 empty pads.
<willmore>
Chip should say 25Q16
<TheLinuxBug>
premoboss: I think tkaiser proved with some adjustments to the fex you can get H3 to use about the same amount, H2 just has slower cores out of the box
<willmore>
I don't remember seeing that.
<TheLinuxBug>
He did some test with the NEO I remember
<TheLinuxBug>
trying to think if I still have that bookmarked
<tuxillo>
willmore: there is a chip but I can't see what's written
<willmore>
tuxillo, then you have it! pleas, you have another guinea pig!
<premoboss>
Tuxillo, SPI flash is a 8-foot little-black chip on rear side of board. most probably you will find only a empty space dedicated fore that chip .
Mr__Anderson has quit [Remote host closed the connection]
<willmore>
premoboss, the later shipping 512MB Zero's were supposed to be shipping with them.
<tuxillo>
but what is it?
<premoboss>
willmore, to you refere to antenna or to soldered SPI boot chip?
deskwizard has joined #linux-sunxi
<willmore>
tuxillo, it's a 2MB FLASH chip that the chip can boot from. The idea is to have a version of uboot that can fit in it that can USB or network boot.
<willmore>
premoboss, the SPI FLASH.
<premoboss>
tuxillo, boot spi chip is where uboot can be stored: in other words, it means you will not nned uSD to boot, boot can be done "in hardware".
<tuxillo>
oh
<willmore>
I don't know anything about different antenna options.
<tuxillo>
that is cool!
<willmore>
tuxillo, it's a WIP, but has been shown to work in principle.
<tuxillo>
and I guess you can write to it with sunxi-tools
<willmore>
yep
<tuxillo>
:)
<tuxillo>
pine64 has it too?
<premoboss>
unfortunately it ca nstore only uboot, not kernel and filesystwem to have a comprete "in hardware firmware".
<willmore>
The hope is that a board specific uboot and DTS can come *one the board* from the factory so a generic uSD or USB can work for multiple boards.
<willmore>
Yeah, uboot+kernel+root is just too big for little SPI chips.
<premoboss>
where is the good side to have only a 2MB flash compared to uSD?
<willmore>
Biggest I've seen is 128b (16MB). That doesn't leave much room for root.
<premoboss>
a well resized kernel + rootfs can be stored onto 16MB.
<tuxillo>
premoboss: I guess you can write your own small kernel for very specific purposes and fit it there :)
ErwinH has joined #linux-sunxi
<willmore>
Yeah, a very dedicated use case could fit on there.
<premoboss>
tuxillo, linux 4.x, even if resized, need more than 2.1MB (last time i recompiled it).
<willmore>
I mean, heck, my first Linux box had 4MB of memory and a 125MB HD, so it can be done.
<tuxillo>
if you compile your own kernel just with the basics I guess it can fit
<premoboss>
willmore, ypou talk about 1.3 linux?
<tuxillo>
I wonder why the load average is 3.00 all the time
<willmore>
premoboss, 0.14
gzamboni has quit [Ping timeout: 248 seconds]
<tuxillo>
something's spinning?
<premoboss>
willmore, OMG!
<premoboss>
tuxillo, run top to see what is running.
<willmore>
premoboss, grep for willmore in the kernel doc directory some day when you're bored.
<tuxillo>
top won't show such things where there are kernel stuff spinning in the background
<TheLinuxBug>
willmore: I haven't found the link to the forum post but 2016-08-01 he said "<tkaiser> But since we're at Armbian are preparing low power settings for the new H3 board (Nano Pi NEO and NanoPi Air) I want to ensure that we can get these H3 board as low as RPi Zero when it's about consumption "
xdanger has joined #linux-sunxi
nikre has joined #linux-sunxi
<premoboss>
tuxillo, so run ps aux
<TheLinuxBug>
and I know he was testing to get power consumption as los as possible
<TheLinuxBug>
low*
<premoboss>
willmore, how to do?
<willmore>
premoboss, look in the Documentation subdirectory of the Linux kernel source.
<premoboss>
ok
<premoboss>
o go to give a look now.
<willmore>
TheLinuxBug, was that his early work on the h3consumption program or whatever it ended up being called?
ErwinH has quit [Ping timeout: 240 seconds]
<willmore>
I think I was reading that the other day. Lots of testing of power consumption on Rpi and Opi boards with different settings for memory and clock?
<TheLinuxBug>
cause he was talking about how you can tune down h3
<premoboss>
how to greo a text onto a herd of files and subdirectories?
<nikre>
i'm trying have my es9023 i2s dac working on opi one. i can see it listed on aplay -l on legacy armbian but i get no sound out of it. can anyone help?
<willmore>
premoboss "find . -type f -print0|xargs -0 grep willmore"
<TheLinuxBug>
willmore: yeah saw that article while I was searching for the one I pasted, in the one I pasted he provides some more detail on turning down things for lowest power consumption on h3
<premoboss>
willmore, ok
<willmore>
TheLinuxBug, cool.
<TheLinuxBug>
willmore:
<TheLinuxBug>
"To sum it up: By simply tweaking software settings (most of them not even needing a reboot but accessible from user space) average idle consumption of an H3 device can be reduced from 1.5W (300mA) to almost the half. In this mode (one single CPU core active at 912MHz and DRAM downclocked to 408MHz) a H3 device is still faster than an RPi Zero while providing way more IO and network bandwidth. And if settings are chosen wisely performance can be increa
<willmore>
Nice.
<premoboss>
./drivers/ide/qd65xx.c: * More research on qd6580 being done by willmore@cig.mot.com (David)
<willmore>
I think some of those settings got incorporated into armbian because my OpiZ testing didn't show any useage above 200mA. I'd have to review to be sure.
<willmore>
premoboss, that would have been in the mid/late 90's.
<TheLinuxBug>
yeah that has been since July, so probably some of it has been incorporated into Armbian by now
<willmore>
Turns out it didn't Just had a CE signal for some latches so that a PIO PATA port could be added--for slow things like CDROMS.
<premoboss>
willmore, i start to linux late 1999 :-)
<premoboss>
you came forst
<premoboss>
first
<willmore>
Well, I'm out of practice, so it doesn't count for much.
<beeble>
willmore: grep -r willmore
<beeble>
willmore: no need for find :)
<premoboss>
tuxillo, how is going OPZ? your impression?
<beeble>
missing the . at the end...
<tuxillo>
premoboss: I'm trying to setup a wifi connection
<tuxillo>
I'm not that familiar with networkmanager crap
<premoboss>
beeble, not needed the "."
<beeble>
ah does recursive imply files?
<premoboss>
tuxillo, work directrly into /etvc/networl/interfaces
<premoboss>
beeble, yes
<premoboss>
-r is enough
<beeble>
good to know
<beeble>
could even suggest git grep since its propably a git tree
scream has quit [Remote host closed the connection]
<tuxillo>
sounds like some sort of propietary chip
<premoboss>
bad news.
<tuxillo>
I don't know the details
<premoboss>
lsusb -v (verbose debug)
<tuxillo>
yeah I know, I didn't see it there
<premoboss>
explore /sys
<tuxillo>
wifi is unusable
<premoboss>
tuxillo, range?
<tuxillo>
i'm almost over the router
ErwinH has joined #linux-sunxi
<tuxillo>
I think I'm going to try armbian
<premoboss>
what OS are you using now?
<tuxillo>
debian. i got it from orange pi web site
<premoboss>
linux version?
<tuxillo>
3.4.39
<premoboss>
drop it and move to armbian.
ErwinH has quit [Ping timeout: 258 seconds]
<tuxillo>
doing so yes
<premoboss>
btw, remember that OPZ is newest, support lacks.
<tuxillo>
what is lacking?
<premoboss>
in general, producerd does not refine thge softwar esupport, it is enough that "it works". so maybe unusability of wifi is due to poor software configuration/old driver.
<premoboss>
so you need to weit unstil armbian will give the rightr support to OPZ.
<tuxillo>
whatever it is, it is absolute crap as far as I tried
<premoboss>
anyway it could be (and i suspect to) tha t wifi is crap by itself and not so much cam be done on software side.
<premoboss>
i don some wireless som (1cm x 1cm). they was so crap that was enough one wall in the middl to make it blind to signal from access point.
<premoboss>
in tht case nothing can be done, hardware is crap. period.
<tuxillo>
me it's not booting wth
<premoboss>
anyway OPZ came for 7USD, so you get what you pay for.
<tuxillo>
meh
<premoboss>
did you get armbian for OPZ?
<tuxillo>
well yeah
<premoboss>
an dont boot at all? no u-boot message?
avph has quit [Ping timeout: 246 seconds]
<tuxillo>
there are u-boot messages for sure but it seems to fail to boot from the sd card
<tuxillo>
USB device 0: unknown device
<tuxillo>
BOOTP broadcast 2
<tuxillo>
BOOTP broadcast 1
<tuxillo>
...
<premoboss>
o-oh... is tryng to boot from network. no way.
<premoboss>
look, maybe armbian guys set up configuration withount have OPZ on and but only thinking that it should works. once again, the board is very recent, it needs time to got tuned OS.
<tuxillo>
not sure whyt it advertises allwinner H3
<premoboss>
becaus dont recognize correctly H2
avph has joined #linux-sunxi
<premoboss>
the the chip are very similar, thy identity is marcher by one byte. of u-boot fdont read that specifiv byte but refere to general hardware, ti is feri similar and H2 can appear to be a H3.
<tuxillo>
i don't think that's the issue here
<tuxillo>
i'm going to write the image again
<premoboss>
no, the probme is tht boot fook at netword and not at uSD to load the fs
<tuxillo>
i'm having some trouble following what you actually write
<premoboss>
sorry, i type fast and often i misstype some buttons
<apritzel>
network boot works for me on the OPi Zero
<tuxillo>
hey apritzel
<tuxillo>
i'm just trying to boot armbian here
<apritzel>
I have a self compiled U-Boot sitting in the SPI flash
<willmore>
beeble, it's just reflex. :)
<apritzel>
CPU: Allwinner H3 (SUN8I 1680)
<apritzel>
Model: Xunlong Orange Pi Zero
reinforce has quit [Quit: Leaving.]
<apritzel>
but apart from the SPI flash part this shouldn't make a difference to an Opi One
<willmore>
tuxillo, some users of 0piZ are seeing strange latency issues with the wireless.
<willmore>
Also, the wireless is on SDIO.
<tuxillo>
what is sdio
<willmore>
You know SD?
<willmore>
That bus used for I/O instead of just storage.
<tuxillo>
yeah
<tuxillo>
oh
<willmore>
It's a cheap way to add medium speed I/O to chips with SD ports--which are cheap.
<tuxillo>
well I didn't think of relating the SD with a network interface
<tuxillo>
hehe
<willmore>
Yep, it's not very normal, but it's been around for quite a while.
<premoboss>
tuxillo, think it as I/O bus.
<premoboss>
willmore, do you know the i/o troughput SDIO can reach?
cptG has joined #linux-sunxi
ErwinH has joined #linux-sunxi
<apritzel>
premoboss: on Allwinner SoCs it's usually SDMMC1, which is limited to 4 bits, 50 MHz, SDR, so 25 MB/s maximum throughput
<tuxillo>
hmm, this is weird. sometimes it detects mmc0, sometimes it doesn't
<premoboss>
even if 25%, of 25MB/s it will be enoung for wifi
cptG_ has quit [Ping timeout: 246 seconds]
<apritzel>
premoboss: probably true, that's why it's so popular as a cheap option to connect WiFi chips