Okay so digging into the forums it looks like my board id is not getting passed from u-boot to kernel. What is the process to write board_id to EEPROM?
Okay digging in a bit more this issue is definitely due to the fact I am using upstream U-Boot 2015.04-00030 that I have made compatible with android fastboot and boota and the upstream fails when I add the serial epprom flags:
/* The following are used to retrieve the board id from an eeprom */
#define CONFIG_SERIAL_EEPROM
#define EEPROM_I2C_BUS 1
#define EEPROM_I2C_ADDRESS 0x56
#define EEPROM_SERIAL_OFFSET 0x04
#define NUM_SERIAL_ID_BYTES 8
compilation error:
LD u-boot
board/nvidia/common/built-in.o: In function `get_board_serial':
/home/matt/Apalis-TK1/u-boot/board/nvidia/common/../../nvidia/common/board.c:290: undefined reference to `i2c_set_bus_num'
/home/matt/Apalis-TK1/u-boot/board/nvidia/common/../../nvidia/common/board.c:292: undefined reference to `i2c_read'
Why don’t you uncomment the BOARDID line in the jetson-tk1.conf in the linux_for_tegra folder where the flasher is located. That probably should override the problem.
That is one of the very first things I tried without success. You can see this same exact error reported all over the NXP community also but no one has seem to addressed it. The error seems to be associated with the same error one gets with a bad removable sdcard so the code must be in the board-sdhci file or the tegra mmc sdhci driver code. Ive examined the code and I cant see any reference to an mmc2 card the only thing I can think of is the bcmhd driver uses an sdio mmc interface for wifi on some tegra boards so the code is trying to load this and halts the system. I really am stumped on this error…
I’m also struggling with the tegra’s sdhci interface now to enable a wifi, so I can feel you…
It’s really annoying that there’s no support at all for the tk1.
If I think or find something about your issue I will come back.
Also, as I had other problems with sdmmc3 which is used by default from Jetson and it’s hardcoded in the kernel, I had the same timeouts (for another reason of course), so what I’ve did was to move the sdmmc3 pins to the unused section in arch/arm/boot/dts/tegra124-pinmux.dtsi
mmc2 is the device name that the kernel assignes to the interface. So if you only have enable sdmmc3 and sdmmc4, then probably mmc0=sdmmc4 and mmc1=sdmm3. I think that in mmc(x), x is usually the .id of the platform_device in the board file, but I’m not really sure about that.
To find which sdhci-tegra interface is assigned to each mmc device, just check the kernel output.
For example in my case I have the following assigns:
[ 5.302607] mmc0: SDHCI controller on sdhci-tegra.3 [sdhci-tegra.3] using ADMA
...
[ 5.393608] mmc1: SDHCI controller on sdhci-tegra.0 [sdhci-tegra.0] using ADMA
...
[ 6.022615] mmc2: SDHCI controller on sdhci-tegra.1 [sdhci-tegra.1] using ADMA
...
Which means that sdhci-tegra.3 → mmc0, sdhci-tegra.0 → mmc1 and sdhci-tegra.1 → mmc2.
Therefore, in my case if mmc2 timeouts then I have to move the sdhci-tegra.1 gpios to the unused pins and of course, disable the corresponding sdhci@78000x00 in the devicetree.
Okay so I noticed all references to sdmmc1 were already set to pinmux_unused_lowpower: unused_lowpower so I moved them to the enabled section just for a test. And in my soc dts includes they are disabled like this:
sdhci@700b0600 {
status = "disabled";
};
sdhci@700b0400 {
status = "disabled";
};
sdhci@700b0200 {
status = "disabled";
};
sdhci@700b0000 {
status = "disabled";
};
Then you have the opposite problem, which means that the sdmmc1 is enabled in the board-ardbeg-sdhci.c file (it’s somewhere at the end of the file) and at the same time you’ve set the pins as unused.
In that case the mmc timeouts because is enabled in the board file but the pins are disabled, therefore it timeouts. Either leave the gpios as unused and remove from the board-ardbeg-sdhci.c the line that sdmmc1 is registered or just move the gpios to the non-unused part of the devicetree file. I think the first approach is better.
I don’t have a kernel now, so I couldn’t see the exact code in my previous answer, but now I’ve found a file on the internet, so in arch/arm/mach-tegra/board-ardbeg-sdhci.c you’ll find in function ardbeg_sdhci_init() that there are some calls at the end that register the sdhci platform devices with a function call like
platform_device_register(&tegra_sdhci_device1)
This means that you’ll also have to remove the call that registers the sdmmc device that timeouts in your case. You can do that by searching in the file the struct that belongs to the parameter that is passed in the function. So, you probably have a tegra_sdhci_device1 struct that has the .id = 1.
Now, if you actually remove the platform_device_register(&tegra_sdhci_devicex) line, I think that the kernel doesn’t compile as the struct is declared but not used, so better use something like that: