**** BEGIN LOGGING AT Wed Dec 23 02:59:58 2015 Dec 23 09:43:04 Pali: BTW, what was the final decision re ATAGS? Dec 23 09:43:23 I've lost the end of the conversation Dec 23 09:43:55 freemangordon: looks like via reserve memory hook from arch/arm/mach-omap2 we should be able to prevent linux kernel to overwrite memory where are original ATAGs stored Dec 23 09:44:40 so it can be dumped to a file on a later stage? Dec 23 09:44:48 and then from rx51 specific board hook (already have one for emmc and one for thumb2 errata) we should be able to read them and store back to /proc/atags Dec 23 09:45:29 everything just from rx51 code without touching global arm/boot code Dec 23 09:45:37 great Dec 23 09:45:37 but I did not tried to play with it yet Dec 23 09:45:54 this solution will be accepted (once somebody write and test it) Dec 23 09:47:00 h,, I'll see if I feel relaxed in the incomming holidays, may look at it Dec 23 09:47:54 moin :) Dec 23 09:48:04 :) Dec 23 10:04:43 Pali: does latest n900 kernel on github compiles? Dec 23 10:04:55 and does it have DT enabled? Dec 23 10:05:11 freemangordon: do not know, I have not updated it for a long time Dec 23 10:05:16 but I think it should Dec 23 10:05:22 ok Dec 23 10:05:44 Pali: which one to use, 4.2? Dec 23 10:05:54 probably last version Dec 23 10:06:01 ok Dec 23 10:06:19 hmm, seems my CPU heatsink needs to get cleaned :) Dec 23 10:07:33 CPU hit 78 deg while compiling the zImage, before being stopped with ctrl-c :) Dec 23 10:16:02 are there any news related to neo900? Dec 23 10:16:19 i mean, some progress? Dec 23 10:54:05 Pali: any ide where to put rx51_reserve()? in board-generic.c? in common.c? in pdata-quirks.c? Dec 23 10:54:14 *idea Dec 23 10:54:54 freemangordon, search for nokia_n900_legacy_init Dec 23 10:55:07 it is in pdata Dec 23 10:55:15 pdata-quirks.c Dec 23 10:55:16 and for n900_boards_compat Dec 23 10:55:32 it is boards-generic :) Dec 23 10:55:43 *board-generic Dec 23 10:55:50 I think reserve memory needs to be instead omap_reserve in "DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board")" Dec 23 10:55:56 sure Dec 23 10:56:13 the point is that - where to put that replacement function Dec 23 10:56:20 in which file Dec 23 10:57:25 I think the best place is board-generic.c, so it can be defined as static, but I see no function definitions in that fil Dec 23 10:57:30 in my opinion put new function into pdata-quirks.c Dec 23 10:57:53 and declare it where? in common.h? Dec 23 10:57:59 and assign it to .reserve = Dec 23 10:58:39 header file common.h Dec 23 10:58:52 I know where to assign it, but it needs to be extern, not static if defined anywhere outside if board-generic Dec 23 10:59:00 *of Dec 23 10:59:13 yes, it must be non-static Dec 23 10:59:30 "extern" keyword for C function is not needed and is not used Dec 23 10:59:53 but if it is declared in common.h, whine not define it in common.c then? Dec 23 10:59:58 *while Dec 23 11:00:05 shit Dec 23 11:00:06 because it is quirkk function Dec 23 11:00:07 WHY Dec 23 11:00:20 so is omap_reserve() Dec 23 11:00:44 will ask on linux-omap Dec 23 11:00:53 basically this is n900 specific function and correct place is in pdata-quirks.c Dec 23 11:01:34 but you must assign pointer to that function in file board-generic.c and that file includes only common.h Dec 23 11:04:14 Pali: but there *is* device specific data in board-generic.c - struct n900_boards_compat, why not define that function there as well. And make it static. Dec 23 11:04:52 or put it in common.c - if it is declared in common.h Dec 23 11:06:22 that board-generic.c does not contains board specific functions Dec 23 11:06:32 but put it here... Dec 23 11:06:40 oh, wait, the *is* at least one function defined in board-generic - omap_generic_init() Dec 23 11:06:59 but it contains board specific data, so I'll put it there Dec 23 11:07:03 omap maintainers will accept it or not Dec 23 11:07:46 :nod: Dec 23 11:08:45 Pali: do we have atags address and size? Dec 23 11:09:53 we have offset Dec 23 11:10:01 0ь100? Dec 23 11:10:07 0x100? Dec 23 11:10:08 and size shold be smaller then one page Dec 23 11:10:13 ok Dec 23 11:10:37 memblock_reserve(PHYS_OFFSET, PAGE_SIZE); Dec 23 11:10:46 yeah Dec 23 11:13:09 read this thread: http://www.spinics.net/lists/arm-kernel/msg464340.html Dec 23 11:13:22 (all messages in "Next by thread" links) Dec 23 11:27:03 Pali: already did it, I am in CC on linux-omap ML :) Dec 23 11:27:11 ok :-) Dec 23 11:28:19 but this memblock API is not very understandable, WTF is the difference between memblock_free and memblock_remove?!? Dec 23 14:03:04 Pali: what about copying atags data to some __init structure instead of doing memblock_reserve()? Dec 23 14:03:57 as it turns out, memblock_reserved() memory cannot be given back to the system once paging_init() is called Dec 23 14:04:43 freemangordon, you can call directly function save_atags() Dec 23 14:06:26 Pali: hmm, tell me then why this is not done yet? I men - I've lost the roots of the problem. Dec 23 14:06:30 *mean Dec 23 14:07:00 problem is that I'm not sure if you really can read that memory where are atags stored Dec 23 14:07:06 if they are not rewritten yet... Dec 23 14:07:34 static char __initdata atags_copy[BOOT_PARAMS_SIZE]; Dec 23 14:07:41 you need to read them before some memory/page init functions are called Dec 23 14:08:37 Pali: save_atags is called from setup_machine_tags Dec 23 14:08:58 yes, but that pointer points to DTS blob! Dec 23 14:09:02 not to atags memory Dec 23 14:10:24 oh, I see Dec 23 14:14:53 Pali: but then, what needs to be done? I mean - DT anyways creates /pros/atags, correct? We can;t overwrite it. Dec 23 14:15:16 DT does not create /proc/atags Dec 23 14:15:25 *DT booted kernel Dec 23 14:15:58 and we want to read ATAGs passed by nolo to kernel also for rx51 device booted in DT mode Dec 23 14:16:23 but what does init_atags_procfs then? Dec 23 14:16:53 on DT booted kernel nothing Dec 23 14:17:13 but if you are using my tree, it contains special patch which store ATAGs into DT structure Dec 23 14:17:27 and then kernel unpack ATAGs from DT structure and store them into /proc/atags Dec 23 14:17:34 but this patch was rejected Dec 23 14:17:37 because atags_copy contains nothing? Dec 23 14:17:46 something like that Dec 23 14:17:57 do not rememeber exacly Dec 23 14:18:04 save_atags is not called in DT booted kernel Dec 23 14:20:10 it should be, at least from what I see in the code http://lxr.free-electrons.com/source/arch/arm/kernel/atags_parse.c#L227 . unless that if fails Dec 23 14:21:21 I know it is not called with the atags from the bootloader Dec 23 14:21:27 but still it is called Dec 23 14:46:11 Pali: what do you think about http://pastebin.com/MHzUvusK ? Dec 23 14:56:41 freemangordon, no need to #ifdef CONFIG_ATAGS_PROC Dec 23 14:56:56 just include atags.h or kernel/atags.h Dec 23 14:56:57 why? Dec 23 14:57:02 you can;t Dec 23 14:57:16 save_atags() is noop when CONFIG_ATAGS_PROC is not defined Dec 23 14:57:18 what needs to be included is ../kernel/atags.h Dec 23 14:57:28 which is ugly Dec 23 14:57:54 I know it is noop, but still I define one more static function, which is not needed Dec 23 14:58:02 if you use function from kernel you should include header file Dec 23 14:58:33 I don;t believe #include "../kernel/atags.h" will be upstreamed :) Dec 23 14:59:30 without correct header too... Dec 23 14:59:34 better ask on ML Dec 23 14:59:46 lets see what will say Russell, I'll fix those nits later Dec 23 14:59:48 but first check if it is working Dec 23 15:00:18 ok Dec 23 15:00:25 and this is the problem, I don;t have device with booting upstream kernel :) Dec 23 15:00:42 can I boot qemu to userspace? Dec 23 15:01:06 Pali: ^^^ Dec 23 15:01:19 yes Dec 23 15:01:29 small userspace with busybox is enough Dec 23 15:01:40 do you have something prepared? Dec 23 15:01:58 I have script which build userspace :-) Dec 23 15:02:07 and start qemu Dec 23 15:02:10 good for you :) Dec 23 15:02:17 care to share it? Dec 23 15:02:45 ok, I'm going to clean it and send it to you Dec 23 15:02:55 now it depends on my PC :-) Dec 23 15:02:56 thanks Dec 23 15:03:06 send it as well :) Dec 23 15:04:11 Pali: don;t hurry, my GF has birthday today, so I don;t think I will have much more time to spend on that today Dec 23 15:14:54 hi folks Dec 23 15:17:31 freemangordon: done, see email Dec 24 01:38:42 Hm. jonwil might be interested to know that the guy from the Google security team responding to my report has reproduced the issue and filed a bug to "the team". Dec 24 01:39:15 Dunno if I can log in to TMO over this internet connection. **** ENDING LOGGING AT Thu Dec 24 02:59:59 2015