A new kernel for oxnas

[jbrnd]

For the machine ID problem, https://developer.ridgerun.com/wiki/ind ... machine_ID

has some relevant information.

[jbrnd]

Hmm... when I tried to quote Geoff's reply to me, the board told me the topic was too old. Weird...

Anyway, to quote Geoff manually: "You have to load and boot the kernel at 60500000"... and that worked! The kernel booted without problems. Thank you! Out of curiosity, why is 60500000 the right address?

[Geoff]

I must admit that it's pure black magic to me. All I can say is that's what the stock uboot did, and it still works with the latest uboot.

[tilator]

$this->bbcode_second_pass_quote('jbrnd', 'H')mm... when I tried to quote Geoff's reply to me, the board told me the topic was too old. Weird...

Anyway, to quote Geoff manually: "You have to load and boot the kernel at 60500000"... and that worked! The kernel booted without problems. Thank you! Out of curiosity, why is 60500000 the right address?

[tilator]

I got it up.

So here is what you will need to use Kref's 3.12.13 kernel version with same Oxnas version I have here. I try to attach the ZIP file here.

********************************************

OK. Too big file (290kb while 256kb allowed). I'll take u-boot binary out of it.

P.S. rtc support needs LED support to be turned on. It is off in attached defaultconfig.

P.P.S. Seems to work with 3.13.5 kernel source too. Still just needs LED support on.

[tilator]

Hi everybody,

There seems still to be one odd problem. Sometimes RTC driver (Dallas 1307) does not load and it seems to be that the RTC chip has memory of it's own. If there has been some incompleted data flow to the rtc, next boot will fail for time functions.

So, I suppose there are some buffered bytes in the RTC chip to prevent driver loading properly.

If original 2.6.14 kernel is booted once, the newer kernel will boot OK again. Older kernel must have some kind of "resetting" or wiping out incompleted bytes from rtc memory. I can't figure out any other reason to this behavior.

But - the question is, how can I add rtc buffer flushing/resetting to the 3.13.x version of kernel? Is there anybody to know how this can be done?

[tilator]

A bit more info:

It seems to be, this device boots OK with kernel 3.13.x and RTC works too, if it's first booted with the original 2.6.31.14 kernel.

This seems to have something to do with disabling secondary, tertiary etc. functions of the multifunction gpio pins.

Old kernel disables them and booting without powering off leaves them as they are. Then booting with 3.13.x kernel goes fine.

But if power is turned off and then booted right away with the new kernel, it does not work.

I just don't know how multifunction pin properties can be set with the new kernel. Anybody to help with this, please?

[celemine1gig]

Perhaps ask kref. He is the one who would probably know. You coold use github's "issue" method in his oxnas kernel repository.

[tilator]

Well, I got it up. It's not pretty but will do.

I just took a dump of the memory area having all needed GPIO settings as they should be for the rtc to get up. I load it together with kernel and device tree. Seems to work.

[WarheadsSE]

Likely culprit is a lack of initialization of the GPIOs to a predefined state on the 3.13 kernel.