10:05 <gordan> Hmm... Just seen some weirdness with RTCs again.

10:05 <gordan> On 4.3

10:05 <gordan> Same behaviour as I'd seen on 4.1.12.

10:06 <gordan> s3c was out but settable, but max wasn't working before or after setting the s3c.

10:08 <gordan> Rebooted and the old behaviour returns (max works again, and seems to have remembered the correct time).

10:09 <gordan> And I bet 4.1.12 behaves the same way (I only booted it a few times, could have been a fluke that it didn't work every time when I tried it).

10:09 <gordan> So it could be an initialization race of some sort.

10:09 <gordan> On a completely unrelated note, is there a way to get access to the u-boot variables from userspace?

10:10 <gordan> Is there an MTD device driver I need to enable?

10:59 <gordan> u-boot seems to indicate it's a SPI device, I compiled the MTD SPI chip support (including SPI NOR), but /dev/mtd* modes still don't show up.

11:00 <gordan> Is the driver for the relevant chip not available in the Linux kernel even though it is in u-boot?

11:00 <gordan> Or did I just not build the correct one?

11:08 <sjoerd> gordan: if you chain load u-boot the u-boot vars would be just on mmc

11:08 <sjoerd> you can't really tweak the mmc vars on spi in a standard way

11:09 <gordan> Which MMC?

11:09 <gordan> I'm chain loading u-boot on a uSD card.

11:10 <gordan> And if I change the card to a different one, the u-boot variables stay the same.

11:10 <sjoerd> the uSD then

11:10 <gordan> So it's not kept on the uSD card even if u-boot is there.

11:10 <sjoerd> that's odd, i would have sworn the standard u-boot config for the exynos crheombooks put the vars on the mmc it got booted from

11:10 <sjoerd> check the u-boot config ? :)

11:11 <gordan> When I do saveenv it says it's writing to SPI W25Q32DW, 4KB erase block size 4MB total size.

11:14 <gordan> CONFIG_SPI_FLASH seems to be set in u-boot config.

11:14 <gordan> As is CONFIG_CROS_EC_SPI

11:16 <sjoerd> ah indeed

11:16 <sjoerd> then yeah it's on the SPI flash, surprising

11:17 <gordan> The question is, what driver do I need in the kernel to get access to it?

11:17 <sjoerd> iirc there are outstanding pathes for the spi device

11:18 <sjoerd> javier__ posted some, so he's the best to ask for the status

11:19 <gordan> I just want fw_printenv to work, so I can dump it out without having to take a photo of printenv in u-boot and transcribe it for the image installation howto. :p

11:21 <sjoerd> why do you need people to set u-boot variables?

11:21 <sjoerd> that would be sad

11:27 <gordan> Becsause I am positively hating how the standard boot process is set up.

11:27 <gordan> I replaced it with something a quarter of the size and an order of magnitude better legibility.

11:28 <gordan> The default u-boot process goes through a whole bunch of hoops, that eventually fails anyway if you deviate even slightly from the partitioning and boot process assumptions.

11:28 <gordan> So on the whole I fail to see the purpose of an elaborate, complex process that is just as fragile as a simple one, and less debuggable to boot.

11:29 <sjoerd> you have one bootable partition and put en extlinux.conf on it, that's it

11:29 <sjoerd> not sure what's so hard about that

11:29 <gordan> For example, my partitioning is: 1) ZFS pool, 2) u-boot binary, 3) squashfs partition, 4) /boot

11:30 <gordan> So I want u-boot to go find zImage and dtb on /boot, set the bootargs including root=/dev/mmcblk1p3 (sqhashfs) and zfsroot=poolname/ROOT, and get on with it.

11:31 <gordan> I haven't looked into extlinux.conf yet.

11:31 <gordan> Maybe I should.

11:31 <sjoerd> you should

11:31 <sjoerd> http://git.denx.de/?p=u-boot.git;a=blob_plain;f=doc/README.distro;hb=HEAD os a good read

11:31 <gordan> But that would make the u-boot process distillable even further, even smaller than what I use, which is already massively smaller than the u-boot default.

11:31 <sjoerd> not sure if the, it looks for a partition with the boot flag, is documented

11:32 <sjoerd> meh

11:32 <sjoerd> just don't change it and it should just work

11:32 <sjoerd> but your choice

11:34 <gordan> Put it this way, I took one look at the default variables and I thought it was enough of a mess to nuke it all and start from scratch.

11:37 <sjoerd> that just translates to "I didn't understand it, so i threw it away" :)

11:37 <sjoerd> but yes the default stuff is quite flexible and it will take a while to understand, u-boots scripting is not that awesome in that respect

11:38 <sjoerd> however for a user it should be quite convenient

11:53 <gordan> It's true, it does translate to that. It also translates to: "it wasn't obvious enough"

11:54 <daniels> one man's mess is another man's necessary complexity

11:55 <daniels> it depends on whether your goal is to have things work easily and portably (the people who designed those variables), or if your goal is to understand literally everything first-principles from scratch (you)

11:56 <gordan> True that. I'll take a look at the defaults again and into using either uEnv.txt or extlinuc.conf. If I can look for a partition with a boot flag and look for uEnv or extlinux, then I can probably make it both understandable from 1st principles and generic enough for same convenience as defaults.

12:01 <sjoerd> the documentation i pointed to exlains how these bits work without having to reverse engineer them

12:04 <sjoerd> daniels: there is that and it's essentially generated code from a bunch of macros, which makes it not be very optimised for reading in the first place

12:20 <javier__> gordan: CONFIG_CROS_EC_SPI has nothing to do with the SPI flash but is the driver used by u-boot to talk wit the Embedded Controller over SPI

12:21 <javier__> gordan: there are patches posted to access to the SPI, I posted some using spidev directly and other dev to use the mtd spi nor driver

12:21 <javier__> gordan: but the SPI is write protected so it will not be convenient for users anyways

12:22 <javier__> gordan: as sjoerd and daniels said, I suggest you take a lookt to the u-boot distro commands

12:44 <gordan> javier__ u-boot distro commands?

12:45 <gordan> Oh, righti

12:45 <gordan> I'll take another look at it.