Robert Nelson <robertcnelson@...> writes: > > On Tue, Aug 5, 2014 at 9:30 AM, <penou87@...> wrote: > > Hi, > > > > I'm currently working on a custom BeagleBone Black of ours and I have a few > > problem. The electronic is the same except that there is no graphic chip and > > no EEPROM. > > > > I'm booting on a µSD card the Angstrom distribution used in the BBB. The > > board is working well except that I have the following message during the > > boot "[ 5.561536] bone-capemgr bone_capemgr.9: Failed to scan baseboard > > eeprom". > > > > This is perfectly normal because I have no EEPROM. My problem is that I > > didn't know that the EEPROM was mandatory to initialize the cape manager. > > Thus, my EMMC is not loaded by the OS. > > > > I already tried to enable the cape with the uEnv.txt but it did nothing. > > I also tried to load it manually but in my cape manager folder there is no > > "slot" file so i guess that the cape manager is simply OFF. > > > > Is there a way to bypass the EEPROM and to load by default the EMMC cape ? > > I'm actually going through the kernel compilation, i'm afraid that I can't > > avoid it. > > Does someone have any experience on this ? > > Mainline kernel has the eMMC setup by default in the dts... > > Since you didn't specify a need for v3.8.x/capemgr, it's a viable option. ;) > > Regards, >
Hi Robert, Thank you, it's a good news. The main reason I stayed on the 3.8 kernel version is because I wanted to use the same kernel that was in the BBB. But it appears that the work you made on the capemgr will be of help for my custom board. However, now I have another problem. I'm trying unsuccessfuly to use this flasher: http://elinux.org/BeagleBoardUbuntu#eMMC:_BeagleBone_Black The problem is that the u-boot and the MLO doesn't have a default dtb. And since I don't have a EEPROM, the boot is stuck. I tried to use the MLO from the BBB, which seems to be OK. And now I'm trying to use the uEnv.txt file to pass the BBB arguments to the u-boot but I still can't boot properly. The error that I can't resolve is essentially: Bad Linux ARM zImage magic! I know that the EEPROM should contain this: struct am335x_baseboard_id { unsigned int magic; char name[HDR_NAME_LEN]; char version[4]; char serial[12]; char config[32]; char mac_addr[HDR_NO_OF_MAC_ADDR][HDR_ETH_ALEN]; }; Does this problem have something to do with the magic argument ? Is it eady to resolv ? Best regards, Julien -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
