Reported by Nikolaus Schaller, Feb 8, 2015
for the reworked beagle board, please use gta04-makesd with this command: DEV=/dev/sdc ./makesd -v unstable bb+b7 Currently known issues: * BB complains about I2C problems on I2C2 if no device is connected (although pinmux and pull-up is enabled). Works if an expansion board with external pull-ups is connected. I2C3 also works * X-Loader hangs if we enable NAND (reason might be that the Samsung Chip uses OneNAND interface). Might need changing the SYSBOOT resistors. * U-Boot does not find NAND as well * Kernel is also not configured for OneNAND * Kernel does only find 512 MB - even if we specify the memory record like for n950/n9
Comment 1 by Joerg Reisenweber, Feb 10, 2015
for SYS_BOOT: sys_boot5=0: sys_boot[4:0]=0b10000 --> OneNAND USB UART3 MMC1 sys_boot5=1: sys_boot[4:0]=0b10000 --> USB UART3 MMC1 OneNAND For Neo900 SYS_BOOT5 should be default=0, and 1 when some hw-button gets pressed (TBD)
Comment 2 by Nikolaus Schaller, Feb 13, 2015
1. I2C2 hang w/o external pull-ups: is solved. Issue was that DM3730 ignores the PULLUP pinmux definitions (while the OMAP3530 doesn't). Setting a register bit in some control register (which is also different from OMAP3530) fixes this. 2. Kernel RAM size: in a discussion about device trees for the OpenPandora specifying the memory size in the Device Tree, it turned out that the DT entry is simply ignored. Rather, the real memory size is passed as ATAG information by U-Boot to the Kernel and explicitly overwrites the /memory property of the device tree blob - after loading into RAM. This can be seen by 'xxd /proc/device-tree/memory'. So the RAM size is solved for the kernel as soon as we have fixed it for U-Boot (which also reports only 512 MByte RAM). 3. SYSBOOT HW button: GTA04 has a similar function - by pressing the AUX button during power-on, the boot order is swapped. This allows to enforce booting from MMC/SD even if NAND is completely bricked. On Neo900, maybe we can (re)use the camera shutter button. Alternatively one of the volume control buttons, but there we thought about adding them to the keyboard scan matrix - which prohibits a parallel function to change sys_boot5. Especially, using sys_boot5 allows to "save" one dedicated GPIO since sys_boot5 can also be reprogrammed as a button gpio after boot (or by the kernel) so that it gets this dual-role.
Comment 3 by Joerg Reisenweber, Feb 13, 2015
3. SYS_BOOT5: Please use IR-proxy-sensor for battery lid. ToBeChecked: V28 VDD hall switch supply stable before CPU comes out of POR reset state and samples the SYS_BOOT pins
Comment 4 by Nikolaus Schaller, Feb 13, 2015
Well, I would not choose the IR lid. It requires the user to remove the battery lid to unbrick. This does not allow to boot normally with open battery lid. Please also think about us developers who want to debug/test a naked board where we just connect a battery. Even then, this emergency boot should be easily accessible. If V28 VDD is supplied by some VAUX (have not looked into current schematics) is is not stable at power-on-reset since X-Loader/Kernel sets the right voltage. And, one more thing to check: is the polarity of the sensor correct or inverted? That is why I propose the camera button, but it might still be the wrong thing.
Comment 5 by Joerg Reisenweber, Feb 13, 2015
Device will boot from MMC1 anyway when OneNAND xLoader is defect: sys_boot5=0: sys_boot[4:0]=0b10000 --> OneNAND USB UART3 MMC1 The SYS_BOOT5 switch is only needed when xLoader looks good to ROMBOOT but actually hangs. Batt lid is Hall switch, sorry when I said IR somewhere. In lab it's simple enough run device without battery lid. In usual in-the-field every day usage the batt lid removal seems the right and most secure thing to use for this security-related feature *) since you never will want to boot from USB to override xLoader in OneNAND in a pub. The other options (cam switch etc) are "reserved" for more common useful usecases that regular users are interested in, like bringing up uBoot menu. *) main purpose being to avoid rogue "USB chargers" in pubs or wherever hijacking the device via coldflashing (ROMBOOT -> USB xLoader) attack vector. The V28 early stability is a concern, we need to work that out properly. When VAUX of TWL4030 starts up to a sufficient voltage before CPU configures it, then we're fine. Hall switch VDD_min might be <2V8, maybe it's sufficiently low for what VAUX comes up with. Polarity is also ToBeChecked and a inverter (or inverted logic Hall switch) added/chosen if needed.
Comment 6 by Joerg Reisenweber, Feb 13, 2015
Note that developers who want to regularly boot xLoader from MMC1 are free to simply nuke the OneNAND xLoader and the boot sequence will eventually fall through to MMC1 no matter if battery lid removed or not. Likewise even with battery lid removed the device will boot from OneNAND xLoader when no xLoader found on MMC1. Actually we need an addirional 0R "jumper" for SYS_BOOT5 that allows users to solder-hardwire the "OneNAND USB UART3 MMC1" sequence so they can completely protect their device against any threat from attackers that have 5 min access to device (the "left device on table in pub" scenario, also known as "cleaning woman" scenario).
Comment 7 by Nikolaus Schaller, Feb 13, 2015
There is a situation where boot loader in NAND is partially broken and does not look for U-Boot. Then, there is no automatic fall-through. Fall-though is only if it is not found. But I have to admit that it is a rare situation. Mixing boot order and bringing up u-boot menu on a single button is no problem on the GTA04. Polarity: hall switch is active if magnet found (lid closed). Has an open collector output. lid closed => pulled down => 0 => OneNAND USB UART3 MMC1 Looks ok. Maybe the hall switch can run from 1.8V? 1.8V is definitively stable. The one used in the OpenPandora/Pyra does.
Comment 8 by Nikolaus Schaller, Feb 13, 2015
0R solution needs two alternatively installed 0R (hall <-0R-> sysboot5 <-0R-> GND. Since otherwise it would short the hall sensor output. And note, that we have two GPIOs with the same value (hall sensor + sysboot5 gpio) in normal state (resistors not swapped).
Comment 9 by Joerg Reisenweber, Feb 13, 2015
shorting hall sensor out doesn't sound like a problem in itself, given it's OpenCollector. In N900 the N5210 hall switch is connected to CardDetect GPIO160. In Neo900 we conect card tray integrated switch to GPIO160, and we move the Hall to SYS_BOOT5. No parallel second GPIO input when we can't spare one. When user wants to hardwire their device to highest security config by shorting the Hall switch to forbid skipping OneNAND xLoader, they will have to live with no battery lid removal detector then - maybe.
Comment 10 by Nikolaus Schaller, Feb 13, 2015
The problem is not shorting the hall sensor output but reading which state it would have wanted to tell the world :) Therefore I suggest this 2xR0 approach. Either connect the hall sensor to sys-boot or ground sys-boot. And always connect the hall switch to gpio160. You can even place the resitor footprints so that they overlap and you can either install the single 0R it to the left or to the right.
Comment 11 by Joerg Reisenweber, Feb 13, 2015
GPIO160 goes to mem card tray switch. For Hall switch we need to find one or two new GPIO anyway, one of them being SYS_BOOT5
Comment 12 by Joerg Reisenweber, Mar 11, 2015
just a reference to the SYSBOOT resistors (and user switch, to switch between SYSBOOT=1 and SYSBOOT=0) http://wstaw.org/m/2015/03/10/plasma-desktopuR1893.png