<hno>
Yes! managed to solder cables for JTAG probe to the board with some attempts.. Trying to solder cables to a x4 resisor array in 1206 packaging proved harder than I thought. Need to get even smaller cables if doing something like this again.
<Triffid_Hunter>
hno: yeah use motor winding wire for that
hipboi has joined #arm-netbook
<hno>
Triffid_Hunter, you mean the wire you wind on the rotor in a motor or other small elecromagnet?
<Triffid_Hunter>
hno: yep, comes in very fine sizes, great for wiring to tiny pads :)
<hno>
You just scrape of the isolatioion with a knife?
<hno>
to solder.
<Marex>
hno: yes :)
<Marex>
hno: and you need some good soldering fluids for that
tuliom has quit [Quit: Konversation terminated!]
<hno>
Had to resolder the cables again. Turned out there was a short after all.Looks better now.
<hno>
too little practice SMT soldering. Everything was hole mounted when I did most of my soldering in old days..
<rm>
I wonder was it so problematic to have all the pins soldered on
<rm>
"solder them yourself" => I'm not good at soldering => "this device isn't targetted at someone not good at soldering" => ok, moving on to something else then
<RaYmAn>
From what I hear the issue is usually that some people want to use weird headers and shit rather than straight up pins (arguable, those people should be able to desolder the pins as well.)
<hno>
RaYmAn, it fails uploading the kernel for me.
<RaYmAn>
hno: hrm
<RaYmAn>
as in the fel write fails?
<hno>
yes.
<RaYmAn>
tried with the sleep 2 intact?
<hno>
yes
<RaYmAn>
hm
<RaYmAn>
I guess test1 isn't initialization the ram correctly on that board then
<hno>
Probably. Andoid boots fine from NAND.
<RaYmAn>
got JTAG running yet?
<hno>
Not yet. Got cables wired up to the right signals, but need to find a pin header to make them fit to the JTAG probe.
<RaYmAn>
ah
<RaYmAn>
also, test 1 outputs to UART 0
<hno>
that works.
<RaYmAn>
okay
<hno>
And uploading small things to DRAM works. But not the kernel.
<RaYmAn>
oh
<hno>
that crashes.
<RaYmAn>
are you using the most recent fel?
<hno>
I think so..
<RaYmAn>
oh bah
<RaYmAn>
It seems I forgot to push
<hno>
push what?
<RaYmAn>
the fix so >64KB files work
<hno>
Ah, that may explain things
<RaYmAn>
there
<RaYmAn>
had comitted, but not pushed, lol
chz__ has joined #arm-netbook
chz__ has quit [Client Quit]
<hno>
Oh, it was sufficient to just limit each bulk transfer op? no need to split the FEL operations?
<RaYmAn>
yup
<RaYmAn>
I figured I'd try simplest solution first and it worked :)
<hno>
Do reading of large blocks works?
<RaYmAn>
no
<RaYmAn>
Probably needs a similar fix
<hno>
I wonder if it's not just a timeout issue.. how long do transfer of kernel take?
<RaYmAn>
1-2 seconds
<hno>
timeout is set at 1000 msec in libusb_buil_transfer() call.
<RaYmAn>
ok, it's possible it's that. in my tests it sent around 160KB then failed
<RaYmAn>
but I think for portability it's probably better to explicitly split up in multiple bulk requests
<hno>
libusb is supposed to automatically split when needed by host os.
<RaYmAn>
I know
<RaYmAn>
I think we should still do it though. We should really also not read/write the entire file into memory, but rather read it in e.g. sanely sized blocks
<hno>
<5>Linux version 3.0.39+ (rayman@megabox) (gcc version 4.4.3 (GCC) ) #15 PREEMPT Sat Aug 11 17:03:41 CEST 2012
<hno>
si disabling, and clearing high bit of clock source, based on the parameters set above for pll5?
<Boulet>
reg_val |= (__u32)0x1<<31; //PLL En
<Boulet>
it gets enable right before, and then reread, i guess it is still on ?
<hno>
thats pll5. looking at the MBUS (MUS_CLK_REG)
<Boulet>
because they have the same structure
<Boulet>
so the enable bit is at the same position ?
<Boulet>
or at least the guys at allwinner know that haha
<Boulet>
they do that &= mask to keep what is common with the config of DRAM_CCM_SDRAM_PLL_REG no ?
<Boulet>
i am not sure why they did it that way, looks a bit cryptic
<hno>
the two differ a lot according to kernel header
<hno>
i think it's broken.
<hno>
this code only executes on resume from suspend. never tried by anyone.
<Boulet>
yeah
<Boulet>
you're right only the enable bit seems common
<hno>
the kernel header also got the register offset wrong (missing padding for reserved registe before), and obviously never touches that clock at all.
<hno>
RaYmAn, can you post your boot0 somewhere?
<RaYmAn>
hno: sure
<hno>
dump it in allwinner-info maybe?
<RaYmAn>
yeah, that was the plan:)
<RaYmAn>
there :)
<hno>
RaYmAn, thanks. those have UART1 enabled. JTAG disabled.
<hno>
and x16 DRAM I/O width?
<hno>
How many DRAM chips do you have?
<RaYmAn>
I believe it's two 256MB chips
<Boulet>
i think everybody has 2
<Boulet>
i really don't think any chinese manufacturer has been trying to get fancy on the DDR3 :)
<hno>
Odd. That boot0 header seems to say you have one chip.
<RaYmAn>
I'll check when i'm near the deviceat some point tonight
<hno>
thin point solder iron, some very thin wires, soldering lead, flux, pin header, and a gluegun to fasten it somewhere suitable, and a lot of patience in soldering the leads on the small component pads on the board without creating a short.. (0.8mm spacing, more used to soldering 2.54mm spacing..)
<RaYmAn>
and skills :)
<RaYmAn>
to avoid killing half the components on the board
<hno>
heh. nor sure it's skill in my case, more like foolhardiness. Took like 10 attempts to get it done, and for a while I was afraid I had destroyed the SD port
<hno>
s/nor/not/
<ibot>
hno meant: heh. not sure it's skill in my case, more like foolhardiness. Took like 10 attempts to get it done, and for a while I was afraid I had destroyed the SD port
<RaYmAn>
heh
ibrah has quit [Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120717123905]]
<Marex>
lundman: tokyo is large, where exactly ... which part of it ?
<lundman>
shibuyaaa.. sangubashi to be exact
Almamuetya has joined #arm-netbook
<lundman>
tokyo is a quaint village :)
kaspter has joined #arm-netbook
<Marex>
:D
<Marex>
lundman: that's good, that's two people I know from there now ... if I ever happen to make a trip in there, we can go beerdrinking :)
<lundman>
you know someone from snagubashi? wow :)
<lundman>
snag!
<lundman>
hah love it
<Marex>
lundman: naw, shibuya
<Marex>
lundman: :)
<Marex>
lundman: funny would be if you also worked for renesas ;-)
<lundman>
renesas is in shibuya? I didnt know that
<lundman>
i do workin shibuya, but for an ISP
<Marex>
lundman: I dunno man, you can't commute ?
<lundman>
i cycle
<Marex>
lundman: lots of people do in there ?
<lundman>
yeah, its a great way to get around
<Marex>
lundman: I'd really love to go there eventually ... maybe not Tokyo, but rather see the countryside, but either way, I'd love to go there for a while
orly_owl has quit [Read error: Connection reset by peer]
<Marex>
lundman: btw. do japs have trouble with gaijins or are they cool with them ?
orly_owl has joined #arm-netbook
Vayun has quit [Quit: Konversation terminated!]
Vayun has joined #arm-netbook
QingPei has quit [*.net *.split]
DEAT has quit [*.net *.split]
xxiao has quit [*.net *.split]
gsilvis has quit [*.net *.split]
QingPei has joined #arm-netbook
DEAT has joined #arm-netbook
gsilvis has joined #arm-netbook
xxiao has joined #arm-netbook
kaspter has quit [Ping timeout: 265 seconds]
ka6sox-away is now known as ka6sox
Almamuetya has quit [Ping timeout: 244 seconds]
QingPei has left #arm-netbook [#arm-netbook]
gimli has joined #arm-netbook
Vayun has quit [Ping timeout: 272 seconds]
<WarheadsSE>
mnemoc hno traeak arokux : adding the sata driver as Y in the Arch kernel so that A1000 have sata boot the easy way.
<traeak>
WarheadsSE: that's more a uboot thing isn't it?
<arokux>
WarheadsSE, thanks!
<WarheadsSE>
mmc bootloader, sata rootfs
<traeak>
okay gotcha
<traeak>
right now i keep the root on the microsd
<WarheadsSE>
Yeah, just people asking in the forums, so I am delivering ;)
<traeak>
woudl be nice to secure the sata drive better
<traeak>
take full advantage of the a10's strengths
<WarheadsSE>
get me cedarX first :p
<traeak>
WarheadsSE: you have a full working arch install and everyitgng now? including kernel ?
<WarheadsSE>
some X11 issues, because we are on Xorg 1.12
<WarheadsSE>
some sort of low level malloc problem
<traeak>
sure
<traeak>
i guess this would let me switch over to using my 1GB sd card if i wanted
<traeak>
heh
<xxiao>
WarheadsSE: on pogoplug-pro archlinux rootfs, is /lib symlink-ed to /usr/lib? last time i checked it's not
<revident>
WarheadsSE, that's an image of the A1000 on the A100 page
<WarheadsSE>
xxiao: we havent done that yet.
<xxiao>
ok.just want to check on that
<xxiao>
thanks
<WarheadsSE>
we're holding glibc @ 2.16-1 so as not to have a bajillion embedded machines go boom
<WarheadsSE>
revident: /me is aware
<traeak>
heh
<WarheadsSE>
We need a nice High-res A100 picture
* WarheadsSE
goes to lunch
<xxiao>
you mean mele1000?
<xxiao>
i can do it here now
<traeak>
i still wish they had found some way to keep a small sufficient '/' intact
<revident>
xxiao, their are now three devices based on the the same board. The Mele A1000 was the first and got all this started. The A2000 is a new case on the same hardware. The A100 is slightly stripped down and takes out the SATA.
<xxiao>
revident: I see, I have a A2000 and unaware of A100
<xxiao>
is A100 with A10 or A13?
<xenoxaos>
a10
<xxiao>
how much cheaper then comparing to 2000/1000?
<revident>
As far as I'm aware it is still the same system board as the A1000 and A2000, xenoxaos do you know if they actually removed the header for the SATA?
<xenoxaos>
there is NO sata header
<xenoxaos>
it looks like the supporting circuitry is there
<xenoxaos>
so some solder wick and a header you should be able to install one
<xxiao>
so they just get rid of the small sata adapter board, that's like $3?
<traeak>
apparently just the plastic connector which is even cheaper
<traeak>
so no sata connector on the mobo, just the solder points
gimli_ has joined #arm-netbook
gimli__ has joined #arm-netbook
gimli has quit [Ping timeout: 276 seconds]
gimli__ is now known as gimli
gimli_ has quit [Ping timeout: 276 seconds]
<WarheadsSE>
traeak: correct
Boulet has quit [Quit: zzzzzzz]
rellla has quit [Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347]]
<specing>
xxiao: sata connector is like $0.1 down there :)
<traeak>
.1usd seems high for that
<specing>
Yeah you are right
<specing>
probably 0.03
<furan>
can someone do me a favor and put nand_id.c from the sun4xi driver on a pastecode site?
<Turl>
I thought sata connectors grew on trees
<furan>
it's in drivers/block
<Turl>
furan: can't you view it @ gihub?
<furan>
can't github at work
<furan>
almost got 32gib nand working
<revident>
They already have the board being mass produced. Mostly likely what they have is a some savings on the case and the dock PCB. And even at pennies, when your doing runs of 100,000... well that's a $1000 in profit.
<furan>
looking at the datasheet for one of the parts I can't for the life of me correlate with what's in the array entry
Quarx has quit []
<Turl>
my nand is fubar'd, e2fsck -yv on the data partition is a several minutes stream of broken stuff :)
<Turl>
also <4>[ 116.080000] PHY_PageRead : too much ecc err,bank 1 block 7ce,page 1b
<Turl>
<4>[ 116.090000] PHY_PageRead : too much ecc err,bank 0 block 7ce,page 1f
<Turl>
<4>[ 116.600000] PHY_PageRead : too much ecc err,bank 1 block 7ce,page 6b
<Marex>
Turl: ext2 on NAND ? :-(
<Marex>
Turl: why don't you use ubifs or such ?
<Turl>
uwhat? :)
<Turl>
it's ext4 actually
<Marex>
ubifs
<Turl>
never heard of it
<xxiao>
jffs2, yaffs, ubifs, never ext*
<Turl>
google themselves dropped yaffs2 and moved over ext4
<Marex>
xxiao: on nand? never jffs2 ;-)
<Marex>
xxiao: jffs2 bbm is not suited well for nand
<Marex>
Turl: on raw nand or on SSD ?
<Turl>
Marex: on eMMC
<xxiao>
Marex: thought jffs2 is now good for nand?
<Marex>
xxiao: it was originally written for NOR though
<xxiao>
right, but i think it's good for NAND nowadays
<xxiao>
Turl: eMMC you should use ext* and vfat etc
<Marex>
xxiao: but then, UBI and UBIFS is much better I'd say
<WarheadsSE>
if anything use ubifs
<WarheadsSE>
ext4 is decent with the right tuning
<Marex>
xxiao: agreed about emmc
<Marex>
it has some builtin bbm
<WarheadsSE>
ubi/ubifs was desgined for nand, iirc
<Turl>
besides ext4 was already there when I got the tablet :P
<Marex>
Turl: that doesn't mean it's right ;-)
<xxiao>
WarheadsSE: never used ubifs for "production", i thought yaffs is already in kernel.org now?
<WarheadsSE>
maybe, is yaffs r/w ?
<Turl>
Marex: I know :)
<Marex>
it is
<Marex>
xxiao: there's even yaffs2 now I think
<xxiao>
i think so, only squashfs that 's read-only
<xxiao>
right, the new one is yaffs2
<WarheadsSE>
ubi has handy built-in bbm/wear/compress
<xxiao>
the trend seems like everyone will use a SD to hold software instead of raw NAND
<xxiao>
and, probably with a spi-flash to hold uboot/kernel/ramfs for reliability/recovery
<Marex>
xxiao: that's rather sad though with the SD ... the BBM is quite all right in kernel
<Marex>
xxiao: SD will leverage some overhead from the kernel, but (!) the BBM won't adapt well on all filesystems used on top of it
<xxiao>
i think SD incorporated BBM etc internally, including its own wear levelling algorithm
Hexxeh has joined #arm-netbook
<xxiao>
still SD itself is not reliable, in the past product we sed SLC SD card, which is very expensive, $40 for 4G in volume
<Marex>
xxiao: exactly ... but the internal BBM usually works fine for "majority FS", aka FAT for usual SD and exFAT for SD<what's the new one called?>
<Marex>
ah ... SDXC
<Marex>
checked the difference between SDHC and SDXC, the only difference seems two bits in some register with almost no significance and the BBM
<xxiao>
right SD is really optimized for FAT/exFAT, hope it can be filesystem neutral
<hno>
xxiao, SD is mostly filesystem neutral, but may be optimized for FAT as that is the default filesystem. But most important is alignent and blocksize.
<xxiao>
i actually tried Arnd(?)'s alignment/blocksize suggestion and did performance benchmark, did not show much difference
<hno>
prehaps your default was sufficiently aligned?
<xxiao>
could be, but i did tweak around(purposely make it unaligned), no big performance impact was found then
<hno>
wrongly aligned and you hot both performance and wear issues.
<hno>
bu yes, the difference is not very big.
<Mazon>
man, "No. The communication with Allwinner is neraly zero." - that just blows
<xxiao>
Mazon: where is it from
<Mazon>
gimli on xbmc forum
<Mazon>
(also in this channal)
<Mazon>
channel*
<Mazon>
just depressing that one needs to use amlogic as it is now
<gimli>
not my fault that Allwinner is that dumb
<hno>
allwinner do not know which leg to stand on.
<xxiao>
Mazon: it's a progress if allwinner or any chip vendor that at least is willing to work with oss
<Mazon>
gimli: I know :/
<WarheadsSE>
how does amlogic relate to allwinner?
<xxiao>
allwinner is a domestic company, amlogic actually HQ in SF
<Mazon>
amlogic is a different soc
<hno>
and different company
<xxiao>
Amlogic's chip is relatively more expensive and hot, it's mainly A9 while Allwinner is A8
<hno>
xxiao, allwinner is working hard on closing that gap.
<Mazon>
hno: well they're dropping the ball by not supporting xbmc
<xxiao>
hno: what gap are you referring to
<Mazon>
A8 vs A9 ?
<Mazon>
damn, so right now - hardware decoding is better off on Raspberry Pi (!) and amlogic's - sad panda
<Mazon>
pardon my ignorance, wouldn't it be "easier" (!) to reverse engineer the allwinner VPU, than Mali GPU?
<hno>
The VPU probably isn't very complex compared to Mali. But hard to reverse when you can't even get the proprietary libraries to work proper.
<Marex>
hno: isn't there that lima driver for Mali ?
<hno>
yes lima is the Mali reversed driver.
<hno>
based on observations of the command stream sent by the proprietary library on known operations.
<Marex>
yes
<hno>
one big difference is that Allwinner VPU is only in Allwinner SoCs, while MALI is hitting a broad range of ARM SoCs.
<xxiao>
isn't MALI for graphic while VPU for video?
<hno>
xxiao, yes.
<e-ndy>
all: hi
<e-ndy>
all: anyone else has amlogic cpu device?
<hno>
at lests MALI 200/400. Next generation is a little more blurred.
<xxiao>
ARM is also selling its own vpu engine, not sure anyone is using it
<Marex>
xxiao: they do ? :)
<xxiao>
Marex: i think it's renamed? it's called mali-ve6 or mali-ve3, don't recall they had mali-prefix in the past
<xxiao>
arm.com seems down
<Marex>
xxiao: oh, all right
<WarheadsSE>
e-ndy: yes, Arch Linux ARM devs were recently donated several
<xxiao>
WarheadsSE: just curious, anyone compared archlinuxarm rootfs size vs angstrom, assuming similar packages
<WarheadsSE>
idk, nor honeslty care
<WarheadsSE>
we're not out to be the tiniest. Leave that to DSL
<WarheadsSE>
We're out to give you base connectivity to an often headless device + ssh
<WarheadsSE>
after that, we don't assume you need much, and its up to you
<WarheadsSE>
'Arch Linux ARM doesn't coddle its users. We say "Welcome to Linux, here's a wrench"'
<Turl>
haha nice one
<Turl>
I'm a debootstrap guy though :)
<xxiao>
Turl: ever tried Grip?
<WarheadsSE>
Turl, there is pacstrap :)
<xxiao>
i used deboostrap most often, grip's small size is appealing but never tried
<WarheadsSE>
it wasn't meant for ARM thoug
<Turl>
xxiao: never heard of it
<Turl>
WarheadsSE: debootstrap can debootstrap any arch from any arch :P
* WarheadsSE
shrugs
<Turl>
it uses a 'second stage' if the arch are not compatible
<WarheadsSE>
It's not that hard for us
<xxiao>
Grip is from embedded debian, emdebian, that's a small size debian for embedded stuff, i should give it a shot sometime
<Turl>
but with the binfmt stuff and qemu and the like people get it done fully on a host lately :P
<xxiao>
Turl: for devel that is
<xxiao>
the binfmt is really nice, who needs scratchbox anymore
<xxiao>
that may also kill the NFSROOT for devel, now you do it all on the host
<WarheadsSE>
Turl: honestly, I haven't looked at pacstrap to do that yet. It's usually as simple as extract and existing arm rootfs, then us rfs-pacman (minor wrapper) to alter/update that rootfs
<xxiao>
except for uboot/kernel/driver testing
<WarheadsSE>
retar, all done
<Mazon>
interresting post on the mailing list .. must be on the channel or something :)
<hno>
Mazon, interesting timing indeed.
* WarheadsSE
isnt on the mailing list
<Marex>
ML ? There's a ML for A10 ?
<hno>
Marex, not actually for A10 as such, but see topic.
<Marex>
hno: stupid me, thanks
<hno>
Hmm.. where do I find adb?
<Marex>
There was something in the android SDK (or was it PDK?)
revident has quit [Quit: Hi ho hi ho, it's off to Seneca@York I go.]
<Marex>
btw is anyone planning to get the A13 olinuxino ?>
<hno>
Marex, quite likely.
<WarheadsSE>
we'll see if they send alarm dev's one
<hno>
yum install android-tools
arokux_h has joined #arm-netbook
<Marex>
WarheadsSE: alarm dev's ?
<hno>
supply of Olinuxino A13 is a bit limited yet.
<Marex>
hno: I only have the mx233 one now ;-)
<WarheadsSE>
<< Arch Linux ARM = A.L.ARM = "alarm"
<Marex>
heh
gimli has quit [Quit: Verlassend]
<furan>
livesuit outputs a lot of info using OutputDebugString when it programs
rsalveti` has joined #arm-netbook
rsalveti has quit [Ping timeout: 276 seconds]
rsalveti` is now known as rsalveti
rsalveti has quit [Changing host]
rsalveti has joined #arm-netbook
mpthompson has joined #arm-netbook
madmalkav has quit [Quit: Leaving]
gsilvis has quit [Read error: Connection reset by peer]