<xxiao>
i almost bought that one, then realized i could get a usb3 one with $10 more
<WarheadsSE>
w/ a fan
<WarheadsSE>
interesting
<WarheadsSE>
nvm that ^
rsalveti` is now known as rsalveti
rsalveti has quit [Changing host]
rsalveti has joined #arm-netbook
mSquare has joined #arm-netbook
<xxiao>
why that fan?
<xxiao>
i am going to cut it off
<xxiao>
most docking does not have that fan
<xxiao>
some enclosure has it, but this is an open air installation
Quarx has joined #arm-netbook
cat_n9 has quit [Ping timeout: 240 seconds]
kaspter has joined #arm-netbook
ejstacey has joined #arm-netbook
phh_ has joined #arm-netbook
phh has quit [Ping timeout: 245 seconds]
sspiff has quit [Ping timeout: 252 seconds]
vgrade has joined #arm-netbook
rellla has joined #arm-netbook
ZaEarl has quit [Quit: Ex-Chat]
cat1 has joined #arm-netbook
cat_n9 has joined #arm-netbook
cat1 has quit [Client Quit]
cat1 has joined #arm-netbook
cat1 has quit [Client Quit]
cat1 has joined #arm-netbook
cat1 is now known as cat_x301
Gujs_ has joined #arm-netbook
Gujs_ has quit [Remote host closed the connection]
kaspter has quit [Ping timeout: 244 seconds]
kaspter has joined #arm-netbook
marcan has joined #arm-netbook
pawel5870 has joined #arm-netbook
pawel58701 has joined #arm-netbook
pawel5870 has quit [Read error: Connection reset by peer]
<cat_x301>
morning; can anyone recommend chip (no more than $70) tablet with HDMI output? Sure I can search, but would like to hear first hand experience :)
phh_ is now known as phh
rellla has quit [Ping timeout: 268 seconds]
rellla has joined #arm-netbook
popolon has joined #arm-netbook
<mnemoc>
cat_x301: I doubt you can find such thing yet
<cat_x301>
mnemoc: i remember seeing something that was offered for 45$, but did not risk to order
<mnemoc>
the cortex-a5 with hdmi tabs aren't that cheap yet, and allwinner-a13 ones don't have hdmi
<mnemoc>
unless you search for arm11 devices...
saltsaint has joined #arm-netbook
saltsaint has left #arm-netbook [#arm-netbook]
<cat_x301>
allright. btw, how are things with linux-sunxi-3.4, haven't seen any updates there recently.
* cat_x301
is a bit offline these days..
<mnemoc>
personally I haven't have much "spare" time... there are some commit in 3.0 to merge, and then sync with the latest 3.4.x ... was going to try to implement pinctrl next
<mnemoc>
since 3.7 pinctrl and multiplatform support will be required
<mnemoc>
but beside having earlyprint the most important bit of the core is the pio support, and these days that means pinctrl
<mnemoc>
cat_x301: did you make your 3.6 using cherrypicks? is it available?
<cat_x301>
mnemoc: it is available but i did not merge display and gpu.
<cat_x301>
mnemoc: wrt mali - i was not sure whether to take 3p1 or 3p0
<cat_x301>
mnemoc: sorry, i have asked this already but now forgotten: which branch would be a candidate for cherry picking for disaply and co
<cat_x301>
s/disaply/display
<cat_x301>
mnemoc: is next_mali good enough?
<mnemoc>
no
<mnemoc>
stick with `linux-sunxi-3.4` as base for 3.6 forwarding
<mnemoc>
once next_mali actually gives something it will be merged to 3.0-v2, and then forwarded to linux-sunxi-3.4
<mnemoc>
but at the moment it's still wip/experimental
<cat_x301>
mnemoc: i haven't done any testing there since last merge from linus tree, so be aware!
<mnemoc>
ok
hp__ has joined #arm-netbook
<cat_x301>
mnemoc: btw, stupid question, but which way you usually do forwarding: take new kernel and do cherry-picking/merging, or vice versa -- old kernel as base and then cherry pick from upstream?
<mnemoc>
FROM/TO in start.sh define the range of commits
<mnemoc>
I usually do a "refenrece" branch which is the merge of all not-sunxi. upstream-3.4 + latest 3.4.x in the 3.4 case
<mnemoc>
and use that as FROM
<mnemoc>
upstream-android-3.4 I mean
<mnemoc>
it's a sort of "poor-man stacked git"
<mnemoc>
but for 3.6+ i would really prefer to stick with the bare core and leave real-life (with drivers) in 3.0/3.4 until it gets polished
<mnemoc>
polished = unified drivers, pending bugs fixed, and mali integration working
<cat_x301>
mnemoc: the bare core -- mach stuff?
<mnemoc>
yes
tzafrir_laptop has quit [Ping timeout: 248 seconds]
<mnemoc>
and forward that part to the current arm-soc requirements. DT/pinctrl/gpiolib/multiplatform
<cat_x301>
mnemoc: yeah, this is good plan. I was thinking of starting sort of polishing for mach-sunxi, but lack of knowledge and experinence prevented me from that.
<mnemoc>
(fortunatelly pinctrl brings gpiolib for free)
<cat_x301>
mnemoc: did anyone start to work on DT for sunxi?
<mnemoc>
cat_x301: in "multiplatform arm-soc" mach-foo is almost empty :|
<mnemoc>
not that i know
sspiff has joined #arm-netbook
sspiff has joined #arm-netbook
sspiff has quit [Changing host]
<mnemoc>
personally I don't even know how to map sunxi configuration/flexibility to DT yet.... that's why I wanted to start win pinctrl instead of DT
<mnemoc>
but i can't until the weekend
<mnemoc>
will update the 3.4 branch today
<cat_x301>
mnemoc: if i would know what to do about pinctl :)
<RaYmAn>
I agree pinctrl/gpiolib is a better starting point - DT isn't much use if you can't setup pins in it :P
<mnemoc>
:)
<mnemoc>
cat_x301: 3.4 needs help deperately too. specially usb gadget
<mnemoc>
:)
<cat_x301>
mnemoc: what about display, does it work already?
<mnemoc>
disp, sure
<cat_x301>
mnemoc: in 3.4?
<mnemoc>
afaik yes
<mnemoc>
at least I got fbcon once :p
<cat_x301>
need to try again. last time i saw issues with it.
* cat_x301
also needs to fix gentoo broken deps first..
<cat_x301>
i somewhat managed to get my system out of control :)
<mnemoc>
if you extract them from the image, please add it to the wiki page
<mnemoc>
cat_x301: very good for the price, and you get the same SoC we are hacking ;-)
<cat_x301>
mnemoc: very true!
<andoma>
mnemoc: will do .. i might have a stab at it tonight
<mnemoc>
andoma: great!
<andoma>
ftr i'm the lead dev of a mediaplayer called showtime (http://www.lonelycoder.com/showtime/) and i was thinking of getting it running on my mk802 (preferrably without X)
<mnemoc>
hope he makes bindings to something others can use too, like gst, ffmpeg or libva
* mnemoc
hates player-specific bindings
<lundman>
empatzero has no binary to quick test? if he needs space for downloads I can help
<mnemoc>
naguirre: assuming you are aiming at using the open source boot chain, you would need to add support to uboot to read the buttons
<cde>
if u-boot works then it's not bricked
<naguirre>
ah so there is a button :)
<naguirre>
cde: no bricked in usual way, in user way, i mean if something goes wronf during update
<naguirre>
i wnat a way to come back to production version
<naguirre>
mnemoc: ok, i already to this kind of stuff in uboot
<naguirre>
you are talking about the button on the right side of the mele ?
<cde>
just provide a tools that creates a "factory reinstall" sd
<naguirre>
i don't want to use sd card
<mnemoc>
naguirre: the mele in particular only has the power button, so you do need a recovery card
<naguirre>
if i understand correctly as long as the first nand sector is readable, you are able to boot something
<mnemoc>
SD and FEL by pass the nand booting entirely
<mnemoc>
bypass*
<hno>
naguirre, mele only have a power button.
<naguirre>
yep
<naguirre>
ok
<naguirre>
but it seems the power button doesn't work for me
<naguirre>
to power up i just need to plug AC power
<hno>
i don't thing you can enter recovery mode with it.
<mnemoc>
it's probably connected to the AXP
<naguirre>
what's the AXP ?
<mnemoc>
AXP209, power managemnt unit chip
<hno>
that's normal. You can push the power button for 12 seconds to power off if you like. och a quick push to suspend/resume.
<naguirre>
ah ok
<hno>
be warned that the 12 seconds is a hard power off, pretty much equivalent to pulling the power. So don't do any operations involving I/O while doing that.
<naguirre>
yep i see
<hno>
phoenixcard is the official recovery for mele.
<hno>
a specially prepared SD card which reflashes the device.
<hno>
prepared from Android firmware image + phoenixcard tool.
<naguirre>
there is IO on the mele ?
<hno>
There is NAND, and plenty of USB ports where you can connect storage.
<naguirre>
for example could i use Rx/Tx of the debug lines for IO ?
<hno>
Sure, the "debug" lines are just an UART.
<mnemoc>
naguirre: if you need GPIOs you are better off with an a10/a13-olinuxino or a cubieboard
<hno>
if in that mode then you also have about 10 pads which can be used for various I/O functions of GPIO.
<naguirre>
mnemoc: i need spdif
<naguirre>
and i need rca Audio also
<naguirre>
and wifi
<mnemoc>
extension board maybe?
<naguirre>
cubieboard is a good candidate, with an expansion board
<naguirre>
but mele is finally the best choice for the price
<naguirre>
i looking at olinuxino
<mnemoc>
you can most probably use part of the USB OTG and UART0 headers as GPIO
<mnemoc>
in the mele
<naguirre>
ok, and add code in uboot to detect
<hno>
for what purpose?
<naguirre>
recovery :)
Almamuetya has quit [Ping timeout: 264 seconds]
<naguirre>
sdcard is finally the best choice ;)
<hno>
you have the u-boot console on uart0.
<naguirre>
yeah i don't want to loose it
<hno>
from the u-boot console you can easily boot recovery.
<naguirre>
yep that not the problem, the problem is enter in this mode
<mnemoc>
he wants a grandma to be able to do it
<naguirre>
and i would like an external way to do so
<naguirre>
haha exactly:)
<hno>
then teach u-boot to read the power button is probably the best.
<hno>
if you want internal recovery from recovery partition. Otherwise SD card based recovery.
<naguirre>
yep
<hno>
the power button is just a button unless you hold it for long.
<naguirre>
ok that's good to know
<naguirre>
thanks for help
<naguirre>
ah and another question, there is a way to change the LED from uboot and from linux ?
<naguirre>
or it's directly connected to vcc ?
<mnemoc>
phoneix card based installers make it blink red
raoulh has joined #arm-netbook
<mnemoc>
and something in the gpl violating kernel turns it blue before reaching userspace
<naguirre>
gpl violating kernel :)
<mnemoc>
"stock kernel" :)
<naguirre>
but no classic led driver
<mnemoc>
not yet
<naguirre>
ok
<naguirre>
and another question, what's behind nand driver ?
<naguirre>
i can't see any mtd layer
<mnemoc>
it's fully home grown
<hno>
not sure it's home grown. But sure, it's not mtd.
<naguirre>
ah :)
<naguirre>
so no way to get ubi running on it
<naguirre>
how it deals with bad blocks ?
<hno>
exactly how is unknown, but it deos deal with bad blocks.
<hno>
and do wear leveling etc.
<naguirre>
ah ok fine
<RaYmAn>
wear elvelling is done in the driver at least - probably most bad block handling as well
<hno>
yes
<naguirre>
ouch
<naguirre>
ubi is so good for that
<mnemoc>
tom mentioned the developers of that driver considered mtd obsolete and that's why the invented their own...
<naguirre>
mtd obsolete ?
<hno>
obsolete in the sense that it's not good for hosting a fat filesystem.
<naguirre>
fat16 you mean ;)
<naguirre>
ok :)
<naguirre>
bon conclusion, pour le recovery, le plus simple reste la carte sd
<naguirre>
8h sorry :)
<hno>
kan bara gissa vad du menar.
<naguirre>
usb host is working in uboot ?
<hno>
no
<naguirre>
ok
<hno>
Actually no USB driver at all in the free u-boot, but even in the allwinnerized u-boot there is only fastboot device mode implemented.
<hno>
the driver do support host mode however, but not integrated in u-boot.
<naguirre>
ok
<hno>
exact sane druver as for the kernel, only different glue layer.
<hno>
s/dru/dri/
<ibot>
hno meant: exact sane driver as for the kernel, only different glue layer.
* hno
can't type tonight either. Switching between two slightly different keyboards hurts.
<RaYmAn>
mtd does seem kind of stale..last I checked it hardly supported any recent nand chips (including the one on a13-olinuxino)
<RaYmAn>
everyone is mostly switching to eMMC, so I guess it is kind of obsolete? :P
<hno>
for good reasons. Much easier to deal with a block device than NAND erase blocks.
<hno>
plus that the eMMC is far more compact.
<hno>
I don't see much reason why one should design for bare NAND today.
<mnemoc>
job security?
<destinal>
lol
<hno>
Wonder if tom also prepared pads for eMMC. I think you can fit pads for SD, eMMC and NAND at the same location without too much effort.
<hno>
providing choice without having to redo the PCB.
von_fritz has quit [Quit: vonfritz leaves, don't panic]
<destinal>
hno: which board are we talking about?
<mnemoc>
destinal: the cubieboard
<hno>
I know he prepared the board for a choice of uSD 2 or NAND.
<mnemoc>
yes
<hno>
mnemoc, do you remember where is those early prototype pictures are?
<mnemoc>
july's prototype was published on G+... but not longer there
<hno>
It's there in his blog.
<hno>
Ah, limited sharing.
<hno>
but NAND already mounted there. Can't tell if there is eMMC pads.
<destinal>
mnemoc: ah I didn't realize tom was making his own board
<mnemoc>
destinal: mine already left .hk :)
revident has quit [Quit: Combustible lemons? Bah, I bring you weaponized asparagus!]
<mnemoc>
good night
<hno>
Yes, good idea. Good night.
<hno>
Not sure where mine is. Last status is "2012-09-19 18:27:01Posted through Sweden Post"
<RaYmAn>
probably stuck in customs
lkcl has quit [Ping timeout: 256 seconds]
<hno>
customs is within sweden post after it arrives here.
<RaYmAn>
I assumed posted through sweden post meant that it had been passed on to sweden post, but I guess I might be wrong
<hno>
It does, but they also include their tracking, but there is none.
<hno>
I think there was similar indications when he shipped the mele so not worried yet for some days.
<hno>
there is a tracking number for sweden post as well, but not recognised.
<hno>
I do remember clearly that sweden post did show that the mele had arrived in Stockholm and then sat on the package for 8 days.