| 00:07.17 | *** join/#arm-netbook Guest57978 (~mike@c-71-63-115-202.hsd1.va.comcast.net) |
| 02:18.04 | *** join/#arm-netbook hp_ (~hp_@p5B38B2D1.dip.t-dialin.net) |
| 02:36.34 | *** join/#arm-netbook toxicpsion (~toxicpsio@out-ab-248.wireless.telus.com) |
| 03:53.44 | *** join/#arm-netbook QingPei (~qingpei@123.118.96.98) |
| 04:23.02 | *** join/#arm-netbook Danie2 (~Daniel3@CPE-120-146-97-206.lns9.cht.bigpond.net.au) |
| 07:34.44 | lkcl | specing: inexperience - lack of software knowledge. that's why they use ext4 not yaffs. |
| 07:35.17 | CIA-91 | rhombus-tech: Alix master * r0105b938e694 /allwinner_a10/orders/alix.mdwn: |
| 07:46.45 | specing | lkcl: any suggestions on the serial port thing? |
| 08:03.13 | specing | steev: ping |
| 08:15.52 | CIA-91 | rhombus-tech: hno master * rcdb0741051ef /allwinner_a10/hacking_the_mele_a1000.mdwn: Add RESET info |
| 09:08.21 | CIA-91 | rhombus-tech: hno master * ra2ee5eff39db /allwinner_a10/hacking_the_mele_a1000.mdwn: |
| 09:09.44 | CIA-91 | rhombus-tech: hno master * r18eace2a5247 /allwinner_a10/hacking_the_mele_a1000.mdwn: |
| 09:16.34 | Gumboot | Is yaffs really necessary? |
| 09:17.50 | Gumboot | I mean, there's a layer in most solid-state storage to manage wear levelling, which seems to overlap with what yaffs is trying to do. Wouldn't it be better to use a filesystem that avoided the horrible behaviours but didn't also mess around with things that weren't necessary? |
| 09:19.18 | Gumboot | I do wonder what kind of compromise exFAT implements. |
| 09:23.35 | specing | Gumboot: ext2 would be apropriate |
| 09:23.49 | specing | ext3 and ext4 are both journaling filesystems |
| 09:24.14 | specing | which means they first write data to the journal and then copy it to the destination block |
| 09:24.16 | mnemoc | ext4 supports disabling the journal |
| 09:26.48 | CIA-91 | rhombus-tech: lkcl master * rf6d43972c4af /: Merge branch 'master' of ssh://git.hands.com/rhombus |
| 09:26.59 | CIA-91 | rhombus-tech: lkcl master * ra11690cf4ca3 /allwinner_a10/orders/ (.mdwn benj.hebert): order processing cleanup |
| 09:28.57 | specing | see mount @ https://10.0.0.2/A10-MID/ |
| 09:29.19 | specing | eh |
| 09:30.07 | specing | see mount @ https://93.103.140.50/A10-MID/ |
| 09:30.12 | Gumboot | I never really got the point in a journal, anyway. |
| 09:30.32 | specing | internal IPs >_> |
| 09:31.10 | Gumboot | Now we know your secrets. |
| 09:31.37 | specing | :D |
| 09:32.29 | Gumboot | Is journalling a poor man's substitute for thinking about what you're doing, or is it meant to be a seek minimiser or something? |
| 09:33.19 | specing | journaling eliminates the risk of losing your data |
| 09:33.37 | specing | if e.g. the power goes out |
| 09:33.49 | specing | then it can restore the filesystem to a sane state |
| 09:34.02 | Gumboot | You can do that by thinking more carefully instead. |
| 09:34.27 | specing | How? |
| 09:35.19 | Gumboot | Ordering the things you change such that the disk is never in a dangerous state. |
| 09:36.28 | Gumboot | It's not really a concept any more complex than what you have to do with data structures in multi-threaded environments... but the other thread is "loss of power". |
| 09:38.09 | Gumboot | You can't do it for every type of filesystem. You couldn't do it for FAT, for example. |
| 09:42.12 | Gumboot | Actually, when I say you can't do it for FAT, I learnt that from someone who was doing research in getting as close as possible. I don't think the holes were enormous. |
| 09:45.52 | Gumboot | This also raises the question of the integrity of filesystems that pre-date journal or have journal disabled. Without journal, who has the fastest fsck? |
| 09:49.00 | specing | dunno, but my webserver^ sometimes gets stuck in fsck loops (ext2 on CF) |
| 09:49.35 | Gumboot | When last I used a journalling filesystem I could still reveal errors by forcing a proper fsck even after the journal had been replayed. |
| 09:51.13 | Gumboot | As I recall, when I was trying to figure out how to do that I saw a lot of "you don't need to", but evidently they were wrong. |
| 10:56.23 | specing | steev: ping |
| 11:27.24 | *** join/#arm-netbook penguin42 (~dg@tu006.demon.co.uk) |
| 12:24.37 | *** join/#arm-netbook eflatun (~eflatun@95.173.235.38) |
| 13:00.52 | hno | Gumboot, yaffs is needed on raw NAND flash. Absolutely not on SDCARD or similar. |
| 13:03.07 | specing | ext4 on raw NAND flash doesen't look sustainable at all :D |
| 13:03.45 | hno | Gumboot, journaling filesystems is actually mostly about ordering if you look at the implementation. Performance would be awful if you only used ordering. |
| 13:07.40 | hno | and with jounaling you can extend reliability to include consistent data. |
| 13:08.06 | hno | plus that it saves you from fsck:ing that 10TB filesystem after a sudden power loss or kernel panic. |
| 14:10.18 | Gumboot | hno: As I say, in my experience it doesn't save you from fsck; it simply offers an fsck which fails to run a full test in its default mode -- even when it really does need to. |
| 14:12.36 | Gumboot | I'd be particularly inclined to force a proper fsck after a kernel panic. |
| 14:15.44 | penguin42 | Gumboot: was this to a flash device? |
| 14:16.28 | penguin42 | Gumboot: I've heard it said that flash devices don't necessarily follow the semantics the journaling systems are expecting and thus the journalling isn't totally valid on them |
| 14:19.13 | ManoftheSea | can the EOMA68 A10 boot with PXE? |
| 14:19.38 | ManoftheSea | I don't remember if u-boot vs. custom linux kernel was settled, but do they both have the PXE option? |
| 14:20.28 | ManoftheSea | I'm thinking that's an easy way to hack on it, since a reboot will reload whatever new kernel easily |
| 14:24.58 | *** join/#arm-netbook mikey_w (~mike@c-71-63-115-202.hsd1.va.comcast.net) |
| 15:02.04 | A1Sheds | linux as PXE should work |
| 15:15.48 | *** join/#arm-netbook toxicpsion (~toxicpsio@out-ab-214.wireless.telus.com) |
| 15:18.15 | specing | I think uboot can do it |
| 15:18.22 | specing | otherwise, there is also coreboot |
| 15:19.43 | toxicpsion | hno: i see that you managed to dump BROM... got a copy of it somewhere? |
| 15:32.46 | A1Sheds | coreboot would just be a kernel as PXE, kernel and the kexec to other kernel |
| 15:33.40 | A1Sheds | yeah uboot can jump to a kernel and then you can kexec to another |
| 15:34.22 | A1Sheds | though some might argue that uboot could be considered a PXE/mini-OS |
| 15:35.29 | A1Sheds | has everyone seen http://kexecboot.org/about as well? |
| 15:39.46 | *** part/#arm-netbook ARE-TEE (~leebradbu@cpc20-stok15-2-0-cust539.1-4.cable.virginmedia.com) |
| 16:17.12 | hno | toxicpsion, see my github accoun |
| 16:18.14 | hno | A1Sheds, kexec is quite nice for a boot loader, but it's a way heavier hammer than u-boot.. |
| 16:18.41 | hno | and you still needa bit of bootloader to load the initial kernel. |
| 16:20.14 | toxicpsion | hno: see that you ended up with a copy of my flash .pcap ;) |
| 16:20.22 | penguin42 | hno: Well, why do you need the 1st boot loader? |
| 16:20.45 | hno | penguin42, because something needs to load the linux kernel. |
| 16:21.10 | hno | the A10 BROM can not do that on it's own. Linux do not fit in 24K. |
| 16:21.10 | penguin42 | hno: But what loads the uboot? There's no reason that the 1st kernel can't be loaded in the same way as the uboot |
| 16:21.40 | penguin42 | hno: But uboot does? |
| 16:21.42 | hno | penguin42, correct. The u-boot SPL loader could load Linux if you want. |
| 16:21.53 | hno | skipping u-boot. |
| 16:21.55 | penguin42 | hno: Ah ok, so it's just a sizeism - yeh fair enough |
| 16:22.18 | penguin42 | hno: I'm not sure if that limit exists on all platforms |
| 16:22.26 | hno | not only size, it's also a matter of configuring hardware such as DRAM. |
| 16:23.28 | hno | Neraly all platforms starts in similar manners with the CPU loading a tiny piece of code into SRAM or cache memory. |
| 16:24.04 | hno | Some like the Raspberry Pi boots in very convoluted ways. |
| 16:24.26 | penguin42 | hno: yeh I guess I'm forgetting how much setup for RAM is needed on modern hardware |
| 16:25.31 | hno | It's not very much setup needed, but it's some and it's most cost effective to do that step in software. |
| 16:26.21 | hno | plus that every OS wants to be booted in their own way. |
| 16:28.29 | penguin42 | Linux isn't too fussy, if you can get it into ram |
| 16:58.47 | *** part/#arm-netbook QingPei (~qingpei@123.118.96.98) |
| 17:48.45 | steev | specing: pong (fyi, i'm central (US) time) |
| 17:54.28 | specing | powers up flux capacitors |
| 17:54.35 | specing | steev: Did you get it to boot? |
| 17:54.49 | steev | specing: negative |
| 17:54.54 | specing | I've tried mine but all I've gotten is a black screen |
| 17:55.19 | steev | i've tried mine as well as the link that hno posted from mnemoc for his uboot and script.bin |
| 17:55.24 | steev | er, not uboot uImage |
| 17:55.33 | specing | And the command line? |
| 17:56.03 | steev | yeah, although i cheated and modified the include/configs/sun4i.h rather than edit it in uboot |
| 17:56.15 | steev | env |
| 17:56.25 | specing | https://93.103.140.50/A10-MID/ <- my tablet's /proc/cmdline is on there |
| 17:58.19 | CIA-91 | rhombus-tech: luis_miguel master * r10e27bf1d125 /allwinner_a10/orders/luismiruiz1__64__gmail.com.htm: |
| 18:01.26 | specing | steev: do you own a mele or a tablet? |
| 18:01.40 | steev | specing: tablet, LY-F1 |
| 18:02.23 | toxicpsion | steev: check /tools/sunxi_env_gen in uboot tree. modifying env vs having to recompile every time to test params. :P |
| 18:03.08 | steev | toxicpsion: interesting. i'd have to reboot either way, that said, my main machine compiles uboot in roughly 9 seconds |
| 18:03.31 | toxicpsion | well no worries then :P |
| 18:03.44 | steev | still good to know about :) |
| 18:21.02 | CIA-91 | rhombus-tech: Elkyn_Johan master * r5d4c19dc48ad /allwinner_a10/orders/johang.qf__64__gmail.com.mdwn: |
| 18:23.31 | CIA-91 | rhombus-tech: Elkyn_Johan master * r51075d35e75c /allwinner_a10/orders/.mdwn: |
| 18:47.12 | hno | steev, the script.bin is for mele. Won't work on a tablet. |
| 18:48.32 | hno | fixes default ubootä-mmc environment to load script.bin. |
| 18:54.53 | steev | hno: ah, okay |
| 18:59.10 | mnemoc | each device has it's own script.bin |
| 19:10.04 | mnemoc | v3.4-rc1 ... uh, is it me or this -rc1 came faster than usual? |
| 19:10.27 | zenitraM | steev: you can get your script.bin by mounting /dev/block/nanda on android |
| 19:11.43 | specing | what is in script.bin? |
| 19:12.03 | specing | It looks like a blob |
| 19:12.21 | mnemoc | it's script.fex in binary form |
| 19:12.42 | mnemoc | tells how each pin is going to be used |
| 19:13.16 | mnemoc | the generic sun4i kernel uses this info to initialize the board |
| 19:15.55 | mnemoc | there is an open source decompiler written in *cough* ruby *cough* and a closed source compiler for linux and windows.... but the format is trivial |
| 19:19.29 | mnemoc | https://github.com/amery/linux-allwinner/blob/linux-3.3-sun4i/arch/arm/mach-sun4i/pin/script.c |
| 19:25.39 | hno | mnemoc, there is no fixed schedule. Depends on what was in queue and linus mood of the day. |
| 19:27.22 | hno | uboot updated a bit in my github tree. |
| 19:30.20 | specing | mnemoc, hno, steev: I've dumped the boot partition on my webserver |
| 19:31.06 | specing | https://93.103.140.50/A10-MID/nanda-boot/ |
| 19:31.24 | specing | Have fun decompiling ;D |
| 19:31.42 | zenitraM | mnemoc: sorry for using not-ideal languages. my python is a bit oxidized and my C is, well, not enough |
| 19:31.54 | zenitraM | although i've also seen a *Java* decompiler somewhere |
| 19:32.00 | specing | D: |
| 19:33.02 | zenitraM | mmm there has to be *some* way to activate multiboot choosing on the bootloader |
| 19:33.23 | zenitraM | [system] |
| 19:33.23 | zenitraM | start_os_name = linux |
| 19:33.23 | zenitraM | timeout = -1 |
| 19:33.23 | zenitraM | display_device= 0 |
| 19:33.23 | zenitraM | display_mode = 0 |
| 19:33.55 | specing | looking at boot.ini? |
| 19:34.05 | zenitraM | there are also references to multi boot at boot on serial |
| 19:34.16 | zenitraM | and some trings on boot.axf |
| 19:34.21 | zenitraM | s/trings/strings/ |
| 19:34.23 | specing | So good, if only I found a serial port... |
| 19:34.53 | zenitraM | i didn't find any visible one on my tablet... |
| 19:35.49 | specing | zenitraM: So you are using the sd hack? |
| 19:35.58 | zenitraM | specing: yes |
| 19:36.02 | specing | D: |
| 19:36.29 | zenitraM | that's why i invaded /data instead of using storage on the sd |
| 19:37.01 | specing | Isn't /data vfat? |
| 19:37.37 | zenitraM | no, that's /sdcard |
| 19:37.43 | zenitraM | data is ext4 |
| 19:37.47 | specing | ah ok |
| 19:42.01 | hno | specing, why would I want to decompile your root partition? |
| 19:42.20 | hno | have more boot files than he needs already. |
| 19:43.26 | hno | Hm... adding usb support to u-boot may be more wotk than estimated. Seem the android u-boot A10 sources is not GPL compatible. |
| 19:49.14 | toxicpsion | *boos* |
| 19:50.05 | hno | sent a quetion to Tom to get clarification. |
| 19:51.34 | mnemoc | in the mean time.... jtag? :) |
| 19:52.16 | hno | Yes.. need to get that fixed. |
| 19:53.26 | toxicpsion | anyone know exactly what's broke with framebuffer console? |
| 19:53.44 | hno | not yet. Been kind of busy on other areas. |
| 19:53.58 | hno | like getting even the serial console to work. |
| 19:54.30 | hno | or actually any i/o at all in current kernels. |
| 19:54.51 | toxicpsion | :( |
| 19:55.43 | hno | It's confusing. I see where it go wrong, but from what I can tell the code looks just right. |
| 19:56.46 | toxicpsion | and where is that? |
| 19:57.22 | hno | It's when the MMU tables are initialized, and in just that area no I/O is available at all which makes debugging a little hard. |
| 19:58.26 | toxicpsion | little sounds like an uderstatement. |
| 19:58.42 | toxicpsion | understatement* |
| 19:58.46 | hno | there is a temporary MMU table map created early, which works. This is then torn down and replaced with the real thing and somewhere there things go real bad. |
| 19:59.11 | hno | Not out of ideas how to debug this. |
| 19:59.56 | zenitraM | given that tom has access to a working 3.0.8 source tree.. although he can't publish it, he might be able to, well, peek things out of it |
| 20:00.42 | hno | it's something stupid I am sure. |
| 20:01.27 | hno | but not sure what to ask Tom. The code looks good to me. |
| 20:04.05 | hno | will stare on it a bit more. But not with a 1 year old in my |
| 20:04.19 | hno | lap trying to steal the keyboard |
| 20:06.02 | hno | it's just 5 lines or so really, repeated 50 times. |
| 20:06.10 | toxicpsion | zenitraM: what tablet you using? |
| 20:09.48 | mnemoc | hno: might be related to https://github.com/amery/linux-allwinner/commit/dacd3a6bf29ca059a901f70b85d3f3dae777f407 ? |
| 20:11.17 | hno | Hmm... no idea what effects that may have. |
| 20:11.52 | hno | or why that is in the kernel and not the bootloader. |
| 20:12.33 | hno | mnemoc, where is the origin of that? |
| 20:14.52 | mnemoc | https://github.com/amery/linux-allwinner/commit/4814fa67184abf29aab83fa2aa7f22b59bcf5990 <--- the original commit |
| 20:18.03 | hno | no idea. |
| 20:18.34 | mnemoc | interesting that the original commit had the chunk after 3: while the ported has it right before 3: |
| 20:24.10 | mnemoc | I'll test with your uboot and that bit corrected |
| 20:25.23 | zenitraM | toxicpsion: ainol novo 7 advanced |
| 20:30.59 | hno | boots mele Andoid to check a little thing.. |
| 20:35.49 | hno | no new ideas. |
| 20:45.03 | mnemoc | moving the mm hack after the 3: didn't fix the halt after enabling earlycon0 on 3.3 |
| 20:52.55 | *** join/#arm-netbook Byan (byan@gateway/shell/mtu-lug/x-tcvlrfgasmcrcoil) |
| 21:03.04 | hno | Hm.. |
| 21:03.50 | *** join/#arm-netbook mikey_w (~mike@c-71-63-115-202.hsd1.va.comcast.net) |
| 21:03.50 | hno | mnemoc, what do you mean? |
| 21:04.08 | *** join/#arm-netbook mike_ (~mike@c-71-63-115-202.hsd1.va.comcast.net) |
| 21:04.47 | hno | I do not have a problem with earlycon in 3.3, only with I/O mapping in general (any) |
| 21:05.44 | hno | and it hangs hard, not even a panic. |
| 21:06.55 | hno | mnemoc? |
| 21:07.29 | hno | some progress.. I can hack my way around that hang, only to have it hang later.. |
| 21:07.54 | hno | but I think I know why it hangs later at least. |
| 21:11.17 | hno | Getting closer... |
| 21:13.36 | hno | Ah... |
| 21:13.43 | hno | now, why is that... |
| 21:13.50 | hno | a NULL pointer. |
| 21:14.27 | hno | No it's not.. |
| 21:19.09 | mnemoc | hno: |
| 21:19.27 | mnemoc | err |
| 21:19.59 | mnemoc | hno: for me 3.3 halts right after [ 0.000000] bootconsole [earlycon0] enabled |
| 21:20.22 | mnemoc | or show nothing at all when earlyprintk is not passed |
| 21:20.50 | mnemoc | the change I did has https://github.com/amery/linux-allwinner/commit/eb937a1b4f43eb7f5d387e9ef69dc9ffc8aa7b60 |
| 21:21.12 | mnemoc | because that's how the original patch was, right after 3: not before |
| 21:22.11 | mnemoc | i don't know if that is "i/o mapping" or something different |
| 21:22.16 | mnemoc | the halt i mean |
| 21:22.36 | mnemoc | hno: i ahven't added any printascii on my own |
| 21:23.38 | hno | Mine gets a little further. Hangs after [ 0.000000] Memory policy: ECC disabled, Data cache writeback |
| 21:23.59 | hno | odd that it differs. |
| 21:24.04 | mnemoc | very |
| 21:24.52 | hno | anyway, I am pretty close to where mine hangs now, but not why. |
| 21:26.40 | mnemoc | is this the same that causes a halt on 2.6.36 when earlyprintk is enabled? |
| 21:27.13 | Gumboot | penguin42: It was a hard drive. I stopped using Linux about ten years ago. Before Flash got big. |
| 21:29.40 | hno | mnemoc, yes the two issues look very similar. |
| 21:30.08 | Gumboot | s/Flash/flash/ |
| 21:30.27 | hno | 2.6.36 differs significantly in how it set up that early page table. |
| 21:30.54 | hno | and crashes on first printascii with MMU enabled. |
| 21:31.13 | hno | 3.3 crashes while trying to create the actual I/O page table. |
| 21:35.29 | mnemoc | for the records, reverted that last commit/fix and my 3.3 still halts on the same place |
| 21:44.28 | hno | mnemoc, to be effective it needs to be after the 3: as in the original allwinner commit. The code just before is for Cortex A9. |
| 21:44.41 | hno | and not executed on A8. |
| 21:47.35 | mnemoc | i reverted it (locally) only for the sake of checking if that execution was causing my early halt |
| 21:48.16 | hno | fixing it made no difference for me either. |
| 21:49.17 | mnemoc | wishes one could use a real debugger on this :| |
| 22:13.51 | hno | Aha.. I think I am almost there. |
| 22:14.39 | hno | Lets see... SW_PA_UART0_IO_BASE 0x01c28000 |
| 22:14.53 | hno | PMD_SIZE(1UL << PMD_SHIFT) |
| 22:15.16 | hno | #define PMD_SHIFT21 |
| 22:16.02 | hno | SW_PA_UART0_IO_BASE != aligned on PMD size. |
| 23:00.00 | hno | Ok, no longer blinded. A reset and then dump log_buf from uboot |