| --- Log opened Tue Jul 15 00:00:20 2014 | ||
| -!- Netsplit *.net <-> *.split quits: mboehnert1, ssvb_, jungma | 02:42 | |
| -!- Netsplit over, joins: ssvb_ | 02:42 | |
| -!- Netsplit *.net <-> *.split quits: clopez, _franck_, jonmasters, rah, jungma, javax, xlro, jeremy_bennett, dalias, mboehnert | 03:12 | |
| -!- Netsplit over, joins: jeremy_bennett, rah, _franck_, xlro, javax, jonmasters, dalias, clopez, mboehnert | 03:20 | |
| stekern | blueCmd_: btw, since you've became such a git advocate, you should embrace it fully and start using present tense in your commit messages ;) | 03:25 |
|---|---|---|
| stekern | oh, and regarding the master->slave change, I think my notion was a mistake there actually | 03:32 |
| stekern | that said, I've heard that the master and slave notion can be offensive to some people, so I suggest we change all occurrancies of 'master' to 'wife' and 'slave' to 'husband' | 03:33 |
| stekern | s/occurrancies/occurrences | 03:35 |
| stekern | dalias: when you have a minute, I'd like to pick your brain on this pthread_robust issue I've been investigating. | 05:27 |
| stekern | the gist of it is that from what I understand, musl ends the robust_list with a null pointer. but the kernel expects the list to point back to itself in: http://lxr.free-electrons.com/source/kernel/futex.c#L2910 | 05:28 |
| dalias | stekern, sure | 05:30 |
| stekern | on x86_64 (for example), this is 'fine', since the get_user will silently exit exit_robust_list on a null pointer. | 05:30 |
| stekern | but on or1k, the null pointer will be de-referenced | 05:30 |
| dalias | ... | 05:30 |
| dalias | why is the null pointer dereferenced? | 05:31 |
| stekern | this is at least what I have made out of it, I might be misunderstanding things... | 05:31 |
| dalias | i mean why does the kernel have a mapped zero page? | 05:31 |
| dalias | that's a source of endless problems, many security-critical | 05:31 |
| stekern | well, that's another issue... but our executables get mapped to page 0 | 05:31 |
| dalias | ... | 05:31 |
| stekern | heh | 05:32 |
| stekern | yeah, it's a problem, but let's look past that for a second? ;) | 05:34 |
| dalias | Documentation/robust-futex-ABI.txt says it stops scanning when a pointer in the linked list is not a valid userspace word address | 05:34 |
| dalias | it doesn't say anything about pointing back at itself | 05:35 |
| stekern | hmm, yeah... so the problem is really that we have a mapped zero page | 05:40 |
| dalias | mapped in userspace? | 05:40 |
| dalias | i could understand if there are arch-specific reasons you have a zero page mapped in kernelspace | 05:40 |
| dalias | but zero page should absolutely never be mapped in userspace | 05:40 |
| stekern | right | 05:41 |
| stekern | so, let's look into fixing that ;) | 05:44 |
| stekern | anyway, I can consider that issue closed as far as the or1k musl port goes, that's what I wanted to conclude first. | 05:49 |
| stekern | dalias: once again, thanks for the help | 05:51 |
| dalias | ok | 05:53 |
| stekern | next - ipc failures | 06:18 |
| dalias | probably wrong struct definitions in the bits headers | 06:19 |
| dalias | that's a common issue in new ports | 06:19 |
| dalias | these structs are the '64' versions | 06:19 |
| stekern | ok, thanks for the hint, will look into that | 06:21 |
| dalias | going to sleep now, you can leave a message for me tho if you have any questions | 06:28 |
| stekern | night | 06:42 |
| stekern | ok, that was easy. we're not selecting ARCH_WANT_IPC_PARSE_VERSION | 06:51 |
| stekern | so, the IPC_64 wasn't masked out from the command | 06:52 |
| stekern | blueCmd_: I bet you don't have anything against this? http://pastie.org/9392304 | 08:15 |
| jtdesousa | while running fusesoc with icarus and then using openocd to connect gdb we found that if the program is not loaded by fusecoc thne gdb can load it but continuing never ends; | 09:21 |
| jtdesousa | if the program is loaded initially by fusesoc then it can be reloaded by gdb and continued. | 09:21 |
| jtdesousa | With Verilator this issue is not present. | 09:22 |
| blueCmd_ | stekern: nope, what does it do? | 09:33 |
| blueCmd_ | stekern: do you have an example of present tense and where I use past tense? | 09:33 |
| stekern | blueCmd_: it moves our executables out of page zero | 09:33 |
| blueCmd_ | stekern: +1 | 09:34 |
| stekern | blueCmd_: present tense: add <feature> past tense: added <feature> | 09:34 |
| blueCmd_ | stekern: ack, input has been accepted. warning: changed configuration will only take effekt from now on and not affect past commits | 09:36 |
| stekern | heh | 09:37 |
| blueCmd_ | on a related note: affect/effect is hard | 09:38 |
| stekern | yes, I can never tell which one should be used | 09:38 |
| stekern | mixing those up is probably minor to all my other mistakes though ;) | 09:39 |
| stekern | I like how you threw a swedificated 'effekt' in the mix there too! =P | 09:39 |
| _franck__ | I'm not good at writing English but at least I know how to use affect/effect since it's mostly the same in French ;) | 09:40 |
| blueCmd_ | stekern: aw crap | 09:41 |
| blueCmd_ | something takes effect, but is being affected | 09:41 |
| blueCmd_ | I think that's correct | 09:41 |
| _franck__ | it is (at least AFAIK) | 09:42 |
| blueCmd_ | _franck__: I have a french 2m from he. yesterday he came dressed in striped cloths and had a baugget with him | 09:43 |
| _franck__ | if one day you leasr French, you'll be able to use affect/effect :) | 09:43 |
| blueCmd_ | (spelling is probably totally off 'baugget' - looks horrible) | 09:43 |
| _franck__ | s/leasr/speak | 09:43 |
| stekern | baguette | 09:44 |
| stekern | finnish-swedish people call that a 'batong' | 09:44 |
| _franck__ | yes baguette | 09:44 |
| blueCmd_ | well I had the letters right anyway | 09:44 |
| stekern | ...which means 'baton' in swedish | 09:45 |
| stekern | but they just took the finnish word 'patonki' and turned it a bit swedish | 09:46 |
| stekern | 'patonki' doesn't mean anything else than baguette (afaik) | 09:47 |
| blueCmd_ | olofk: you spoke earier about the need to refactor wb_intercon_gen - I agree, but I think you should in that case focus on the tool being standalone just as it is now, and make it just as easy to use without another tool. then your GUI graphical "point-and-drag" interface would just write the config for wb_intercon_gen | 09:55 |
| -!- Netsplit *.net <-> *.split quits: clopez, _franck_, jonmasters, rah, javax, xlro, mafm, dalias, mboehnert, jeremy_bennett, (+1 more, use /NETSPLIT to show all of them) | 09:56 | |
| stekern | +1 | 09:56 |
| blueCmd_ | what I love with wb_intercon_gen is that it's easy to interop it in whatever workflow I have, input is one file, output is two - you could probably prove it mathematically if you really put your mind to it | 10:00 |
| -!- Netsplit over, joins: maxpaln | 10:00 | |
| -!- Netsplit over, joins: _franck_, mafm | 10:01 | |
| dalias | stekern, if or1k does not need IPC_64 we should just def that macro to 0 | 10:14 |
| dalias | no need for kernel change | 10:14 |
| stekern | dalias: you mean if we don't need to support IPC_OLD? ok, makes sense | 10:20 |
| dalias | if there's only one version of the ipc structs for the arch and thus IPC_64 is not needed to get the correct version, IPC_64 can just be defined to 0 | 10:21 |
| dalias | like it is on x86_64 | 10:21 |
| stekern | yeah, I see | 10:22 |
| dalias | does that resolve the remaining test failures? | 10:45 |
| stekern | oh, there's more, but it does resolve the ipc failures | 10:46 |
| dalias | ah :) | 10:46 |
| stekern | sem_open fails, but I don't even have /dev/shm so it's no wonder. then there's some socket failures, but I think that's due to my kernel config in the test setup | 10:51 |
| stekern | the stat test fails too | 10:51 |
| stekern | and then there's still a bunch of tests I haven't ran yet | 10:52 |
| blueCmd_ | olofk: I split the submodules pull request now | 10:58 |
| blueCmd_ | that was much harder than I thought it would be. git does not like read HEAD~1 if it contains submodule changes | 10:58 |
| dalias | stat failing may be a wrong struct definition | 10:58 |
| dalias | sem_open is probably just the missing /dev/shm mount | 10:59 |
| maxpaln | I've fixed the last bug (aren't they always so easy to fix once you've spent FOREVER finding them!) | 12:37 |
| maxpaln | I am now trying to track down why Linux isn't producing any output on the console | 12:37 |
| maxpaln | I can see that after a short period it is getting stuck in the last few instructions of the <die> function - obviously not good! | 12:38 |
| maxpaln | I've traced it back - it appears to be called from within <do_unaligned_access> | 12:38 |
| blueCmd_ | yeah, that's bad :P | 12:38 |
| blueCmd_ | don't misalign your data :) | 12:39 |
| maxpaln | :-) thanks | 12:39 |
| maxpaln | I'm tracing back through to find the original cause of this - but I am a little surprised these cause a terminal failure. I would have expected a straight forward exception for this... | 12:39 |
| maxpaln | maybe there's a clue right there... | 12:39 |
| blueCmd_ | well, linux has exception handlers for unaligned access | 12:40 |
| maxpaln | ah, I see - so the kernel caught the exception instead of the processor | 12:42 |
| maxpaln | makes sense I guess | 12:42 |
| blueCmd_ | well no, the CPU jumps to 0xa00 (IIRC) on unaligned access, and linux has code there that handles that | 12:44 |
| _franck__ | http://lxr.free-electrons.com/source/arch/openrisc/kernel/entry.S#L313 | 12:44 |
| maxpaln | Ah, I see - ok that makes even more sense | 12:44 |
| maxpaln | as an aside, I can see the printk code getting executed as part of the die process (during show_registers) but I am not getting any activity on the UART console | 12:45 |
| maxpaln | Not being a Linux expert I have no idea if I really should be able to see UART output (which would make debug a LOT easier) or whether the Linux kernel needs to get further into the boot process to be able to output over the console. | 12:46 |
| maxpaln | anyway, I'll keep searching. | 12:46 |
| blueCmd_ | I feel I don't have enough state to guide you on this, it's weird that you get alignment errors in Linux unless you modified the kernel or put the UART on some odd address | 12:46 |
| ysionneau | waaa there is a #if 0 in the upstreamed code? | 12:47 |
| maxpaln | well, I guess it is possible the write to the UART is causing the alignment problem - but I can't be conclusive on this. | 12:48 |
| maxpaln | I am essentially debugging the OR1200 processor with a new DDR3 memory controller - written by me using our DDR3 IP. | 12:49 |
| maxpaln | so it is possible there is a bug in the memory controller - I have already found one of those. | 12:49 |
| maxpaln | but I have also tried to strip back the kernel so it doesn't do too much in the way of peripheral loading - | 12:49 |
| blueCmd_ | maxpaln: right, so in that case I would put my money on a stack restore getting the wrong register contents | 12:50 |
| blueCmd_ | and then loading an address from there ends up using an address that's not aligned | 12:50 |
| blueCmd_ | I've had that issue myself | 12:50 |
| maxpaln | ok - that makese sense. | 12:50 |
| maxpaln | The last bug was something similar actually | 12:50 |
| blueCmd_ | ysionneau: yes, ugly - I agree | 12:51 |
| maxpaln | But I don't think any of this gets me much closer to finding the root cause :-( | 12:51 |
| blueCmd_ | maxpaln: for this I have written a newlib 'diagnostics' program that does a bunch of memory operations to test stuff like that | 12:51 |
| maxpaln | oooh, | 12:52 |
| blueCmd_ | it's quite board specific, but it might be easier to drill down using something like that | 12:52 |
| maxpaln | although without a console I am not sure how I would get at the output!!!! | 12:52 |
| blueCmd_ | maxpaln: right | 12:52 |
| blueCmd_ | writing this in assembler wouldn't be hard though | 12:52 |
| blueCmd_ | avoiding memory read/writes for UART | 12:52 |
| maxpaln | I'll continue on this route for now - I'm still making something that feels like progress | 12:53 |
| blueCmd_ | maxpaln: let me know if you want to hack together a memory write / readback test for you | 12:53 |
| blueCmd_ | that won't use memory for uart | 12:53 |
| maxpaln | ok, thanks | 12:53 |
| maxpaln | It is worth mentioning that the UART does work - I have a simple 'Hello World' program that prints to the UART - it works fine. | 12:54 |
| blueCmd_ | yes, i would imagine so | 12:54 |
| maxpaln | :-) | 12:54 |
| maxpaln | but it at least gives me confidence the HW works :-) | 12:54 |
| maxpaln | roughly | 12:54 |
| blueCmd_ | what's your sys_clk speed and what baud are you using? | 12:55 |
| maxpaln | clock of 50 MHz, baud of 115200 | 12:55 |
| blueCmd_ | where is the uart? 0x90000000 ? | 12:55 |
| maxpaln | Yep | 12:56 |
| maxpaln | I was just looking at the Linux assmebler - I can see the alignment exception handler at 0x600 | 13:07 |
| maxpaln | but it doesn't seem to call the code that is being exectued in my code | 13:07 |
| maxpaln | in fact the do_unaligned_access() function is only called from _alignment_handler() | 13:08 |
| maxpaln | but nothing seems to call alignment handler - which puzzles me a lot | 13:08 |
| maxpaln | or rather, there are no jumps to _alignment_handler() or any code within it in the assembler!! | 13:09 |
| _franck__ | _alignment_handler is "called by the hardware". It's located at exception vector. When alignment error happend, the PC jump at 0x600 automatically | 13:13 |
| _franck__ | you have to look at the pc before it jumps to 0x600 | 13:13 |
| dalias | stekern, btw what is the reason the zero page is mapped, and is it supposed to be mapped/visible to userspace? | 13:14 |
| dalias | perhaps i would have some ideas for fixing it if i knew why.. | 13:14 |
| maxpaln | _franck__: thanks - although I don't think I quite follow the sequence. the Linux kernel has a section of code at 0x600 for alignment exceptions | 13:15 |
| maxpaln | but there is a separate section of code at 0xc00053fc called _alignment_handler | 13:15 |
| maxpaln | this is where my code ends up before entering die() and getting stuck in a loop | 13:16 |
| maxpaln | I was hoping to track back through the assembler to see where what instruction(s) could jump to _alignment_handler() but there aren't any!! | 13:16 |
| blueCmd_ | maxpaln: yes, the code at 0x600 is only a trampoline that jumps to the other function | 13:17 |
| stekern | dalias: probably for hysterical raisins | 13:17 |
| blueCmd_ | maxpaln: or, maybe not - but that's how I tought it was | 13:18 |
| maxpaln | blueCmd_: I don't see anything in the code at 0x600 that could take it anywhere outside that block of code | 13:18 |
| stekern | but there's no reason we should map our executables to page zero from now on | 13:18 |
| maxpaln | but I don't doubt you are correct - it must be my understanding. | 13:18 |
| dalias | stekern, oh, it's not a kernel matter but just the ELF headers requesting an address of 0 ? | 13:19 |
| stekern | dalias: exactly | 13:19 |
| dalias | i'm surprised that would even be honored -- i thought 0 meant (like for mmap) assigned-by-kernel | 13:19 |
| blueCmd_ | maxpaln: http://lxr.free-electrons.com/source/arch/openrisc/kernel/head.S#L327 | 13:19 |
| blueCmd_ | and that uses http://lxr.free-electrons.com/source/arch/openrisc/kernel/head.S#L124 to jump | 13:20 |
| dalias | also, normally the kernel has an option to refuse mapping the zero page or any low pages... | 13:20 |
| stekern | dalias: maybe the actual issue is deeper, that the kernel allows that. but we kind of have to allow that for old binaries then. | 13:21 |
| maxpaln | hmmm, ok - I was approaching from a different angle. I disassembled the linux kernel and was reviewing the assembler. It isn't a straight forward comparison %-) | 13:22 |
| dalias | well if the kernel doesn't have any explicit code to stop robust list processing at a null pointer, i think you either need to add this to the generic, arch-independent code as an explicit check... | 13:23 |
| stekern | anyway, I have a patch for the linker script in binutils, I'll push that upstream asap. that should at least catch null pointer derefencing... | 13:23 |
| dalias | ...or make the or1k futex atomics the kernel uses explicitly check for null and emulate a fault | 13:24 |
| stekern | and with that, the pthread_robust test passes (as expected) | 13:24 |
| dalias | ideally the text address should be >64k or so | 13:25 |
| maxpaln | blueCmd_: but like I say, I am sure you are right - this is a weak area for me! | 13:25 |
| dalias | (vm.mmap_min_addr is recommended to be 64k or higher) | 13:25 |
| stekern | sem_open fails with /dev/shm present as well, but the reason for that seems to be stat related too, so I think that failure is what I should look into now | 13:26 |
| dalias | yes | 13:26 |
| blueCmd_ | maxpaln: the way it uses to jump to the symbol wouldn't show up in a disassembler | 13:26 |
| blueCmd_ | maxpaln: since we split it by hi/lo the disassembler wouldn't show you a text reference | 13:26 |
| stekern | dalias: ah, ok. I have to read into that more, I adjuested the textaddress to start at 0x2000 (or1k pages are 8192), maybe I should increase that even more then. | 13:26 |
| dalias | basically there are lots of potential kernel vulns if the kernel accidentally dereferences a null pointer and the deref doesn't fault | 13:27 |
| blueCmd_ | maxpaln: if you look at your 0x600 in your elf you should see code where the last four instructions should be loading the address, one l.mtspr and an l.rfe | 13:27 |
| dalias | and you want mmap_min_addr to be larger than any offset the kernel might happen to access | 13:28 |
| dalias | the kernel folks recommend 64k or so and they probably have their reasons, but they might just be building in extra padding for safety | 13:28 |
| maxpaln | blueCmd_: yep, I see that - ah, and now you've pointed it out I can see that's what the code is doing. | 13:29 |
| dalias | stekern, i think i found your stat problems | 13:29 |
| dalias | see include/uapi/asm-generic/stat.h | 13:30 |
| dalias | you have the st_ino in the wrong place and various wrong padding | 13:31 |
| stekern | yup, I see | 13:33 |
| dalias | (stat64 is the relevant one) | 13:34 |
| stekern | looks like I just have copied that from microblaze and then forgot to change it :/ | 13:34 |
| stekern | I think I'll go through the rest of the bits/ files tonight, might be more of that kind... | 13:37 |
| dalias | :) | 13:37 |
| stekern | got to run now, bbl | 13:37 |
| dalias | k | 13:37 |
| blueCmd_ | maxpaln: how big is your memory? | 13:41 |
| blueCmd_ | (how is the map? 0x0 - 0x????) | 13:42 |
| maxpaln | blueCmd: the memory itself is very big - its a DDR module so at least 1GB, I would have to check | 13:50 |
| maxpaln | but I guess you are asking how much memory is available to Linux... | 13:50 |
| maxpaln | it's in the dts file as: | 13:51 |
| maxpaln | memory@0 { | 13:51 |
| maxpaln | device_type = "memory"; | 13:51 |
| maxpaln | reg = <0x00000000 0x02000000>; | 13:51 |
| maxpaln | }; | 13:51 |
| maxpaln | I should probably expand this but this should be enough | 13:51 |
| blueCmd_ | http://openrisc.debian.net/tmp/maxpaln/ | 13:53 |
| blueCmd_ | that should write all addresses between 0x00000000 0x02000000 and read it back | 13:53 |
| maxpaln | blueCmd_: Thanks - taking a look now | 14:05 |
| blueCmd_ | the code is at https://github.com/bluecmd/mexiko/blob/master/src/bootrom/mem_stress.S if you feel like modifying it | 14:06 |
| maxpaln | so can I use the .v as the ROM code? | 14:06 |
| blueCmd_ | maxpaln: I use it as rom code yes | 14:06 |
| maxpaln | So presumably I should look out for EPCR changes against this code | 14:07 |
| blueCmd_ | I place it in a rom at 0xf0000000 so that line 64 is at 0xf0000100 | 14:07 |
| blueCmd_ | this code doesn't do any exception handling | 14:07 |
| maxpaln | that works, my ROM is at 0xF0000000 too | 14:08 |
| blueCmd_ | it doesn't do stacks either, it just reads/writes RAM and outputs progress on UART | 14:08 |
| maxpaln | ah, ok - well that would be a good start | 14:08 |
| maxpaln | Out of interest, How does the .bin version work? Presumably you'd need to set the address range to be outside the program storage of the OR1200. | 14:09 |
| maxpaln | does the code check if the read matches the write? | 14:09 |
| maxpaln | I will build this shortly and test it out :-) | 14:10 |
| blueCmd_ | maxpaln: the bin and .v is linked to be loaded on 0xf0000100 | 14:10 |
| maxpaln | ah, ok - I see - the .bin is the precursor to .v - makese sense | 14:11 |
| blueCmd_ | as in https://github.com/bluecmd/mexiko/blob/master/src/bootrom/bootrom.ld | 14:11 |
| blueCmd_ | maxpaln: yes, sort of. i use the ELF as source of truth, but I didn't know if you wanted it in verilog or binary blob | 14:11 |
| maxpaln | verilog will do fine :-) | 14:11 |
| maxpaln | ok, I think I need a little help on this one - I have traced back my problem | 14:55 |
| maxpaln | it occurs because of a misaligned access to memory | 14:56 |
| maxpaln | it occurs when an instruction in the enable_mmu function tries to load a word from memory using the following instruction: | 14:58 |
| maxpaln | c01ba174:84 79 00 00 l.lwz r3,0x0(r25) | 14:58 |
| maxpaln | The problem is that r25 at this stage contains 0xFF | 14:58 |
| maxpaln | I traced all the way back through the Linux boot and there is no previous assignment to r25 - the closest is in _start | 14:59 |
| maxpaln | when all the registers are initialised - except r25 | 14:59 |
| maxpaln | c01ba064:e2 e0 00 04 l.or r23,r0,r0 | 14:59 |
| maxpaln | c01ba068:e3 00 00 04 l.or r24,r0,r0 | 14:59 |
| maxpaln | c01ba06c:e3 40 00 04 l.or r26,r0,r0 | 14:59 |
| maxpaln | c01ba070:e3 60 00 04 l.or r27,r0,r0 | 14:59 |
| maxpaln | Is this an error or deliberate - is r25 meant to contain something sensible at this stage? | 15:00 |
| maxpaln | oh, hang on | 15:00 |
| maxpaln | I was a little premature - | 15:00 |
| maxpaln | r25 is initialised at the top of _start() | 15:00 |
| maxpaln | sorry - my bad! | 15:01 |
| maxpaln | going back in... | 15:01 |
| maxpaln | ok, I can see the problem now | 15:09 |
| maxpaln | although I am really confused about the real root cause | 15:09 |
| maxpaln | the Linux boots by running through the handful of instructions at 0x100: | 15:09 |
| stekern | maxpaln: r25 isn't expected to hold a sensible value, but r3 | 15:09 |
| maxpaln | c0000100:19 e0 c0 1b l.movhi r15,0xc01b | 15:10 |
| maxpaln | c0000104:a9 ef a0 00 l.ori r15,r15,0xa000 | 15:10 |
| maxpaln | c0000108:19 a0 40 00 l.movhi r13,0x4000 | 15:10 |
| maxpaln | c000010c:e1 ad 78 00 l.add r13,r13,r15 | 15:10 |
| maxpaln | c0000110:44 00 68 00 l.jr r13 | 15:10 |
| maxpaln | c0000114:15 00 00 00 l.nop 0x0 | 15:10 |
| maxpaln | This sends it to _start() - which has this as its first instruction: | 15:10 |
| maxpaln | c01ba000 <_start>: | 15:10 |
| maxpaln | c01ba000:e3 20 18 04 l.or r25,r0,r3 | 15:10 |
| stekern | it should contain a pointer to fdt | 15:10 |
| stekern | (or 0) | 15:10 |
| maxpaln | yeah, well r3 is never initialised from 0x100 onwards | 15:11 |
| stekern | the kernel entry is kernel(void *fdt) | 15:11 |
| maxpaln | so that line in _start just takes whatever happens to be in r3 and puts in r25 | 15:11 |
| stekern | yes, but you "call" the kernel from somewhere and pass arguments to it using the regular function arg passing ABI | 15:12 |
| maxpaln | stekern: I don't think I am getting that far - I can see the processor booting in the ELA | 15:12 |
| maxpaln | it goes through the ROM code loading from SPI to RAM | 15:12 |
| maxpaln | jumps to 0x100 | 15:12 |
| maxpaln | executes the above code | 15:12 |
| maxpaln | and jumps to _start() | 15:12 |
| stekern | yes, r3 is expected to hold a sensible value already at the first line of code in the kernel | 15:13 |
| stekern | i.e. the fdt pointer is passed from a bootloader | 15:13 |
| maxpaln | Ah, so the problem is in the ROM code - which leaves r3 holding a random value - probably the last byte of code from the SPI Flash | 15:13 |
| maxpaln | so what value should really be in r3? | 15:13 |
| stekern | since you're not passing a pointer to fdt, 0 should be fine | 15:14 |
| maxpaln | ok - (although I am not sure what the fdt pointer would be) | 15:14 |
| stekern | actually, any word aligned address that is accesible will do | 15:14 |
| maxpaln | ok - well I'll try 0x0 | 15:14 |
| stekern | fdt = a compiled device tree blob | 15:14 |
| maxpaln | :-) | 15:15 |
| maxpaln | For reference, this is the standard bootrom.S code that I am using - I am kinda surprised I didn't run into this problem before | 15:15 |
| stekern | i.e. you can feed the kernel a dynamic device tree configuration from a bootloader, instead of building it into the kernel itself | 15:15 |
| maxpaln | I must have gotten lucky and had the final byte in the SPI Flash contain something like 0x00 | 15:16 |
| maxpaln | It would be a sensible addition to the ROM code to reset all the registers it uses I guess | 15:16 |
| stekern | yeah, as I said, any accessible word-aligned value will "work" | 15:16 |
| maxpaln | stakern: ah I see now - during enable_mmu the contents of r25 (formerly r3 at the time of jumping to 0x100) become the reference to the fdt | 15:20 |
| maxpaln | hmmm, the bootrom.S really should include a reset of r3 in that case!! I wonder if the latest sample bootrom.S does this... | 15:20 |
| maxpaln | (ooops sorry - typo on your name stekern!) | 15:21 |
| maxpaln | WOOOOOOOOHOOOOOOOOOOO! After several months of work I have Linux booting on our new silicon!!! :-) | 17:44 |
| maxpaln | ish - I am getting boot dialog on the UART - but it is pausing mid boot. Something to debug tomorrow - I am very happy though! | 17:45 |
| stekern | hah, the stat failure was just silly... I had the wrong date set.. | 20:32 |
| stekern | the sem_open failure was however due to the wrong stat struct | 20:33 |
| stekern | dalias: when I started to look in to that, I remembered why I hadn't changed anything in it. I copied the microblaze one, and checked that microblaze use asm-generic/stat.h. Then I obviously got lazy and didn't check that it actually matched asm-generic/stat.h. | 20:36 |
| stekern | so I would assume that microblaze's bits/stat.h isn't correct neither | 20:37 |
| -!- Netsplit *.net <-> *.split quits: fotis2, rjo, trevorman | 21:07 | |
| -!- Netsplit over, joins: trevorman | 21:07 | |
| -!- Netsplit over, joins: fotis2 | 21:08 | |
| blueCmd_ | mboehnert: gratz! :) | 21:19 |
| stekern | all functional tests passes now, and all but malloc-brk-fail regression tests passes | 23:33 |
| stekern | a bunch of math tests fails though | 23:34 |
| stekern | that's for tomorrow... zzz | 23:34 |
| --- Log closed Wed Jul 16 00:00:21 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!