* hno
really needs to get JTAG level debugging running.
<hno>
too much annoying low-level initialization crap going wrong.
<hno>
but now sleep.
tuliom has joined #arm-netbook
Almamuerta has quit [Quit: Page closed]
tuliom has quit [Quit: Konversation terminated!]
<Turl>
hipboi_: is there any chance allwinner is reworking the Cedar stuff to become OMX compatible? I won't bother porting the ICS Cedar code to JB if they are
Almamuerta has joined #arm-netbook
zzz_kiev has joined #arm-netbook
zzz_kiev has left #arm-netbook [#arm-netbook]
<xenoxaos>
2d
<Turl>
mnemoc: preempt rcu + interactive seem to cause huge system failure on kernel :|
<Turl>
my last_kmsg is too corrupted to be of any use but I distinguish lots of pointer dereference errors
gimli has joined #arm-netbook
Quarx has joined #arm-netbook
nibb__ has joined #arm-netbook
nibb_ has quit [Read error: Connection reset by peer]
<RaYmAn>
I'm battling installing linux on my mac mini
<Turl>
no bootcamp thingy?
<RaYmAn>
I can't seem to find any way to actually install bootcamp stuff on this device
<RaYmAn>
it's a mac mini server (late 2009) - and it seems to be stupidly hard to get working :(
<Turl>
"Use Boot Camp Assistant (located in the Utilities folder) to create a partition for Microsoft Windows. Boot Camp Assistant works only with an Intel-based Mac that has a single hard disk partition."
<RaYmAn>
yeah, that kind of requires actually having boot camp assistant.
<RaYmAn>
I've been trying to convince this damn pc to boot linux all day :P
<j1nx_>
Turl: Something about Android? He asked me for a specialst, you were the only one I could thing of :D
<Turl>
yep, about android
<rm>
ah, nope that's not all
<rm>
I'll post to the mailing list
<Turl>
rm btw you're the one with PGP signed messages right?
<Turl>
rm are you using enigmail?
<rm>
mnemoc, curl -6 linux-sunxi.org
<rm>
curl: (7) couldn't connect to host
<rm>
Turl, "the one with PGP signed messages" O.o
<rm>
yes
Mazon has quit [Read error: Connection reset by peer]
<rm>
but no
<rm>
I am using Claws-Mail
<Turl>
rm anyway, I always disable PGP for the ML because it's awesomely spammy to sign inline, and noticed you attach the signature, is that the "PGP/MIME" thing?
<hno>
Yes. PGP/MIME looks like attachment to non-PGP aware mail clients.
<L84Supper>
this things built like a proto that you just want to show someone for proof of concept
<hno>
"8-Bit Microcontroller-Microcomputer - Tone Generator,Voice ROM"
<L84Supper>
then you go make the real one
<L84Supper>
yeah, it has a bunch of GPIO
<L84Supper>
I'll look at the board later, see what they did
<hno>
I don't get why one would want an EC in an A10 design, unless it's also the keyboard controller. But the A10 can also act as keyboard controller.
<L84Supper>
I'll find out later
<L84Supper>
maybe they didn't place the ESD parts down since it's so awful you really don't want to even use it
<L84Supper>
I can't say enough nice things about this netbook
<L84Supper>
the case is very shiny
<L84Supper>
you really know when you press the trackpad buttons, it like pressing a 1983 IBM keyboard
<L84Supper>
plenty of airflow inside
<L84Supper>
spare room for 2x the battery
<L84Supper>
wifi module easily replaced
<L84Supper>
they easily could have made this unit much better
* rm
enjoys the newfound sanity of debugging with a serial console
<mnemoc>
j1nx_: did the mem= thing work?
<mnemoc>
rm: wiki wiki :)
<L84Supper>
the board has a USB on the go connector but they didn't make an opening in the case for it
nibb has quit [Read error: Connection reset by peer]
nibb has joined #arm-netbook
<rm>
the uboot SPL does not see my SD card
<rzk>
rm: blind guess: try slighlty press on both ddr3's and see if anything changed
<rm>
I don't have seven hands
<mnemoc>
rm: what spl?
<rm>
I already have to hold the serial console wires in midair :DDD
<rzk>
solder them? :3
<rm>
mnemoc, both 'old' and today's
<L84Supper>
looks like the EC is for keyboard scan
<hno>
L84Supper, also seem to have a recovery button (sw3)
<rm>
mnemoc, yes, I already tried the SPL from there
<mnemoc>
rm: same problem?
<rm>
verified by md5sum
<rm>
yes, it gives the first example of output
<rm>
spl: mmc device not found!!
<mnemoc>
rm: compare the pins in your stock script.bin with the classic one
<mnemoc>
smells like you are wired differently
<hno>
SPL do not use script.bin
<hno>
neither do the full u-boot.
<mnemoc>
hno: I know, but any different gpio will be reflected in the script.bin
<hno>
yes. Maybe SD card present pin is wired differently.
<hno>
but I don't think SPL or even u-boot checks that pin.
<hno>
The device do have internal NAND, right?
<rm>
yes
<hno>
The A10 have quite many SD controllers. But I think the other one that it can boot from shares pins with NAND so if it booted SPL from SD and have NAND then is should be MMC0.
<rm>
however I tried the same card that works in the other MK802
<rm>
with exactly the same OS image still on it
<rm>
and it didn't work
<mnemoc>
but there could be 512 meles needing a different initializatin, isn't it?
<mnemoc>
dram i mean
<mnemoc>
hipboi_ may now
<hno>
Yes. DRAM setup is a bit messy. If the board is using significantly different DRAM then SPL would not be able to load u-boot.
<hno>
and the dram_para section in script.bin from the failing board looks very odd.
<hno>
maybe the livesuite DRAM probing mentioned for A13 is also applied to A10 in newer releases which would explain why it's not in script.bin. If so then we need to get boot0/boot1 from the NAND to find actual DRAM parameters.
gimli has quit [Ping timeout: 246 seconds]
<mnemoc>
do we know to do that from `fel` yet or only from extracted livesuite images?
<hno>
Ah, nice. The EOMA68 A10 boards will have almost full GPIO capability.
<hno>
mnemoc, neither.
<hno>
apparently livesuite patches boot0/boot1 on the fly when programming the flash.
<hno>
no idea how phoenixcard is supposed to work with those firmwares.
<hno>
phoenixcard needs working DRAM parameters for the SDCARD.
<hno>
and can't probe the target board.
<mnemoc>
the best way for us i think is to find the magic address to dump using `fel`
<hno>
it's not a magic address.
<hno>
boot0 & boot1 is in the first erase blocks of the first NAND.
<hno>
but neither kernel NAND driver or u-boot NAND driver exposes raw NAND access. Only logical NAND access with block translation layer.
<mnemoc>
hipboi!!!
<mnemoc>
:(
<hno>
Well, the raw nand access layer is obviously there in the driver, but only accessed via the translation layer.
<mnemoc>
it's not the nicest driver to research...
<hno>
there is also a simplified raw nand access layer with comments sayint it's for u-boot to access the boot area, but have not got those to work.
<rm>
but now with the serial console I managed to iron out the nanda-based kernel bootup
<specing>
It is funny how most vendors pick the most memorable ip range ever
<xenoxaos>
hno, back to the DRAM on different boards not allowing things to load.... if the timings in the SPL were close to the actual timings of the dram, BUT NOT quite right, would uboot load intermittently/kernel loading be completely unreliable?
<hno>
Not sure.
<hno>
penguin42, MPEG Transport Stream interfaces, for DVB intefacing etc.
<penguin42>
hno: Hmm, so yeh I've come accross MPEG Transport streams, but I've never seen an interface on a CPU for it - what do they look like from software?
<hno>
Unknown. All I know is that the A10 contains MPEG TS demultiplexers.
<hno>
there is no driver in the kernel sources that I am aware of.
<penguin42>
hno: Interesting, I can see why - MPEG is a pain to decode in software, it's all stupidly aligned bit strings
<hno>
I think you can even make them feed VE directly, enabling decode without touching the ARM core.
<rm>
looks like the RAM in the second segment does not really work
<hno>
rm, what?
<rm>
this kernel uses "mem=448M@0x40000000 mem=512M@0x60000000"
<rm>
'memtester 300M' seemed to work
<hno>
Ok, 1G hardcoded on command line.
<rm>
'memtester 750M' and 500M lock up the machine hard
<rm>
but bizzarely it continues to be pingable
<hno>
ping is pretty low level.
<rm>
so not that hard, I guess :)
<hno>
ping continues as long as interrupts works basically.
<hno>
Have you tried with just the first mem block?
<rm>
yeah, I will try now
<rm>
but I verified it has 2x512MB RAM chips
<rm>
and 2nd "but": even the Boot0 has "RAM: 512MB"
<hno>
Then it only configured 512MB in the DRAM controller.
<hno>
boot0 reads DRAM configuration from a header section in boot0. In the tools I have seen this header section is populated from script.bin when the firmware image is built.
<hno>
but the dram_para section in your android version seems empty?
<rm>
hm, so I basically have a firmware image for a 512MB board
<hno>
but a boot command line for 1G board?
tuliom has joined #arm-netbook
<rm>
this is supposedly an 1G board
<rm>
maybe I should find a different firmware
<hno>
From where is that boot command line?
<rm>
I hardcoded it into my kernel
<hno>
Ok.
<hno>
So you livesuite flashed it, and then replaced kernel & root?
<hno>
Yes, you need a 1G firmware for a 1G board, unless the automatic probing & detection by livesuite on A13 applies to later versions for A10 as well.
<hno>
Actually you need a firmware which is for your exact board type. Cross-flashing is only possible between devices with exact same DRAM configuration.
<rm>
I flashed it, then replaced linux.ini and added bImage
<rm>
and the bImage has "root=/dev/mmcblk0p2" hardcoded
<rm>
okay, now running with a 512MB kernel, 317MB available, testing 275MB - seems fine (at least does not fail/lockup instantly)
* penguin42
watches the A10 factory video - I'm always amazed by how much manual stuff is still in all this
<specing>
robots are expensive
<penguin42>
and probably harder to train on anything less than vast production runs
<rm>
imagine if you had to sit 10 hours a day fitting widgets into gadgets
<rm>
and then feel grateful that you have your current job / living conditions
<rm>
s/10/16/, maybe
<penguin42>
someone has at least given them fume extractor fans
<rm>
also there's no "the" video, I know at least three
<penguin42>
if you're going to want to shave pennies off stuff that just would seem so easy
<specing>
A funny thing happened with the industrial revolution: first they started replacing human workers with machines, then they just move everything over to china
nibb has quit [Read error: Connection reset by peer]
<hno>
penguin42, they only have one guy doing paint job, and that's likely the only task he is good at doing. Seem to keep up fine with the production rate.
nibb has joined #arm-netbook
<penguin42>
hno: Shrug, I doubt he couldn't do some of the other tasks - like the nice girl who basically just wipes a screen
<penguin42>
specing: The interesting question is what happens next, as the chinese get more prosperous and want to get paid more, does the production move to the next cheapest country or do they pick up some more mechanisation
<hno>
rm, confusing. Seems same firmware is used on MK802 and MK802+?