01:22 <enkoder> can someone explain to me what the "ID Block" is? Any documentation on the structure of it?

02:30 <hipboi_> enkoder, Identify block

02:30 <hipboi_> enkoder, a block to store the information about the first part of bootloader

02:37 <enkoder> hipboi_: thanks. This is probably information that is under rockchips NDA, but do you have any other information? Like memory storage, structure of the binary, any tools to build, etc?

07:18 <premoboss> enkoder, there are too much NDA informatio with these soc. make it difficult do have a good software support.

07:25 <sjoerd> enkoder: It's just a block on the storage

07:25 <sjoerd> if you're using a 3288 board with emmc you luckily don't really have to care about it anymore

07:47 <naobsd> we know rc4 key, data layout, no problem

07:48 <naobsd> only OOB data on NAND are not yet supported

07:49 <naobsd> OOB data for writing

07:49 <naobsd> I'm not sure it's really required... at least it's not required for eMMC

07:50 <naobsd> loader knows OOB handling, so there is no reason to supply it from PC

08:19 <rperier> hi, do you know if the ethernet framework proposes a way to get a mac address from an eeprom device ? (an eeprom over i2c). I am talking about device drivers interfacing and dependencies handling here, I can of course write an i2c driver to read my eeprom but I don't know how to give this information to the ethernet driver :/

08:19 <rperier> that's just to know if some of you already did something like that, otherwise I will search on internet

08:21 <miqi> Have anyone tried hdmi audio on rk3288 with 4.4+ kernel ?

08:27 <miqi> rperier: why not just put the mac address on emmc or nandflash? e.g. misc partition :D

08:31 <mmind00> rperier: I think generally that gets to be uboot's task to read the mac from somewhere and put it into the devicetree it sends to the kernel?

08:33 <sjoerd> If it comes form the machine not the network card uboot reads it indeed

08:35 <sjoerd> rperier: in u-boot just call eth_setenv_enetaddr("ethaddr", <your ethernet accress>) and it'll get manged into the dts (assuming the dts is properly setup)

08:46 <rperier> miqi: because usually, when you buy a mac address you buy a memory with the address flashed into this memory. Here that's an eeprom

08:47 <rperier> well, we have a memory for that, I think you can also buy one without a memory... anyway...

08:49 <rperier> mmind00,sjoerd: you mean that uboot is able to change the kernel devicetree on the fly ? mhhh... the devicetree is not in NOR yet, I download everything via the network... I will think about it...

08:50 <sjoerd> yes

08:51 <sjoerd> rperier: u-boot loads the dtb into memory, adjusts it (also sets e.g. the amount of memory) before it boots the kernel

08:51 <rperier> that's not very clean... that's the really the bootloader's job... :/

08:51 <rperier> I mean, it's weird

08:56 <sjoerd> the bootloader is also where you can configure it, e.g. by saving a custom one in its environment

09:07 <rperier> well... I agree

15:13 <sjoerd> mmind00: hrm, looks like the debian kernel added the IO domain driver as a module.. wonder if that's a sensible thing to do

15:13 <sjoerd> (which i guess makes me wonder if it should be a tristate in the first place)

15:16 <mmind00> sjoerd: interesting constellation ... io-domains will defer until the pmic is probed, but nobody is hindering the mmc to drop the card-voltage without the soc getting notified

15:18 <mmind00> both pmic + dw_mmc can be built in or be modules (other users probably as well), so nothing is speaking against io-domains being a module in general

15:19 <sjoerd> This is true

15:19 <sjoerd> otoh there are some probing order issues here for sure

15:20 <sjoerd> if the mmc/sdio slots get probed before the io-domain is setup then fun will happen

15:20 <sjoerd> (unless the defaults are correct)

16:15 <naobsd> https://android.googlesource.com/platform/hardware/bsp/kernel/common/v4.1 oh is kylin brillo device?

16:20 <mmind00> sjoerd: yep, although the fun is pretty safe ... i.e. 3.3V is of course the default, so it just won't tune instead of frying stuff ;-)

16:25 <sjoerd> mmind00: No, but i bet it's the reason i had all those issues with getting the wirelss card recogniseed

16:25 <sjoerd> It won't fry the board, but things don't work as expected necessarily either

16:25 <sjoerd> (the wireless cards is at 1.8v

16:34 <mmind00> sjoerd: yep ... I guess one could make the dw_mmc-rockchip look for the io-domain presence in some way

16:37 <Astralix> hey guys. I ever wondered about how the kernel decides about the correct sequence of starting internal / external modules. However here it always worked so I never did a deeper inspection…

16:38 <Astralix> But I thought that if you put a pin definition setting into the FDT and add a reference to it in a device section on the FDT too, it should fire up the GPIO driver

16:40 <Astralix> However that must fail at a point where you load the rootfs from a device that needs to have GPIOs tuned but it needs to load gpio module from that rootfs... So I never ever would put the gpio module outside of the kernel itself...

17:22 <enkoder> sjoerd: what do you mean by this "if you're using a 3288 board with emmc you luckily don't really have to care about it anymore"

17:22 <enkoder> Whats special about a 3288 device? I have a radxa rock2 which is rk3288 based

17:33 <mmind00> enkoder: (1) way better mainline kernel-support, (2) mainline uboot support, (3) resulting in: you can just remove the Rockchip partition scheme and use a regular partition table

17:34 <mmind00> enkoder: and (3) is limited to emmc devices ... won't work with nand

18:14 <enkoder> mmind00: noice! I like all of those things.

18:34 <enkoder> mmind00: How do you get mainline u-boot on an rk3288 device (firefly or radxa rock2)? rkflashtool? upgrade_tool?

18:34 <enkoder> The lack of informatiopn regarding the mask rom mode and their loader is making things difficult for me,

18:47 <sjoerd> mmind00: makes me wonder if iodomainsshouldn't be more low power domains

18:57 <mmind00> sjoerd: I guess other socs maybe just can detect the voltage they get supplied with?

18:59 <mmind00> sjoerd: the rockchip io-domain function is really only to tell the soc if it gets supplied with 3.3V or 1.8V on a given input at that moment

20:59 <patrik> Hey!

20:59 <patrik> someone there?

21:12 <sjoerd> mmind00: hmm