<hno>
It's most likely leaked somewhere. Chineese is good at leaking..
<arokux_h>
hno, so you have it? :)
<furan>
how does livesuite use the nand driver? does livesuite send code to execute on the device?
dyoung has joined #arm-netbook
<arokux_h>
hno, where do you know 8250 knows USR, it's not in drivers/tty/serial/8250/8250.c
ka6sox has joined #arm-netbook
_whitelogger has joined #arm-netbook
<arokux_h>
hno, there is something similar in: arch/m68k/include/asm/mcfuart.h
<hno>
arokux_h, 8250_dw.c mentions it. Seems to have somewhat different functionality there however.
<arokux_h>
hno, and drivers/tty/serial/mcf.c too.
<arokux_h>
ok, so what does it mean if the second bit of USR is set?
<arokux_h>
sorry, is NOT set.
<arokux_h>
"is not ready"?
<hno>
Bit #2 is Transmit FIFO Empty
<hno>
1<<2
<hno>
1<<1 is Transmit FIFO Not Full
<hno>
not sure which of the two you ask about.
<arokux_h>
about this one: while ((SW_UART0_USR & 0x2) == 0); so << 1
<hno>
while (FIFO is full)
<arokux_h>
yes, right.
<hno>
where did you find that?
<arokux_h>
in early_printk.c
<arokux_h>
(in allwinners)
<arokux_h>
hno, it's used only there.
<arokux_h>
hno, as I understood each mach-* should create debug-macro.S under mach/include, with some asm macros in it. the will be then used (by #include) by arch/arm/kernel/debug.S and early_printk will work on top of them.
<furan>
hey hno do we have source for boot.axf and sprite.axf?
<furan>
oddly their purposes are switched inside them. boot.axf does all the graphics and sprite.axf is responsible for serving livesuit commands
<arokux_h>
sun5i has debug-macro.S, but then for some weird reason isn't using it and wipes out the existing early_printk and writes to the UART directly.
<hno>
probably. standard 16550 interface also have something for handling full FIFO.
<hno>
probably. standard 16550 interface also have something for handling full FIFO.
<hno>
furan, no, all allwinner boot code is considered sensitive intellectual property by Allwinner.
<hno>
furan, the SDK do include the tools needed for building an image.
<hno>
but if you prefer hexedit then by all means. Just don't forget to check the "format nand" checkbox.
ZaEarl has joined #arm-netbook
<furan>
hno: it is just that I must edit the axf in order to add support for a different nand chip
<furan>
I will build an image with it + my rom
<furan>
can you tell me, how is the partition stuff described in the image?
<furan>
I have an expanded image I'm looking at
<arokux_h>
hno, will you tell me smth more about UART before I go to bed? (just asking)
<hno>
I really should be in bed..
<furan>
thanks for your help
<arokux_h>
thanks from me too.
<arokux_h>
let's go sleep!
<arokux_h>
good night.
arokux_h has quit [Read error: Connection reset by peer]
penguin42 has quit [Quit: Leaving.]
tuliom has joined #arm-netbook
<furan>
can someone tell me how partitions are described in an allwinner image?
tuliom_ has joined #arm-netbook
tuliom has quit [Ping timeout: 276 seconds]
tuliom_ is now known as tuliom
tuliom is now known as tuliom_
revident has quit [Quit: Combustible lemons? Bah, I bring you weaponized asparagus!]
ZaEarl has quit [Read error: Connection reset by peer]
Boulet has joined #arm-netbook
tuliom_ is now known as tuliom
<Boulet>
hi
Boulet has quit [Remote host closed the connection]
Boulet has joined #arm-netbook
tuliom is now known as tuliom_
tuliom_ has quit [Quit: Konversation terminated!]
gimli has joined #arm-netbook
ZaEarl has joined #arm-netbook
DEAT_ has quit [Read error: Connection reset by peer]
tzafrir_laptop has quit [Ping timeout: 248 seconds]
<Boulet>
damn i can't catch this IRQ
<Boulet>
hno, RaYmAn, any idea where the interrupt vectors are located ?
<Boulet>
it seems it is at address 0 by default
<Boulet>
the interrupt controller seems to be able to specify the address of the vectors, but i am not sure, and cannot find the use of it in the linux source code
<Boulet>
uboot does not use any interrupts it seems like...
Boulet has quit [Read error: Connection reset by peer]
Boulet has joined #arm-netbook
Dibblah has joined #arm-netbook
<Dibblah>
Oddest behavior on ak802 - Plug it in, allow it to start up and it kills an ADSL connection that's 5 meters away. Replace untwisted ADSL cable with twisted - no more interference. Very, very odd.
<RaYmAn>
hno: erm. So I'm having trouble getting ANYTHING useful out of the place where those registers should be. :(
steev has quit [Remote host closed the connection]
Hexxeh has quit [Remote host closed the connection]
Holo_ has quit [Remote host closed the connection]
Ralf has joined #arm-netbook
<Ralf>
Hi, I have connected UART of my Mele A2000 to my laptop but now I only get cryptic output from it
<Ralf>
like "hÂtBa«$ÿ°¾þv½[3?¨³¶+"
<Ralf>
what am I doing wrong
<RaYmAn>
are you setting your terminal emulator to the right baud rate?
<Ralf>
I don't know to which baudrate should i set it?
<RaYmAn>
115200 is usually ok
<Ralf>
ah thx
<Ralf>
:D
<Ralf>
that worked :)
steev has joined #arm-netbook
penguin42 has joined #arm-netbook
arokux_h has joined #arm-netbook
<arokux_h>
does smb have a long (500 pages) datasheet of A10? I'd be glad to have it too :)
hehopmajieh_ has joined #arm-netbook
hehopmajieh_ has quit [Remote host closed the connection]
Ralf has left #arm-netbook [#arm-netbook]
<hno>
RaYmAn, cp14 registers?
<RaYmAn>
hno: yeah.. As far as I can tell they *should* be accessible over memory mapped registers at the debug port
<RaYmAn>
but everything is 0
<arokux_h>
hno, you have the datasheet, right? at least you could tell where do you have it from...?
* RaYmAn
ponders if replacing nand u-boot with a 44-byte app that sets up pinmux and loops forever is a poor idea
<hno>
arokux_h, yes I have the datasheet, under indirect NDA agreement.
<hno>
some others here have it as well.
Dibblah has quit [Ping timeout: 260 seconds]
<arokux_h>
hno, from hipboi?
<arokux_h>
I wonder what it the meaning of the aw_ prefix to function and define names.
<Marex>
RaYmAn: btw. about the wifi issue ok mk802, did anyone solve it ? I pulled the antena out of the casing, seems to work, but far from elegant
<Marex>
RaYmAn: thanks :)
<RaYmAn>
I dunno
<RaYmAn>
I haven't used my mk802 for anything serious =P
<Marex>
RaYmAn: me neither ... just needed the wifi to work better than 100kbps ... got to 12Mbps after the fixup
<specing>
Oh I see Marex got himself an A10
<specing>
:)
<Marex>
specing: well hello, I recall your nick somewhere :)
<Marex>
#u-boot maybe ?
<Marex>
yep ;-)
<Marex>
specing: efikamx didn't cut it ... so I went for the easier solution
<Boulet>
RaYmAn, would you know where the interrupt vectors are located ?
<RaYmAn>
Boulet: presumably at 0x0? if not, I dunno.
<Boulet>
i think so too, but not 100% sure
<specing>
interrupt vectors could be in a seperate SRAM space internal to the A10?
<Boulet>
i don't know, it seems the interrupt controller can specify the address of the vectors
<arokux_h>
how are you using your MK802?
<Marex>
arokux_h: since I'm mostly not at home, I plan to use it instead of the cisco ip phone to telco with my parents ... so far I didn't get webcam working, thus my interest in fixing the kernel
<Marex>
Boulet: the arm vectors can be at 0x0 or 0xffff0000 ... the intc vectors can be at arbitrary address I guess
<Marex>
(but that depends on the controller ... whta does a10 use, that arm intc?)
tuliom has joined #arm-netbook
<arokux_h>
Marex, what about touchscreen? or screen/keyboard?
<Boulet>
Marex, i have no idea what intc they use :(
<Marex>
arokux_h: genius thumbmouse seems sufficient for the task
<Marex>
Boulet: looks like they didn't roll out any reasonable datasheet, right ?
<RaYmAn>
documentation is extremely sparse for allwinner socs =P
<Marex>
RaYmAn: that's the sad part ... same thing the olimex guys said about the a13 too :(
<Boulet>
marex, but you could be right, it is still at 0xffff0000
<Marex>
Boulet: yep ... that seems like arm vectors :)
<Boulet>
but i don't see that the vectors address become 0 when that high vectors bit is cleared
<Marex>
Boulet: you need to load code to 0, then issue some exception ... it'll jump there
<Marex>
(reset will clear the bit too, but I guess the A10 has some bootrom or loader that executes before user code and sets the bit back)
<Boulet>
yeah it jumps to 0xffff0000 by default
<Boulet>
if i issue some exception it will jump to the corresponding vector at 0xfff000xx right ?
<Marex>
Boulet: yes, but not from linux userland (linux handles and traps those)
n6pfk has quit [Quit: Leaving]
<Marex>
Boulet: on the bare hardware, yes
<Boulet>
yeah i am talking about bare hardware
hehopmajieh_ has joined #arm-netbook
<hehopmajieh_>
Mazon: hi, are you here :)
<Marex>
Boulet: can you load code to 0 at all? maybe the bootrom is mapped there and you can't rewrite it ... so you'd have to turn on MMU and remap some page there
<Boulet>
yeah, 0 is location of internal sram, we can put some code there
<Boulet>
you mean after MMU is on, i should remap 0xffff0000 to 0 ?
<Boulet>
hum
<Marex>
Boulet: you can remap any page to 0 by properly configuring the mapping
<Marex>
Boulet: and then you flip off the high vectors bit
<RaYmAn>
bootrom is mapped to 0xffff0000
<Marex>
RaYmAn: so you want to steal control from bootrom ? :)
<Marex>
what for ?
<RaYmAn>
I want to dump boot0/boot1
<RaYmAn>
:)
<Boulet>
RaYmAn, not stealing, just relocating interrupt vectors :)
<RaYmAn>
Boulet: I don't care about relocating interrupt vectors really
<RaYmAn>
:P
<Boulet>
and we of course cannot modify the vector address at 0xffff0000
<Boulet>
you don't, i do ;)
<Marex>
then just loading some code to 0 (if it's SRAM) and turning off the high vectors bit si enough
<Boulet>
marex, but if the high vectors bit is cleared, the vector address is automatically 0, right ? then no need to enable MMU ?
<Boulet>
right
<Boulet>
ok
<Boulet>
now i need to figure out how to clear that bit
<Boulet>
with that p15 register
<Marex>
it's in cp13 ?
<Boulet>
i think cp15
<Marex>
ah ... mrc or mcr instruction
<Boulet>
right
<Marex>
Boulet: check uboot's start.S, lot of usage there
<Marex>
arch/arm/ <any start.S there>
<Boulet>
yes i see some stuff for cache, mmu..
<RaYmAn>
Marex: in practice, It doesn't seem like reset vector is actually honored (or rather, it's reset) on reset
<RaYmAn>
at least on all Cortex cpu's i've looked at
<Boulet>
oh what do you mean?
<specing>
reset should point to the internal boot rom?
<RaYmAn>
when issuing a reset it always points at internal boot rom
<RaYmAn>
hence ignoring what you set the reset vector to.
<Marex>
RaYmAn: well, it jumps to 0, bootrom does the remaining magic
<Boulet>
specing, yeah ... when the chip goes out of reset, if you want a chance to load your code from somewhere
<Boulet>
except if the code executes from flash i guess
<Marex>
Boulet: no, we have a chip here that -- even if booted from nor flash -- executes bootrom first anyway
<hno>
Boulet, u-boot sets the interrupt vector
mikey_w has quit [Remote host closed the connection]
<hno>
Marex, A10 always executes boot rom first.
<RaYmAn>
hno: any clue on where to look for boot0/boot1 in memory? :S
<Marex>
hno: hi
<Boulet>
hno, where is that ?
<Marex>
hno: not only a10, too many chips do these days
<Marex>
(actually all of those that have one ;-) )
<RaYmAn>
I've dumped all of sram, but I at least can't find the header (ok, so i guess it's not impossible the header is stripped?)
<hno>
RaYmAn, boot0 is loaded into SRAM (0-something)
<hno>
but you need to catch it early. First couple of KB is overwritten later.
<Marex>
hno: I think if you connect BDI2000, you can stop the execution even before bootrom (if the bootrom isn't well written ... so that's not the case for 100% cpus)
<RaYmAn>
yeah, that's my issue =P
<hno>
so RaYmAn don't the procedure I outlined yesterday work? SD boot a small piece of code that reprograms PF to JTAG and the loops infinitely. Then attach JTAG, set a breakpoint @0, change PC to FFFF4000 and resume CPU execution.
madmalkav has joined #arm-netbook
<RaYmAn>
hno: I haven't tried that quite yet. I've replaced u-boot.bin with something that does that. In the hopes I'd at least be able to dump boot1
<hno>
boot1 is in DRAM somewhere.
<RaYmAn>
yeah
<Marex>
hno: btw. are you planning to submit the uboot patches to uboot ML ?
<RaYmAn>
hno: one issue though - brom changes pinmux in order to check sd
<RaYmAn>
I mean, if I resume at 0xffff4000
<hno>
Marex, core support yes. But need to figure out what broke SPL in later versions first.
<Marex>
broke SPL ?
<hno>
RaYmAn, right.. so you may need to debug BROM a bit to skip SD check. Or hope that OpenOCD do not get too confised by briefly seeng som SD signals.
<hno>
Marex, if I merge the sunxi changes to u-boot 2011.11 or later then SPL no longer works.
<Marex>
hno: try the ToT version please ... don't stick with ancient crap
<Marex>
hno: why do you need the SPL at all though ?
<Marex>
doesn't your chip init all the DRAM and stuff via bootrom?
<hno>
The chip do not initialize DRAM at all.
<hno>
the boot rom only loads boot code into SRAM.
<Marex>
I see
<Marex>
I recall someone told me he has some crazy binary blobs that do some random goo to init all that
mikey_w has joined #arm-netbook
<Marex>
hno: so you now managed to boot right off the bootrom?
<hno>
Ofcourse the issue is the same with current u-boot development version. I said 2011.11 or later.
<Marex>
hno: so ... stick with mainline when debugging it ... need some help with it ?
<hno>
Marex, hipboi kindly contributed the MMC u-boot version with SPL and everything. Can't take much credit for it.
<Marex>
hno: well ... if you need help debugging the issues, ping me, I should be around eventually
<hno>
Marex, you are welcome to help debugging it. Got kind of stuck last time.
<Marex>
hno: so, did you configure the SPL link address properly ?
<hno>
breakage gets worse the more current u-boot version I try.
<Marex>
hno: there were some severe changes in the uboot recently and more are to come ... so it might have broken some out of tree code
<hno>
2011.11 can be made to work sort of, but UART output somehow gets held up.
<RaYmAn>
hno: could be initialization order changes like in test1?
<hno>
in later versions I haven't even been able to get UART running.
<hno>
RaYmAn, it configures all clocks first, including gating. Then sets up UART registers.
<hno>
s/gating/gating and PIO
<RaYmAn>
ah.
<Marex>
hno: isn't there some generic uart IP? like that arm pl01x ?
<hno>
But feels like it's crashing before.
<Boulet>
ok, now my interrupts work :o)
<RaYmAn>
do you have the merged source anywhere?
<Boulet>
thanks for the tips marex !
<RaYmAn>
wip/update?
<hno>
Marex, the UART is 16550 compatible, nothing strange there. But clock generator needs to be configured to enable the clock.
<Marex>
hno: do you have some LEDs to debug it ?
<Marex>
GPIO controlled at best
<hno>
and pin mux configuration also needs to be configured to route the UART signals out on the right pins.
<hno>
I bit short on leds, but have plenty of pads available for GPIO.
<hno>
and should also have a JTAG probe in my mail at home.
<Marex>
hno: let's do it the easy way ... you think the software gets stuck, right ?
<hno>
and RaYmAn figured out how to get OpenOCD to talk to A1X.
<Marex>
hno: so ... toggle the led off at the begining, toggle it back on just before you think it gets stuck ;-)
<Marex>
hno: usually you can bisect code that way too
<Marex>
RaYmAn: that's nice ... it's also good to see the bootrom doesn't interfere :)
<RaYmAn>
u-boot is hell to debug with jtag, but I'd imagine SPL would be easy enough (relocation is a pain :P)
<Marex>
RaYmAn: uboot is easy to debug with jtag, Linux is worse ... why is it problematic ?
<Marex>
RaYmAn: ah ... the relocation
<hno>
Marex, I do not have a led that is easily programmed.
<RaYmAn>
I've tried most "guides" on how to handle the relocation but not having much luck
<Marex>
RaYmAn: if you can connect GDB, it's really only a matter of add-symbol-file
<Marex>
hno: :-(
<Marex>
hno: GPIO and a meter maybe ?
<RaYmAn>
yeah. I tried that, not really had any luck.
<RaYmAn>
I might be getting the relocation offset wrong, I dunno
<hno>
Marex, yes, but not today.
<Marex>
RaYmAn: ah!
<Marex>
RaYmAn: do sed -i "s/debug/printf/" arch/arm/lib/board.c
<Marex>
RaYmAn: then there's one line which tells you the offset when you run it
<RaYmAn>
yeah.
<RaYmAn>
Been there, done that
<Marex>
444 debug("relocation Offset is: %08lx\n", gd->reloc_off);
<Marex>
this one ...
<RaYmAn>
I did just notice I missed the += TEXT_BASE note
<RaYmAn>
so that might be my issue
<hno>
RaYmAn, I would be perfectly happy with instruction level debugging for the SPL issue. No need for source when most of the problematic areas is asm anyway.
<Marex>
ah that's right ... though I'm not sure if the reloc_off is already with this value added or not
<Marex>
hno: the asm only sets up stack, nothing more
<RaYmAn>
hno: source level debugging works fine out of the box as long as there's no relocation going on :)
<Marex>
hno: then board_init_f might cause trouble if your link addr is misconfigured
<RaYmAn>
u-boot.map: 0x4a000040 _TEXT_BASE
<RaYmAn>
I guess I need to add 0x40 to relocation offset
<hno>
Marex, I had to back out the interrupt vector changes to get 2011.11 to work.
<hno>
same as for TEGRA.
<Marex>
hno: you also hack on tegra ?
<hno>
Marex, no. I had to do the same #ifndef workaround as TEGRA.
<Marex>
hno: meh ... tegra is crazy piece of hardware
<RaYmAn>
indeed
<hno>
But honestly haven't looked at it in a while now. Been buzy with fel stuff.
<Marex>
FEL ?
<RaYmAn>
though, lately they have much better (public) documentation than allwinner does :P
<Marex>
RaYmAn: yes? I had to sign some ugly NDA for T20
<RaYmAn>
okay, so semi-public
<hno>
Marex, FEL is the other piece of the boot rom, allowing you to bootstrap the CPU over USB.
<RaYmAn>
but anyone can get it
<hno>
RaYmAn, I can't if the NDA is ugly.
<Marex>
hno: :-)
<Marex>
hno: not as ugly as the Marvell NDA ... that's still way uglier
<hno>
Have not read either NVidia ot Marvell NDA documents.
<hno>
I did read an Allwinner NDA.. that was funny reading.
<Marex>
hno: of your ... you couldn't have, the marvell NDA is under NDA too
<Marex>
s/your/course
<hno>
Marex, so you need to sign another NDA to read the NDA?
<Marex>
just by reading further than the header, you agree to the first-stage NDA
<hno>
Marex, no signature needed?
<RaYmAn>
you can't actually get to the NDA right now for tegra, heh
<Marex>
hno: I didn't get past first stage ... I gave up after seeing the insane requirements
<RaYmAn>
hno: interesting tidbit: 1) In fel MMU is enabled. 2) When loading "SPL" off sd, MMU is disabled
<hno>
RaYmAn, yes, MMU is off in normal boot process.
<hno>
that's why the boot0 process I outlined uses SD booting to get the CPU halted in a state where BROM likely can be restarted without too much trouble.
<RaYmAn>
yeah, I'm in there now
<arokux_h>
hm.. why do you need to poke around this booting stuff, if A10 boots successfully already?
<hno>
arokux_h, we are looking for some hardware parameters which livesuite recorded in boot0 when programming the flash.
<arokux_h>
hno, you would like to be able to flash the device?
<hno>
arokux_h, we intend to extend u-boot SPL to also work from NAND, not only MMC.
<hno>
but the parameters have nothing to do with NAND as such.
<hno>
more DRAM and system clocks.
<Boulet>
hno, won't you need to have a mean to read/write from/to nand in uboot ?
<arokux_h>
I see. thanks.
<hno>
Boulet, working on that too.
<hno>
well, we do have driver for full access to the logical nand block device. But not the boot blocks.
<Boulet>
then you can also get boot0 that way
<hno>
boot0 is in the boot blocks.
<hno>
boot1 as well.
<Boulet>
i mean there are some code that reads the physical blocks of the flash
<hno>
Yes.
<RaYmAn>
Boulet: do get it working
<RaYmAn>
:P
<Boulet>
:o)
<Boulet>
i know it is easy to say
<hno>
I tried. And got 512b random garbage and 3.5K zeroes on each read.
<hno>
or was it 7.5k zeroes, don't remember.
<Boulet>
yeah i think the pages are 2048 bytes and there are some oob data containing ECC and such
<hno>
Yes there is OOB data in NAND flash.
<RaYmAn>
ok, so boot1 seems to be loaded at 0x42400000
<arokux_h>
hno, hm.. but the allwiner's uboot should already contain the code to boot from NAND, or?
<Marex>
hno: how can anything prevent you from reading the whole NAND ?
<Boulet>
nothing, for sure
<Boulet>
but just have to play with the code we have, not that trivial i guess
<hno>
Marex, it's not actively preventing. Just not very well documented.
<Boulet>
if you can read a particular page of a particular block, indeed you can read the whole flash
<Boulet>
the brom has those routines, we could certainly use fel's routine, if we knew where it was
<Marex>
hno: :-(
<hno>
User Guide documentation on the NAND controller is basically "There is a NAND controller".
<Boulet>
i would think allwinner put some stuff to also write a NAND block from FEL, because it would be so convenient in factory
<hno>
Boulet, it loads lots of code in FEL.
<Marex>
Boulet: you really don't want to call bootrom routines from uboot
<hno>
Time to go. Rest of family arrived with the boat.
<Boulet>
Marex, just to dump that boot0 block haahha
<Boulet>
see ya hno
<arokux_h>
Marex, what's about a display for MK802?
<Marex>
what do you mean ?
<arokux_h>
Marex, which display do you normally use with it?
<Marex>
arokux_h: some samsung TV
<arokux_h>
and it's normally could be found at the place where u'll be?
<Marex>
arokux_h: nope
<arokux_h>
Marex, that's why it's kind of hard to make use of such a device, imho
<Marex>
arokux_h: what do you mean ?
<RaYmAn>
Marex: know of any way to get gdb to ignore that it doesn't have a symbol file and just disassmble the instructions it has as you stepi through them?
<Marex>
RaYmAn: isn't that the default behavior ?
hehopmajieh_ has quit [Ping timeout: 268 seconds]
<RaYmAn>
0xffff4020 in ?? ()
<RaYmAn>
(gdb) stepi
<RaYmAn>
0xffff4024 in ?? ()
<RaYmAn>
apparently not..
<Marex>
aaah :)
<arokux_h>
Marex, you cannot use MK802 if you do not have it connected to the display, or?
<RaYmAn>
you could run it headless..
<Marex>
arokux_h: I think I'll get another one ... I'll leave this one at home
<Marex>
arokux_h: the whole point was to use it as a videophone, but it still has a bit of a way to go
<arokux_h>
Marex, an Android smartphone couldn't be used as a videophone?
<Marex>
arokux_h: this device is way cheaper ... and the big screen is already there ;-)
<arokux_h>
ok :)
<Marex>
RaYmAn: try set disassemble-next-line I think
<RaYmAn>
perfect, ty
hehopmajieh_ has joined #arm-netbook
QingPei has joined #arm-netbook
hehopmajieh_ has quit [Ping timeout: 246 seconds]
hehopmajieh_ has joined #arm-netbook
hehopmajieh_ has quit [Ping timeout: 252 seconds]
<arokux_h>
how big and quick is A10 NAND, btw?
<arokux_h>
(speed in comparison to MMC)
<RaYmAn>
most devices have 4GB
<specing>
of which only 2GB is available
<specing>
arokux_h: Why dont you test it?
<arokux_h>
I'm currently busy with other things like reading kernel sources and do not even know what the name of nand device is..
<specing>
You're currently busy with asking questions ;)
<arokux_h>
no, not only )
<arokux_h>
but you are right, I ask more then the others here..
<rz2k>
when they go active, we will be pretty fucked up. :/
<Turl>
techn: doesn't crash? :P
<techn>
Turl: noup.. :)
<arokux_h>
rz2k, maybe we could delete their accounts before they go active? :)
fjzz has joined #arm-netbook
<techn>
Turl: but dunno if there is regression somewhere ;)
<rz2k>
mnemoc is on vacation and I dont remember who else is admin on wiki
<Turl>
I can admin too rz2k
<Turl>
rz2k: blocked one of 'em, if they used the same IP they'll die when they go live
<Turl>
if you notice people spamming let me know and I'll clean it btw
<fjzz>
Could somebody\ anybody give me a working 'recovery.ini' file
<fjzz>
Or at least point me to one?
hehopmajieh_ has joined #arm-netbook
Boulet has quit [Quit: zzzzz]
<hno>
RaYmAn, congratulations!
<hno>
and my package had arrived in good condition.
<RaYmAn>
Cool :)
<hno>
so at least that part in the TNT handling was correct.
<RaYmAn>
where did they deliver it then?
techn_ has joined #arm-netbook
<hno>
probably in my mail box, which my neighbours emptied.
<hno>
it's only a large envelope.
<RaYmAn>
ah
Quarx has quit []
techn has quit [Ping timeout: 256 seconds]
<steev>
RaYmAn: what you're looking for is in the Kconfig
<Marex>
steev: oh, you're here too ? :)
<steev>
Marex: of course
<Marex>
steev: is Neko's period over already ?
<steev>
his might be, is yours?
<Marex>
steev: mine was never there ... I just try hate his bullshit approach
<Marex>
steev: btw the mk802 works better than efikamx for all I need :)
<steev>
good to hear :)
<steev>
RaYmAn: in the arch Kconfig that is, for selecing the nand
<Marex>
steev: the community around efika isn't as lively as here ... I wonder why
<steev>
Marex: i'm not about to fight about it here
<steev>
that is way off topic for this channel
<Marex>
steev: indeed ... just think about my final remark
<steev>
Marex: no need to. but anyway, does this mean you're going to start up a u-boot-allwinner on denx? :D
<WarheadsSE>
arent the efika imx53?
<steev>
WarheadsSE: no, 51
<WarheadsSE>
k
<WarheadsSE>
idk, none have been brought to #archlinux-arm
<steev>
the 53 board is only for custom designs
<steev>
mm, i thought a couple people in Arch have them
<Marex>
51 -- shitty chip ; 53 -- fixed version of 51
<Marex>
steev: I ain't mucking with the stick unless necessary ... but I can throw some advice
<Marex>
steev: looks like hno is already working on uboot port, so I might as well help upstreaming it
<steev>
heh
<steev>
Marex: :D
<WarheadsSE>
steev: not the core devs
<WarheadsSE>
Marex: the uboot is working decent, for the A10, and they mostly seem to have it working for A13
<Marex>
WarheadsSE: the problem is the control freak of Neko kicked into high gear with efikamx ... and the ancient kernel there (.32), the lack of proper VPU libraries and ... lack of community for the efikamx
<Marex>
but, it did it's job, we now have armhf debian
<WarheadsSE>
VPU
<Marex>
WarheadsSE: I know about uboot ... but pushing it mainline would be even better ;-)
<WarheadsSE>
otherwise, shouldnt be *that* horrible to port it forward
<Marex>
WarheadsSE: I'll wait for hno to muck with it again and try steering him in the right direction so he can progress quickly
<WarheadsSE>
:)
<WarheadsSE>
had him tack in uEnv
<WarheadsSE>
handy
<WarheadsSE>
my users all too often = derp
<Turl>
has anyone other than lundman used wemac? :P
<WarheadsSE>
?
<Turl>
trying to figure out what's the max perf you can squeeze out of the ethernet on Mele
<WarheadsSE>
hmm
<Turl>
but I'm too lazy to wire the mele to my PC directly and do perf testing :P
<WarheadsSE>
I've capped it around 10MB/s so almost 100Mbps
<WarheadsSE>
it's not hooked up at the moment, so idk
<Turl>
I got like 8,somethingMB/s using NFS
<Turl>
might be the WiFi limiting it
<WarheadsSE>
that wifi will probably cap arouns 72Mbps
<Turl>
I'm linked at 150Mbit/s "RX Rate" and 120Mbit/s for "TX Rate" according to LuCI
<WarheadsSE>
yeah, but sometimes throughput might not match
<Turl>
yeah
<WarheadsSE>
idk, I've been using it exclusivly wired
<Turl>
at least what I get is faster than wifi G :P
<arokux_h>
does anybody know why there are so many clocks and why they have parents and brothers? :$
<RaYmAn>
steev: ...
tzafrir_laptop has joined #arm-netbook
<penguin42>
arokux_h: It's not unusual to divide one clock off another, which is why you get parent/child relationships
<penguin42>
arokux_h: And on some systems you can shut them off to save power - but that's going to shut off the children as well, which might be a bad thing if you need the clock below it to be able to switch back on
<arokux_h>
penguin42, why just one clock is not enough?
<Marex>
because you need different speeds for different peripherals
<Marex>
say 400kHz for i2c, 24MHz for SPI etc.
<Marex>
also, you want to be able to control clock domains to save power ^^
<arokux_h>
are there some docs on it?
<specing>
arokux_h: you can read any cortex-m3/m4 datasheet to get a roughly simplified idea
<Marex>
arokux_h: depends on the chip
<arokux_h>
Marex, I see, I just need a broad overview.
ibrah has joined #arm-netbook
<arokux_h>
I've found a presentation "A Generic Clock Framework in the Kernel: Why We Need It & Why We Still Don't Have It" but it not much...
<RaYmAn>
arokux_h: you probably need to read up on basic EE. as far as I know this kind of clock requirements really arise from there. It's a lot more complex in these kind of units of course, but yeah.
<hno>
RaYmAn, can you try help techn how to make a pull request in github when he comes back?
<RaYmAn>
hno: will have to be tomorrow probably, but sure
lkcl has quit [Ping timeout: 246 seconds]
penguin42 has quit [Quit: Leaving.]
<RaYmAn>
hno: techn_: it really is just pressing the "pull request" button, selecting head repo and branch as your own, then selecting amery repo & branch as base, and *poof* :) github rocks!
just4dos has joined #arm-netbook
<hno>
Ah, he is here with a _, didn't notice.
<hno>
had a priv message from him without _
<RaYmAn>
hmm..so this booting over fel thing isn't the most stable of things :P. I suspect doing two fel write's too close to eachother causes corruption or similar
gimli has quit [Remote host closed the connection]
<Marex>
RaYmAn: github is terrible :-( it still pesters you with flash .swf goo popping up
<Turl>
flash? where Marex? o.O
<RaYmAn>
yeah, I was wondering that too
<arokux_h>
does x86 has also this clocking business?!
<Marex>
did they fix it ?
gimli has joined #arm-netbook
<Marex>
no, it's still there ... clippy.swf
<Marex>
happens in konqueror without adobe crap installed ... all the time
<Marex>
firefox masks it away somehow
<Turl>
Marex: ah it's probably the 'copy URL' stuff
<Marex>
Turl: well ... it's broken ;-)
<Turl>
I don't recall any way to copy stuff using JS
<Turl>
so that's why they use flash :P
<Marex>
so it's broken ;-)
<Marex>
I don't have flash installed, so it's annoying
<Turl>
just flashblock all the things ;)
<Marex>
why? that's fixing a problem at a wrong place
<Turl>
keyword: fix
<Turl>
:P
ibrah has quit [Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120717123905]]
<hno>
arokux_h, only a handful number of people know how to bootstrap x86 from bare metal. But yes, there is clock generators for cater for there as well.
<arokux_h>
hno, I'm reading mach-sun4i/clock/* and try to understand clocking in general and check if it is done in upstream way.
<hno>
that needs a bit of cleanup, but isn't too bad compared to most other drivers.
<hno>
s/other/other sunXi/
<ibot>
hno meant: that needs a bit of cleanup, but isn't too bad compared to most other sunXi drivers.
<arokux_h>
hno, there is some clkevent framework, but sun5i isn't using it. this code is in #ifdef 0 clauses.
<Marex>
arokux_h: might be better to study up on drivers/clk/mxs/ instead ... that's quite fresh code
<arokux_h>
Marex, first I try to understand what sun5i is doing, next check the leading upstream architectures. last step should be a rewrite of sun5i (if needed). that the theory.
<arokux_h>
hno, does this 500pages manual contains something on clocking?
<Marex>
arokux_h: I'd go the other way -- figure out how it works upstream and then try to adapt the manufacturers crapcode to it
<Marex>
;-)
<arokux_h>
Marex, do you know some good upstream examples?
<Marex>
just told you one ... drivers/clk/mxs/
<Marex>
all that happens afterwards is that you do clk_prepare clk_get etc.
<hno>
arokux_h, yes some.
<Marex>
arokux_h: there's also some documentation in Documentation/clk.txt
<arokux_h>
oh, that's useful
<hno>
RaYmAn, the board boots. Have not tried fel yet.
<hno>
mnemoc, my power button seems to work. Powers off if I hold it for ~10 sec, and powers on on ~1sec press.
<Turl>
hno: that's how it works on tablets
<furan>
how do I repack an img using unimg?
<furan>
(let's say I unpacked it using unimg, did nothing, and now I want to repack it)
<Turl>
furan: unimg just unpacks afaik
<furan>
ok. author said it repacks on a forum but didn't say how
<hno>
Turl, that's how AXP works. But mnemoc claimed the power button on his board did not work.
<hno>
furan, why don't you use the SDK tools for packing the image?
<furan>
I have no good reason not to, this is just my first time making one
<Marex>
hno: btw can't the livesuit protocol be sniffed by installing windows into virtual machine and then sticking usbmon underneath ?
<hno>
Marex, that's what we did.
<furan>
awesome that works great, thanks
<furan>
does livesuit do any crc stuff?
<furan>
say if I hexedited one of the files?
<Marex>
hno: but the problem is the encryption ? :-(
<hno>
no
<Marex>
hno: so what's the problem then ?
<hno>
livesuit USB traffic is not encrypted.
<Marex>
hno: according to the wiki, there are no linux tools
<hno>
Marex, there is no linux tools for working with livesuit images. Have no big interest in those.
<Marex>
hno: I see
<hno>
I have already written a tool for talking to the FEL rom and RaYmAn succeeded in booting Linux that way.
<hno>
which means we can now boot Linux in at least 4 different ways
<hno>
a) Allwinner bootloader from NAND
<hno>
b) MMC u-boot
<hno>
c) JTAG
<hno>
d) FEL-USB
<CIA-121>
rhombus-tech: Kuo master * rb79bb9ea3e1e /allwinner_a10/orders/fluidfish.mdwn:
<Marex>
hno: cool :-)
<hno>
But we are still not 100% sure on DRAM setup parameters for A13. Those are auto-detected by livesuit and recorded in boot0 when you flash the device that way.
<Marex>
hno: so that's why you need to read boot0 ?
<hno>
for A10 the DRAM parameters have traditionally been in script.bin and pre-recorded in boot0 within the image.
<hno>
yes
<Marex>
crazy hardware you have :)
<hno>
Not really. Crazy software dealing with the hardware.
<Marex>
I wonder how it can detect dram parameters in any way
<hno>
Everything except for clock rate can be detected.
<Marex>
the clock rate is kinda ... important ;-)
<Marex>
hno: btw. it can distinguish between ddr2 and ddr3 ?
<Marex>
the dram chips have no jedec interface, do they ?
<hno>
clock rate is defined in A13 images I think.
<Marex>
oh ok :)
<Marex>
I was just curious
<hno>
DRAM is just DRAM, so no jedec rom no.
<Marex>
hno: btw the width of a dram bus can't be determined accurately either
<Marex>
I mean the address and data bus
<Marex>
or it'd be something I wont trust myself at least
<hno>
you can try until you find one that works.
<Marex>
yea ... not the best way to do it :(
lkcl has joined #arm-netbook
<Marex>
I already shot myself in the leg with this approach
<hno>
agreed.
<hno>
we don't really know what livesuit does.
<Marex>
hno: heh :)
<arokux_h>
<hno> a) Allwinner bootloader from NAND: can I flash my linux distro rootfs to the NAND, so I do not use MMC?
<hno>
yes
<hno>
you can even repartition the nand if you like.
<hno>
but boot partition need to be FAT and contain boot.axf etc.
<hno>
the easiest way is perhaps to use the SDK to build an Linux image. It does support both Android and Linux images.
<arokux_h>
hm.. but wait, I'm planing to gradually test the ported kernel gradually, moving the sun5i code piece by piece. so the nand support won't be there at the beginning.
<arokux_h>
(ignore the first "gradually")
<hno>
arokux_h, we do have a 3.4 branch.
<arokux_h>
hno, yes, I'm working (i.e. will work) with it. as I understand it contains the absolute minimum it can.
<hno>
My -minimal- branches is absolutely minimum. But the normal branches have most drivers (all that have been ported to that version)
<hno>
odd.. both multimeter and CSO-nano gone missing. Do they party somewhere?
<hno>
s/CSO/DSO/
<ibot>
hno meant: odd.. both multimeter and DSO-nano gone missing. Do they party somewhere?
<arokux_h>
hno, were you able to boot your minimal kernel?
<hno>
yes.
<hno>
not useful for anything else however.
<hno>
why do you want a minimal kernel?
<arokux_h>
I want to do smth... <arokux_h> Marex, first I try to understand what sun5i is doing, next check the leading upstream architectures. last step should be a rewrite of sun5i (if needed). that the theory.
<arokux_h>
minimal -- because I want to gradually port it.
<arokux_h>
piece after piece
piezo has quit [Ping timeout: 248 seconds]
<arokux_h>
so the minimal kernel comprises the code that should be ported first
<hno>
arokux_h, what is your final goal?
<arokux_h>
1. learn as much as possible. 2. it would be nice to push something upstream.
<hno>
Ok, makes sense.
<hno>
same here, except that I currently focus on boot process.
<arokux_h>
hno, you seem to have ported from some different location as mnemoc did. In your code in arch/arm/mach-sun4i/clock/aw_clocksrc.c there is #ifdef CONFIG_HIGH_RES_TIMERS, whereas in mnemoc's #ifdef 0
tuliom has joined #arm-netbook
<hno>
arokux_h, this tree is from before the ICS code drop, Based on 2.6.36.
<hno>
whereas the current tree is based on the ICS code drop.
<arokux_h>
ICS code drop?
<hno>
I have not looked in detail how they differ.
<hno>
qware
<arokux_h>
current = mnemocs?
<hno>
yes. my tree is 3+ months old now.
<arokux_h>
hno, but I like it more :)
<arokux_h>
ok, thanks for the answer!
<hno>
arokux_h, not sure interupts works proper in my tree.
<arokux_h>
hno, is there a chance to get the minimal support merged upstream, once it's mainlined?
<arokux_h>
hno, I'm just thinking.. if kernel moves fast I'd be better to push upstream as soon as possible?
<hno>
sure hope so.
<arokux_h>
cool.
<hno>
but need to move to devicetree instead of script.bin etc. Should probably move all of PIO and clocks setup out of mach-sunXi for initial merge, that cuts it down much cleaner and those can be done in boot stage before starting kernel.
<hno>
iirc my minimal tree have no PIO configuration, reliying entirely on PIO to be configured by the boot loader.
hno has left #arm-netbook ["Lämnar"]
hno has joined #arm-netbook
tuliom has quit [Ping timeout: 276 seconds]
tuliom has joined #arm-netbook
<hno>
Annoying. Found the DSO-nano but not it's probe cable and multimeter still missing. How am I going to probe for JTAG signals?
<Turl>
hno: heh
<Turl>
LEDs? :P
<furan>
doesn't it use a headphone port
<furan>
start stripping wires
<hno>
yes, been thinking of doing just that.
<furan>
I have somehow made it so my device can't boot into recovery mode
<hno>
not even FEL?
<furan>
nope
<furan>
I have this project where I wanted to add nand, pin compatible, etc and I accidentally taped it on backwards
<furan>
so then I turned it off, it can still read the other nand, shows the logo,etc
<furan>
and I had already screwed up the boot and needed to flash it
<furan>
but now it won't go into fel
<hno>
do you have a hard FEL / u-boot button?
<furan>
yeah, I am pressing that, plugging in usb
<furan>
done it a billion times
<Turl>
you can use a FEL sdcard
<Turl>
try that
<hno>
it's very hard for a hard uboot button to fail.. it is a separate pin on the CPU and the CPU accesses nothing before checking that.
<furan>
is there a guide on making one? remember I can't get my cwm sdcard to boot