IO Error writing to MMC BeagleBone Black
Locked
 
|
I recently decided to play with my BBB boards after ignoring them for a few years (one of them still had 5.6 installed on it!). I have 3 BeagleBone Black boards (2 with 2GB, 1 with 4GB). When i dd’ed miniroot-am335x-68.img to a uSD cards and booted it, it all seemed pretty normal until I got to the part where it actually writes to the onboard storage. It would fail due to IO errors. This happened on all 3 of my boards. I figured it was unlikely that all 3 would have bad flash so I re-imaged one with with a supported debian distro and it worked just fine.
Is there an issue with writing to the onboard storage in 6.8 or is there some step I missed in the startup phase to get it working? Thanks! |
|
|
It might have gotten mounted read-only for some reason.
BTW I'm seen a few cases now where a bad SD card could be fixed by reformatting then reloading. Stick it in something else like a camera to format it, then reimage it back to Linux. May not be 100% reliable. On Sat, Mar 20, 2021, 10:46 AM Jordon <[hidden email]> wrote: > I recently decided to play with my BBB boards after ignoring them for a > few years (one of them still had 5.6 installed on it!). I have 3 > BeagleBone Black boards (2 with 2GB, 1 with 4GB). When i dd’ed > miniroot-am335x-68.img to a uSD cards and booted it, it all seemed pretty > normal until I got to the part where it actually writes to the onboard > storage. It would fail due to IO errors. This happened on all 3 of my > boards. I figured it was unlikely that all 3 would have bad flash so I > re-imaged one with with a supported debian distro and it worked just fine. > Is there an issue with writing to the onboard storage in 6.8 or is there > some step I missed in the startup phase to get it working? > > Thanks! > > > |
|
|
In reply to this post by jordon-7
On 3/20/21 1:28 PM, Jordon wrote:
> I recently decided to play with my BBB boards after ignoring them for a few years (one of them still had 5.6 installed on it!). I have 3 BeagleBone Black boards (2 with 2GB, 1 with 4GB). When i dd’ed miniroot-am335x-68.img to a uSD cards and booted it, it all seemed pretty normal until I got to the part where it actually writes to the onboard storage. It would fail due to IO errors. This happened on all 3 of my boards. I figured it was unlikely that all 3 would have bad flash so I re-imaged one with with a supported debian distro and it worked just fine. > Is there an issue with writing to the onboard storage in 6.8 or is there some step I missed in the startup phase to get it working? > > Thanks! > > with my BBB[1] I've never used the onboard storage I just boot the uSD with OpenBSD on. The output from fdisk is shown below [2]. Cheers Fred [1] bbb:fred ~> dmesg|head OpenBSD 6.8 (GENERIC) #337: Wed Oct 7 01:35:49 MDT 2020 [hidden email]:/usr/src/sys/arch/armv7/compile/GENERIC real mem = 477290496 (455MB) avail mem = 457314304 (436MB) [2] bbb:fred ~> doas fdisk sd0 doas ([hidden email]) password: Disk: sd0 geometry: 233/255/63 [3751936 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start: size ] ------------------------------------------------------------------------------- *0: 0C 0 1 1 - 8 254 63 [ 63: 144522 ] FAT32L 1: 83 9 0 1 - 232 254 63 [ 144585: 3598560 ] Linux files* 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused bbb:fred ~> doas fdisk sd1 Disk: sd1 geometry: 966/255/63 [15523840 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start: size ] ------------------------------------------------------------------------------- *0: 0C 0 32 33 - 2 42 40 [ 2048: 32768 ] FAT32L 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: A6 2 42 41 - 966 80 10 [ 34816: 15489024 ] OpenBSD |
|
|
man mount, then type /read-only to search, / to search for the same thing
again. Sometimes a read-only mount happens if thare's something wrong. But reformat and try reloading before you throw it away. On Sat, Mar 20, 2021, 3:30 PM Fred <[hidden email]> wrote: > On 3/20/21 1:28 PM, Jordon wrote: > > I recently decided to play with my BBB boards after ignoring them for a > few years (one of them still had 5.6 installed on it!). I have 3 > BeagleBone Black boards (2 with 2GB, 1 with 4GB). When i dd’ed > miniroot-am335x-68.img to a uSD cards and booted it, it all seemed pretty > normal until I got to the part where it actually writes to the onboard > storage. It would fail due to IO errors. This happened on all 3 of my > boards. I figured it was unlikely that all 3 would have bad flash so I > re-imaged one with with a supported debian distro and it worked just fine. > > Is there an issue with writing to the onboard storage in 6.8 or is there > some step I missed in the startup phase to get it working? > > > > Thanks! > > > > > > with my BBB[1] I've never used the onboard storage I just boot the uSD > with OpenBSD on. The output from fdisk is shown below [2]. > > Cheers > > Fred > > [1] > bbb:fred ~> dmesg|head > OpenBSD 6.8 (GENERIC) #337: Wed Oct 7 01:35:49 MDT 2020 > [hidden email]:/usr/src/sys/arch/armv7/compile/GENERIC > real mem = 477290496 (455MB) > avail mem = 457314304 (436MB) > > [2] > bbb:fred ~> doas fdisk sd0 > doas ([hidden email]) password: > Disk: sd0 geometry: 233/255/63 [3751936 Sectors] > Offset: 0 Signature: 0xAA55 > Starting Ending LBA Info: > #: id C H S - C H S [ start: size ] > > ------------------------------------------------------------------------------- > *0: 0C 0 1 1 - 8 254 63 [ 63: 144522 ] > FAT32L > 1: 83 9 0 1 - 232 254 63 [ 144585: 3598560 ] > Linux files* > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] > unused > 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] > unused > bbb:fred ~> doas fdisk sd1 > Disk: sd1 geometry: 966/255/63 [15523840 Sectors] > Offset: 0 Signature: 0xAA55 > Starting Ending LBA Info: > #: id C H S - C H S [ start: size ] > > ------------------------------------------------------------------------------- > *0: 0C 0 32 33 - 2 42 40 [ 2048: 32768 ] > FAT32L > 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] > unused > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] > unused > 3: A6 2 42 41 - 966 80 10 [ 34816: 15489024 ] > OpenBSD > > |
|
|
The issue is not the sd card - it is the onboard emmc. I dd’ed the miniroot image to a micro sd card. I the boot the bbb and run the installer. I set the install drive to the onboard emmc drive and when it tries to write to it, I get io errors. This used to work, as i had 5.6 on one of my bbb’s and 5.8 on another, both booting without micro sd cards in them.
I have received messages that suggest that this never worked, but I know I did this years ago following a post from tedu’s website. And i did flash the debian ‘flasher’ image to the micro sd card, booted it, and had it run through its reimaging process, and afterwards the bbb booted debian just fine, so the micro sd card and the emmc are both functional. > On Mar 20, 2021, at 14:52, Alan Corey <[hidden email]> wrote: > > man mount, then type /read-only to search, / to search for the same thing > again. Sometimes a read-only mount happens if thare's something wrong. > > But reformat and try reloading before you throw it away. > >> On Sat, Mar 20, 2021, 3:30 PM Fred <[hidden email]> wrote: >> >>> On 3/20/21 1:28 PM, Jordon wrote: >>> I recently decided to play with my BBB boards after ignoring them for a >> few years (one of them still had 5.6 installed on it!). I have 3 >> BeagleBone Black boards (2 with 2GB, 1 with 4GB). When i dd’ed >> miniroot-am335x-68.img to a uSD cards and booted it, it all seemed pretty >> normal until I got to the part where it actually writes to the onboard >> storage. It would fail due to IO errors. This happened on all 3 of my >> boards. I figured it was unlikely that all 3 would have bad flash so I >> re-imaged one with with a supported debian distro and it worked just fine. >>> Is there an issue with writing to the onboard storage in 6.8 or is there >> some step I missed in the startup phase to get it working? >>> >>> Thanks! >>> >>> >> >> with my BBB[1] I've never used the onboard storage I just boot the uSD >> with OpenBSD on. The output from fdisk is shown below [2]. >> >> Cheers >> >> Fred >> >> [1] >> bbb:fred ~> dmesg|head >> OpenBSD 6.8 (GENERIC) #337: Wed Oct 7 01:35:49 MDT 2020 >> [hidden email]:/usr/src/sys/arch/armv7/compile/GENERIC >> real mem = 477290496 (455MB) >> avail mem = 457314304 (436MB) >> >> [2] >> bbb:fred ~> doas fdisk sd0 >> doas ([hidden email]) password: >> Disk: sd0 geometry: 233/255/63 [3751936 Sectors] >> Offset: 0 Signature: 0xAA55 >> Starting Ending LBA Info: >> #: id C H S - C H S [ start: size ] >> >> ------------------------------------------------------------------------------- >> *0: 0C 0 1 1 - 8 254 63 [ 63: 144522 ] >> FAT32L >> 1: 83 9 0 1 - 232 254 63 [ 144585: 3598560 ] >> Linux files* >> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] >> unused >> 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] >> unused >> bbb:fred ~> doas fdisk sd1 >> Disk: sd1 geometry: 966/255/63 [15523840 Sectors] >> Offset: 0 Signature: 0xAA55 >> Starting Ending LBA Info: >> #: id C H S - C H S [ start: size ] >> >> ------------------------------------------------------------------------------- >> *0: 0C 0 32 33 - 2 42 40 [ 2048: 32768 ] >> FAT32L >> 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] >> unused >> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] >> unused >> 3: A6 2 42 41 - 966 80 10 [ 34816: 15489024 ] >> OpenBSD >> >> |
|
|
They do wear out, mine in my Pinebook Pro was about a year old when I
was seeing strange crashes. Loaded up a brand new SD card and I get uptimes of a week or more. And refomatting a misbehaving sd or emmc sometimes works wonders for ueexplainable reasons, it's like it needs to be refreshed periodically.. On 3/21/21, Jordon <[hidden email]> wrote: > The issue is not the sd card - it is the onboard emmc. I dd’ed the miniroot > image to a micro sd card. I the boot the bbb and run the installer. I set > the install drive to the onboard emmc drive and when it tries to write to > it, I get io errors. This used to work, as i had 5.6 on one of my bbb’s and > 5.8 on another, both booting without micro sd cards in them. > > I have received messages that suggest that this never worked, but I know I > did this years ago following a post from tedu’s website. > > And i did flash the debian ‘flasher’ image to the micro sd card, booted it, > and had it run through its reimaging process, and afterwards the bbb booted > debian just fine, so the micro sd card and the emmc are both functional. > > >> On Mar 20, 2021, at 14:52, Alan Corey <[hidden email]> wrote: >> >> man mount, then type /read-only to search, / to search for the same >> thing >> again. Sometimes a read-only mount happens if thare's something wrong. >> >> But reformat and try reloading before you throw it away. >> >>> On Sat, Mar 20, 2021, 3:30 PM Fred <[hidden email]> wrote: >>> >>>> On 3/20/21 1:28 PM, Jordon wrote: >>>> I recently decided to play with my BBB boards after ignoring them for a >>> few years (one of them still had 5.6 installed on it!). I have 3 >>> BeagleBone Black boards (2 with 2GB, 1 with 4GB). When i dd’ed >>> miniroot-am335x-68.img to a uSD cards and booted it, it all seemed >>> pretty >>> normal until I got to the part where it actually writes to the onboard >>> storage. It would fail due to IO errors. This happened on all 3 of my >>> boards. I figured it was unlikely that all 3 would have bad flash so I >>> re-imaged one with with a supported debian distro and it worked just >>> fine. >>>> Is there an issue with writing to the onboard storage in 6.8 or is >>>> there >>> some step I missed in the startup phase to get it working? >>>> >>>> Thanks! >>>> >>>> >>> >>> with my BBB[1] I've never used the onboard storage I just boot the uSD >>> with OpenBSD on. The output from fdisk is shown below [2]. >>> >>> Cheers >>> >>> Fred >>> >>> [1] >>> bbb:fred ~> dmesg|head >>> OpenBSD 6.8 (GENERIC) #337: Wed Oct 7 01:35:49 MDT 2020 >>> [hidden email]:/usr/src/sys/arch/armv7/compile/GENERIC >>> real mem = 477290496 (455MB) >>> avail mem = 457314304 (436MB) >>> >>> [2] >>> bbb:fred ~> doas fdisk sd0 >>> doas ([hidden email]) password: >>> Disk: sd0 geometry: 233/255/63 [3751936 Sectors] >>> Offset: 0 Signature: 0xAA55 >>> Starting Ending LBA Info: >>> #: id C H S - C H S [ start: size ] >>> >>> ------------------------------------------------------------------------------- >>> *0: 0C 0 1 1 - 8 254 63 [ 63: 144522 ] >>> FAT32L >>> 1: 83 9 0 1 - 232 254 63 [ 144585: 3598560 ] >>> Linux files* >>> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] >>> unused >>> 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] >>> unused >>> bbb:fred ~> doas fdisk sd1 >>> Disk: sd1 geometry: 966/255/63 [15523840 Sectors] >>> Offset: 0 Signature: 0xAA55 >>> Starting Ending LBA Info: >>> #: id C H S - C H S [ start: size ] >>> >>> ------------------------------------------------------------------------------- >>> *0: 0C 0 32 33 - 2 42 40 [ 2048: 32768 ] >>> FAT32L >>> 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] >>> unused >>> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] >>> unused >>> 3: A6 2 42 41 - 966 80 10 [ 34816: 15489024 ] >>> OpenBSD >>> >>> > > -- ------------- Education is contagious. |
|
|
I just ran the installer for 5.7 and it had no problems writing to the emmc. Tomorrow after work i might try bisecting to see what the last functional version was, but it really looks like there was a regression at some point.
> On Mar 21, 2021, at 16:41, Alan Corey <[hidden email]> wrote: > > They do wear out, mine in my Pinebook Pro was about a year old when I > was seeing strange crashes. Loaded up a brand new SD card and I get > uptimes of a week or more. And refomatting a misbehaving sd or emmc > sometimes works wonders for ueexplainable reasons, it's like it needs > to be refreshed periodically.. > >> On 3/21/21, Jordon <[hidden email]> wrote: >> The issue is not the sd card - it is the onboard emmc. I dd’ed the miniroot >> image to a micro sd card. I the boot the bbb and run the installer. I set >> the install drive to the onboard emmc drive and when it tries to write to >> it, I get io errors. This used to work, as i had 5.6 on one of my bbb’s and >> 5.8 on another, both booting without micro sd cards in them. >> >> I have received messages that suggest that this never worked, but I know I >> did this years ago following a post from tedu’s website. >> >> And i did flash the debian ‘flasher’ image to the micro sd card, booted it, >> and had it run through its reimaging process, and afterwards the bbb booted >> debian just fine, so the micro sd card and the emmc are both functional. >> >> >>>> On Mar 20, 2021, at 14:52, Alan Corey <[hidden email]> wrote: >>> >>> man mount, then type /read-only to search, / to search for the same >>> thing >>> again. Sometimes a read-only mount happens if thare's something wrong. >>> >>> But reformat and try reloading before you throw it away. >>> >>>> On Sat, Mar 20, 2021, 3:30 PM Fred <[hidden email]> wrote: >>>> >>>>> On 3/20/21 1:28 PM, Jordon wrote: >>>>> I recently decided to play with my BBB boards after ignoring them for a >>>> few years (one of them still had 5.6 installed on it!). I have 3 >>>> BeagleBone Black boards (2 with 2GB, 1 with 4GB). When i dd’ed >>>> miniroot-am335x-68.img to a uSD cards and booted it, it all seemed >>>> pretty >>>> normal until I got to the part where it actually writes to the onboard >>>> storage. It would fail due to IO errors. This happened on all 3 of my >>>> boards. I figured it was unlikely that all 3 would have bad flash so I >>>> re-imaged one with with a supported debian distro and it worked just >>>> fine. >>>>> Is there an issue with writing to the onboard storage in 6.8 or is >>>>> there >>>> some step I missed in the startup phase to get it working? >>>>> >>>>> Thanks! >>>>> >>>>> >>>> >>>> with my BBB[1] I've never used the onboard storage I just boot the uSD >>>> with OpenBSD on. The output from fdisk is shown below [2]. >>>> >>>> Cheers >>>> >>>> Fred >>>> >>>> [1] >>>> bbb:fred ~> dmesg|head >>>> OpenBSD 6.8 (GENERIC) #337: Wed Oct 7 01:35:49 MDT 2020 >>>> [hidden email]:/usr/src/sys/arch/armv7/compile/GENERIC >>>> real mem = 477290496 (455MB) >>>> avail mem = 457314304 (436MB) >>>> >>>> [2] >>>> bbb:fred ~> doas fdisk sd0 >>>> doas ([hidden email]) password: >>>> Disk: sd0 geometry: 233/255/63 [3751936 Sectors] >>>> Offset: 0 Signature: 0xAA55 >>>> Starting Ending LBA Info: >>>> #: id C H S - C H S [ start: size ] >>>> >>>> ------------------------------------------------------------------------------- >>>> *0: 0C 0 1 1 - 8 254 63 [ 63: 144522 ] >>>> FAT32L >>>> 1: 83 9 0 1 - 232 254 63 [ 144585: 3598560 ] >>>> Linux files* >>>> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] >>>> unused >>>> 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] >>>> unused >>>> bbb:fred ~> doas fdisk sd1 >>>> Disk: sd1 geometry: 966/255/63 [15523840 Sectors] >>>> Offset: 0 Signature: 0xAA55 >>>> Starting Ending LBA Info: >>>> #: id C H S - C H S [ start: size ] >>>> >>>> ------------------------------------------------------------------------------- >>>> *0: 0C 0 32 33 - 2 42 40 [ 2048: 32768 ] >>>> FAT32L >>>> 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] >>>> unused >>>> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] >>>> unused >>>> 3: A6 2 42 41 - 966 80 10 [ 34816: 15489024 ] >>>> OpenBSD >>>> >>>> >> >> > > > -- > ------------- > Education is contagious. |
|
|
6.6 was the last release that works. 6.7 and 6.8 throw an input/output error when it tries to create the partitions (right after you choose ‘(W)hole disk’).
Am I the only person to try installing it to onboard storage in the last year? Or am I doing something wrong? > On Mar 21, 2021, at 23:26, Jordon <[hidden email]> wrote: > > I just ran the installer for 5.7 and it had no problems writing to the emmc. Tomorrow after work i might try bisecting to see what the last functional version was, but it really looks like there was a regression at some point. > > > >> On Mar 21, 2021, at 16:41, Alan Corey <[hidden email]> wrote: >> >> They do wear out, mine in my Pinebook Pro was about a year old when I >> was seeing strange crashes. Loaded up a brand new SD card and I get >> uptimes of a week or more. And refomatting a misbehaving sd or emmc >> sometimes works wonders for ueexplainable reasons, it's like it needs >> to be refreshed periodically.. >> >>>> On 3/21/21, Jordon <[hidden email]> wrote: >>> The issue is not the sd card - it is the onboard emmc. I dd’ed the miniroot >>> image to a micro sd card. I the boot the bbb and run the installer. I set >>> the install drive to the onboard emmc drive and when it tries to write to >>> it, I get io errors. This used to work, as i had 5.6 on one of my bbb’s and >>> 5.8 on another, both booting without micro sd cards in them. >>> >>> I have received messages that suggest that this never worked, but I know I >>> did this years ago following a post from tedu’s website. >>> >>> And i did flash the debian ‘flasher’ image to the micro sd card, booted it, >>> and had it run through its reimaging process, and afterwards the bbb booted >>> debian just fine, so the micro sd card and the emmc are both functional. >>> >>> >>>>> On Mar 20, 2021, at 14:52, Alan Corey <[hidden email]> wrote: >>>> >>>> man mount, then type /read-only to search, / to search for the same >>>> thing >>>> again. Sometimes a read-only mount happens if thare's something wrong. >>>> >>>> But reformat and try reloading before you throw it away. >>>> >>>>> On Sat, Mar 20, 2021, 3:30 PM Fred <[hidden email]> wrote: >>>>> >>>>>> On 3/20/21 1:28 PM, Jordon wrote: >>>>>> I recently decided to play with my BBB boards after ignoring them for a >>>>> few years (one of them still had 5.6 installed on it!). I have 3 >>>>> BeagleBone Black boards (2 with 2GB, 1 with 4GB). When i dd’ed >>>>> miniroot-am335x-68.img to a uSD cards and booted it, it all seemed >>>>> pretty >>>>> normal until I got to the part where it actually writes to the onboard >>>>> storage. It would fail due to IO errors. This happened on all 3 of my >>>>> boards. I figured it was unlikely that all 3 would have bad flash so I >>>>> re-imaged one with with a supported debian distro and it worked just >>>>> fine. >>>>>> Is there an issue with writing to the onboard storage in 6.8 or is >>>>>> there >>>>> some step I missed in the startup phase to get it working? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>> >>>>> with my BBB[1] I've never used the onboard storage I just boot the uSD >>>>> with OpenBSD on. The output from fdisk is shown below [2]. >>>>> >>>>> Cheers >>>>> >>>>> Fred >>>>> >>>>> [1] >>>>> bbb:fred ~> dmesg|head >>>>> OpenBSD 6.8 (GENERIC) #337: Wed Oct 7 01:35:49 MDT 2020 >>>>> [hidden email]:/usr/src/sys/arch/armv7/compile/GENERIC >>>>> real mem = 477290496 (455MB) >>>>> avail mem = 457314304 (436MB) >>>>> >>>>> [2] >>>>> bbb:fred ~> doas fdisk sd0 >>>>> doas ([hidden email]) password: >>>>> Disk: sd0 geometry: 233/255/63 [3751936 Sectors] >>>>> Offset: 0 Signature: 0xAA55 >>>>> Starting Ending LBA Info: >>>>> #: id C H S - C H S [ start: size ] >>>>> >>>>> ------------------------------------------------------------------------------- >>>>> *0: 0C 0 1 1 - 8 254 63 [ 63: 144522 ] >>>>> FAT32L >>>>> 1: 83 9 0 1 - 232 254 63 [ 144585: 3598560 ] >>>>> Linux files* >>>>> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] >>>>> unused >>>>> 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] >>>>> unused >>>>> bbb:fred ~> doas fdisk sd1 >>>>> Disk: sd1 geometry: 966/255/63 [15523840 Sectors] >>>>> Offset: 0 Signature: 0xAA55 >>>>> Starting Ending LBA Info: >>>>> #: id C H S - C H S [ start: size ] >>>>> >>>>> ------------------------------------------------------------------------------- >>>>> *0: 0C 0 32 33 - 2 42 40 [ 2048: 32768 ] >>>>> FAT32L >>>>> 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] >>>>> unused >>>>> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] >>>>> unused >>>>> 3: A6 2 42 41 - 966 80 10 [ 34816: 15489024 ] >>>>> OpenBSD >>>>> >>>>> >>> >>> >> >> >> -- >> ------------- >> Education is contagious. |
Re: IO Error writing to MMC BeagleBone Black
|
|
On Mon, Mar 22, 2021 at 07:00:06PM -0500, Jordon wrote:
> 6.6 was the last release that works. 6.7 and 6.8 throw an input/output error when it tries to create the partitions (right after you choose ‘(W)hole disk’). > > Am I the only person to try installing it to onboard storage in the last year? Or am I doing something wrong? The workaround to limit emmc bus width is not done after the device tree changes which removed the "ti,hwmods" property. While reads work without this writes give an error. After adding calls to enable clocks emmc writes work without limiting bus width. Index: ommmc.c =================================================================== RCS file: /cvs/src/sys/arch/armv7/omap/ommmc.c,v retrieving revision 1.38 diff -u -p -r1.38 ommmc.c --- ommmc.c 19 Jan 2021 18:04:43 -0000 1.38 +++ ommmc.c 24 Mar 2021 12:04:17 -0000 @@ -35,6 +35,7 @@ #include <armv7/omap/prcmvar.h> #include <dev/ofw/openfirm.h> +#include <dev/ofw/ofw_clock.h> #include <dev/ofw/ofw_gpio.h> #include <dev/ofw/ofw_pinctrl.h> #include <dev/ofw/fdt.h> @@ -304,8 +305,6 @@ ommmc_attach(struct device *parent, stru struct sdmmcbus_attach_args saa; uint32_t caps, width; uint32_t addr, size; - int len, unit; - char hwmods[128]; if (faa->fa_nreg < 1) return; @@ -322,14 +321,6 @@ ommmc_attach(struct device *parent, stru size = faa->fa_reg[0].size; } - unit = -1; - if ((len = OF_getprop(faa->fa_node, "ti,hwmods", hwmods, - sizeof(hwmods))) == 5) { - if (!strncmp(hwmods, "mmc", 3) && - (hwmods[3] > '0') && (hwmods[3] <= '9')) - unit = hwmods[3] - '1'; - } - sc->sc_iot = faa->fa_iot; if (bus_space_map(sc->sc_iot, addr, size, 0, &sc->sc_ioh)) panic("%s: bus_space_map failed!", __func__); @@ -339,9 +330,8 @@ ommmc_attach(struct device *parent, stru pinctrl_byname(faa->fa_node, "default"); - /* Enable ICLKEN, FCLKEN? */ - if (unit != -1) - prcm_enablemodule(PRCM_MMC0 + unit); + clock_enable_all(faa->fa_node); + reset_deassert_all(faa->fa_node); sc->sc_ih = arm_intr_establish_fdt(faa->fa_node, IPL_SDMMC, ommmc_intr, sc, DEVNAME(sc)); @@ -450,9 +440,6 @@ ommmc_attach(struct device *parent, stru saa.caps |= SMC_CAPS_MMC_HIGHSPEED | SMC_CAPS_SD_HIGHSPEED; } width = OF_getpropint(faa->fa_node, "bus-width", 1); - /* with bbb emmc width > 1 ommmc_wait_intr MMCHS_STAT_CC times out */ - if (unit > 0) - width = 1; if (width >= 8) saa.caps |= SMC_CAPS_8BIT_MODE; if (width >= 4) |
Re: IO Error writing to MMC BeagleBone Black
|
|
On Wed, Mar 24, 2021 at 11:14:43PM +1100, Jonathan Gray wrote:
> On Mon, Mar 22, 2021 at 07:00:06PM -0500, Jordon wrote: > > 6.6 was the last release that works. 6.7 and 6.8 throw an input/output error when it tries to create the partitions (right after you choose ‘(W)hole disk’). > > > > Am I the only person to try installing it to onboard storage in the last year? Or am I doing something wrong? > > The workaround to limit emmc bus width is not done after the device tree > changes which removed the "ti,hwmods" property. While reads work > without this writes give an error. > > After adding calls to enable clocks emmc writes work without limiting > bus width. updated diff with other ti,hwmods use Index: omgpio.c =================================================================== RCS file: /cvs/src/sys/arch/armv7/omap/omgpio.c,v retrieving revision 1.12 diff -u -p -r1.12 omgpio.c --- omgpio.c 10 Apr 2020 22:02:45 -0000 1.12 +++ omgpio.c 24 Mar 2021 13:46:44 -0000 @@ -17,26 +17,21 @@ #include <sys/param.h> #include <sys/systm.h> -#include <sys/queue.h> #include <sys/device.h> -#include <sys/malloc.h> #include <sys/evcount.h> #include <sys/gpio.h> -#include <arm/cpufunc.h> - #include <machine/bus.h> #include <machine/fdt.h> #include <machine/intr.h> #include <dev/gpio/gpiovar.h> -#include <armv7/armv7/armv7var.h> -#include <armv7/omap/prcmvar.h> #include <armv7/omap/omgpiovar.h> #include <dev/ofw/fdt.h> #include <dev/ofw/openfirm.h> +#include <dev/ofw/ofw_clock.h> #include <dev/ofw/ofw_gpio.h> #include "gpio.h" @@ -259,22 +254,12 @@ omgpio_attach(struct device *parent, str struct omgpio_softc *sc = (struct omgpio_softc *) self; struct gpiobus_attach_args gba; u_int32_t rev; - int i, len, unit; - char hwmods[64]; + int i; if (faa->fa_nreg < 1) return; - unit = -1; - if ((len = OF_getprop(faa->fa_node, "ti,hwmods", hwmods, - sizeof(hwmods))) == 6) { - if ((strncmp(hwmods, "gpio", 4) == 0) && - (hwmods[4] > '0') && (hwmods[4] <= '9')) - unit = hwmods[4] - '1'; - } - - if (unit != -1) - prcm_enablemodule(PRCM_GPIO0 + unit); + clock_enable_all(faa->fa_node); sc->sc_node = faa->fa_node; sc->sc_iot = faa->fa_iot; Index: ommmc.c =================================================================== RCS file: /cvs/src/sys/arch/armv7/omap/ommmc.c,v retrieving revision 1.38 diff -u -p -r1.38 ommmc.c --- ommmc.c 19 Jan 2021 18:04:43 -0000 1.38 +++ ommmc.c 24 Mar 2021 13:46:44 -0000 @@ -19,11 +19,8 @@ /* Omap SD/MMC support derived from /sys/dev/sdmmc/sdhc.c */ - #include <sys/param.h> #include <sys/device.h> -#include <sys/kernel.h> -#include <sys/malloc.h> #include <sys/systm.h> #include <machine/bus.h> #include <machine/fdt.h> @@ -31,10 +28,8 @@ #include <dev/sdmmc/sdmmcchip.h> #include <dev/sdmmc/sdmmcvar.h> -#include <armv7/armv7/armv7var.h> -#include <armv7/omap/prcmvar.h> - #include <dev/ofw/openfirm.h> +#include <dev/ofw/ofw_clock.h> #include <dev/ofw/ofw_gpio.h> #include <dev/ofw/ofw_pinctrl.h> #include <dev/ofw/fdt.h> @@ -304,8 +299,6 @@ ommmc_attach(struct device *parent, stru struct sdmmcbus_attach_args saa; uint32_t caps, width; uint32_t addr, size; - int len, unit; - char hwmods[128]; if (faa->fa_nreg < 1) return; @@ -322,14 +315,6 @@ ommmc_attach(struct device *parent, stru size = faa->fa_reg[0].size; } - unit = -1; - if ((len = OF_getprop(faa->fa_node, "ti,hwmods", hwmods, - sizeof(hwmods))) == 5) { - if (!strncmp(hwmods, "mmc", 3) && - (hwmods[3] > '0') && (hwmods[3] <= '9')) - unit = hwmods[3] - '1'; - } - sc->sc_iot = faa->fa_iot; if (bus_space_map(sc->sc_iot, addr, size, 0, &sc->sc_ioh)) panic("%s: bus_space_map failed!", __func__); @@ -339,9 +324,8 @@ ommmc_attach(struct device *parent, stru pinctrl_byname(faa->fa_node, "default"); - /* Enable ICLKEN, FCLKEN? */ - if (unit != -1) - prcm_enablemodule(PRCM_MMC0 + unit); + clock_enable_all(faa->fa_node); + reset_deassert_all(faa->fa_node); sc->sc_ih = arm_intr_establish_fdt(faa->fa_node, IPL_SDMMC, ommmc_intr, sc, DEVNAME(sc)); @@ -450,9 +434,6 @@ ommmc_attach(struct device *parent, stru saa.caps |= SMC_CAPS_MMC_HIGHSPEED | SMC_CAPS_SD_HIGHSPEED; } width = OF_getpropint(faa->fa_node, "bus-width", 1); - /* with bbb emmc width > 1 ommmc_wait_intr MMCHS_STAT_CC times out */ - if (unit > 0) - width = 1; if (width >= 8) saa.caps |= SMC_CAPS_8BIT_MODE; if (width >= 4) Index: omrng.c =================================================================== RCS file: /cvs/src/sys/arch/armv7/omap/omrng.c,v retrieving revision 1.2 diff -u -p -r1.2 omrng.c --- omrng.c 29 May 2020 04:42:23 -0000 1.2 +++ omrng.c 24 Mar 2021 13:46:44 -0000 @@ -24,10 +24,9 @@ #include <machine/fdt.h> #include <dev/ofw/openfirm.h> +#include <dev/ofw/ofw_clock.h> #include <dev/ofw/fdt.h> -#include <armv7/omap/prcmvar.h> - /* Registers */ #define RNG_OUTPUT0 0x0000 #define RNG_OUTPUT1 0x0004 @@ -110,8 +109,7 @@ omrng_attach(struct device *parent, stru printf("\n"); - if (OF_getproplen(faa->fa_node, "ti,hwmods") > 0) - prcm_enablemodule(PRCM_RNG); + clock_enable_all(faa->fa_node); /* Configure and enable the RNG. */ HWRITE4(sc, RNG_CONFIG, 0x21 << RNG_CONFIG_MIN_CYCLES_SHIFT | Index: ti_iic.c =================================================================== RCS file: /cvs/src/sys/arch/armv7/omap/ti_iic.c,v retrieving revision 1.13 diff -u -p -r1.13 ti_iic.c --- ti_iic.c 10 Apr 2020 22:02:45 -0000 1.13 +++ ti_iic.c 24 Mar 2021 13:46:44 -0000 @@ -50,11 +50,9 @@ * SUCH DAMAGE. */ -#include <sys/cdefs.h> #include <sys/param.h> #include <sys/systm.h> #include <sys/device.h> -#include <sys/kernel.h> #include <sys/rwlock.h> #include <machine/bus.h> @@ -63,12 +61,11 @@ #include <dev/i2c/i2cvar.h> -#include <armv7/armv7/armv7var.h> -#include <armv7/omap/prcmvar.h> #include <armv7/omap/ti_iicreg.h> #include <dev/ofw/openfirm.h> #include <dev/ofw/ofw_pinctrl.h> +#include <dev/ofw/ofw_clock.h> #include <dev/ofw/fdt.h> #ifndef AM335X_I2C_SLAVE_ADDR @@ -165,8 +162,6 @@ ti_iic_attach(struct device *parent, str struct fdt_attach_args *faa = aux; struct i2cbus_attach_args iba; uint16_t rev; - int unit, len; - char hwmods[128]; if (faa->fa_nreg < 1) return; @@ -174,14 +169,6 @@ ti_iic_attach(struct device *parent, str sc->sc_iot = faa->fa_iot; sc->sc_node = faa->fa_node; - unit = -1; - if ((len = OF_getprop(faa->fa_node, "ti,hwmods", hwmods, - sizeof(hwmods))) == 5) { - if (!strncmp(hwmods, "i2c", 3) && - (hwmods[3] > '0') && (hwmods[3] <= '9')) - unit = hwmods[3] - '1'; - } - rw_init(&sc->sc_buslock, "tiiilk"); sc->sc_rxthres = sc->sc_txthres = 4; @@ -195,8 +182,7 @@ ti_iic_attach(struct device *parent, str sc->sc_ih = arm_intr_establish_fdt(faa->fa_node, IPL_NET, ti_iic_intr, sc, DEVNAME(sc)); - if (unit != -1) - prcm_enablemodule(PRCM_I2C0 + unit); + clock_enable_all(faa->fa_node); rev = I2C_READ_REG(sc, AM335X_I2C_REVNB_LO); printf(" rev %d.%d\n", |
Re: IO Error writing to MMC BeagleBone Black
|
|
In reply to this post by jordon-7
Hi,
I had a couple and both had issues with the onboard storage after an upgrade. So no, you are not the only person. As both were aging and 32 bit I decided that they were better off being recycled and a couple of Pine A64's took their place. Cheers. On Tue, 23 Mar 2021 at 10:01, Jordon <[hidden email]> wrote: > 6.6 was the last release that works. 6.7 and 6.8 throw an input/output > error when it tries to create the partitions (right after you choose > ‘(W)hole disk’). > > Am I the only person to try installing it to onboard storage in the last > year? Or am I doing something wrong? > > > > > On Mar 21, 2021, at 23:26, Jordon <[hidden email]> wrote: > > > > I just ran the installer for 5.7 and it had no problems writing to the > emmc. Tomorrow after work i might try bisecting to see what the last > functional version was, but it really looks like there was a regression at > some point. > > > > > > > >> On Mar 21, 2021, at 16:41, Alan Corey <[hidden email]> wrote: > >> > >> They do wear out, mine in my Pinebook Pro was about a year old when I > >> was seeing strange crashes. Loaded up a brand new SD card and I get > >> uptimes of a week or more. And refomatting a misbehaving sd or emmc > >> sometimes works wonders for ueexplainable reasons, it's like it needs > >> to be refreshed periodically.. > >> > >>>> On 3/21/21, Jordon <[hidden email]> wrote: > >>> The issue is not the sd card - it is the onboard emmc. I dd’ed the > miniroot > >>> image to a micro sd card. I the boot the bbb and run the installer. > I set > >>> the install drive to the onboard emmc drive and when it tries to write > to > >>> it, I get io errors. This used to work, as i had 5.6 on one of my > bbb’s and > >>> 5.8 on another, both booting without micro sd cards in them. > >>> > >>> I have received messages that suggest that this never worked, but I > know I > >>> did this years ago following a post from tedu’s website. > >>> > >>> And i did flash the debian ‘flasher’ image to the micro sd card, > booted it, > >>> and had it run through its reimaging process, and afterwards the bbb > booted > >>> debian just fine, so the micro sd card and the emmc are both > functional. > >>> > >>> > >>>>> On Mar 20, 2021, at 14:52, Alan Corey <[hidden email]> wrote: > >>>> > >>>> man mount, then type /read-only to search, / to search for the same > >>>> thing > >>>> again. Sometimes a read-only mount happens if thare's something > wrong. > >>>> > >>>> But reformat and try reloading before you throw it away. > >>>> > >>>>> On Sat, Mar 20, 2021, 3:30 PM Fred <[hidden email]> wrote: > >>>>> > >>>>>> On 3/20/21 1:28 PM, Jordon wrote: > >>>>>> I recently decided to play with my BBB boards after ignoring them > for a > >>>>> few years (one of them still had 5.6 installed on it!). I have 3 > >>>>> BeagleBone Black boards (2 with 2GB, 1 with 4GB). When i dd’ed > >>>>> miniroot-am335x-68.img to a uSD cards and booted it, it all seemed > >>>>> pretty > >>>>> normal until I got to the part where it actually writes to the > onboard > >>>>> storage. It would fail due to IO errors. This happened on all 3 of > my > >>>>> boards. I figured it was unlikely that all 3 would have bad flash > so I > >>>>> re-imaged one with with a supported debian distro and it worked just > >>>>> fine. > >>>>>> Is there an issue with writing to the onboard storage in 6.8 or is > >>>>>> there > >>>>> some step I missed in the startup phase to get it working? > >>>>>> > >>>>>> Thanks! > >>>>>> > >>>>>> > >>>>> > >>>>> with my BBB[1] I've never used the onboard storage I just boot the > uSD > >>>>> with OpenBSD on. The output from fdisk is shown below [2]. > >>>>> > >>>>> Cheers > >>>>> > >>>>> Fred > >>>>> > >>>>> [1] > >>>>> bbb:fred ~> dmesg|head > >>>>> OpenBSD 6.8 (GENERIC) #337: Wed Oct 7 01:35:49 MDT 2020 > >>>>> [hidden email]:/usr/src/sys/arch/armv7/compile/GENERIC > >>>>> real mem = 477290496 (455MB) > >>>>> avail mem = 457314304 (436MB) > >>>>> > >>>>> [2] > >>>>> bbb:fred ~> doas fdisk sd0 > >>>>> doas ([hidden email]) password: > >>>>> Disk: sd0 geometry: 233/255/63 [3751936 Sectors] > >>>>> Offset: 0 Signature: 0xAA55 > >>>>> Starting Ending LBA Info: > >>>>> #: id C H S - C H S [ start: size ] > >>>>> > >>>>> > ------------------------------------------------------------------------------- > >>>>> *0: 0C 0 1 1 - 8 254 63 [ 63: 144522 ] > >>>>> FAT32L > >>>>> 1: 83 9 0 1 - 232 254 63 [ 144585: 3598560 ] > >>>>> Linux files* > >>>>> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] > >>>>> unused > >>>>> 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] > >>>>> unused > >>>>> bbb:fred ~> doas fdisk sd1 > >>>>> Disk: sd1 geometry: 966/255/63 [15523840 Sectors] > >>>>> Offset: 0 Signature: 0xAA55 > >>>>> Starting Ending LBA Info: > >>>>> #: id C H S - C H S [ start: size ] > >>>>> > >>>>> > ------------------------------------------------------------------------------- > >>>>> *0: 0C 0 32 33 - 2 42 40 [ 2048: 32768 ] > >>>>> FAT32L > >>>>> 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] > >>>>> unused > >>>>> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] > >>>>> unused > >>>>> 3: A6 2 42 41 - 966 80 10 [ 34816: 15489024 ] > >>>>> OpenBSD > >>>>> > >>>>> > >>> > >>> > >> > >> > >> -- > >> ------------- > >> Education is contagious. > > -- Simon -- ------------------------------------------------------------------------ "Well, an engineer is not concerned with the truth; that is left to philosophers and theologians: the prime concern of an engineer is the utility of the final product." Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh |
Re: IO Error writing to MMC BeagleBone Black
|
|
In reply to this post by Jonathan Gray-11
On Thu, Mar 25, 2021 at 12:54:02AM +1100, Jonathan Gray wrote:
> On Wed, Mar 24, 2021 at 11:14:43PM +1100, Jonathan Gray wrote: > > On Mon, Mar 22, 2021 at 07:00:06PM -0500, Jordon wrote: > > > 6.6 was the last release that works. 6.7 and 6.8 throw an input/output error when it tries to create the partitions (right after you choose ‘(W)hole disk’). > > > > > > Am I the only person to try installing it to onboard storage in the last year? Or am I doing something wrong? > > > > The workaround to limit emmc bus width is not done after the device tree > > changes which removed the "ti,hwmods" property. While reads work > > without this writes give an error. > > > > After adding calls to enable clocks emmc writes work without limiting > > bus width. > > updated diff with other ti,hwmods use Looking at the device tree I see the clocks should be enabled by omsysc(4) already. I can't trigger emmc errors on writes at the moment even after dropping the diff so I'm not sure what is going on. Not handling vmmc-supply/regulator enable? > > Index: omgpio.c > =================================================================== > RCS file: /cvs/src/sys/arch/armv7/omap/omgpio.c,v > retrieving revision 1.12 > diff -u -p -r1.12 omgpio.c > --- omgpio.c 10 Apr 2020 22:02:45 -0000 1.12 > +++ omgpio.c 24 Mar 2021 13:46:44 -0000 > @@ -17,26 +17,21 @@ > > #include <sys/param.h> > #include <sys/systm.h> > -#include <sys/queue.h> > #include <sys/device.h> > -#include <sys/malloc.h> > #include <sys/evcount.h> > #include <sys/gpio.h> > > -#include <arm/cpufunc.h> > - > #include <machine/bus.h> > #include <machine/fdt.h> > #include <machine/intr.h> > > #include <dev/gpio/gpiovar.h> > > -#include <armv7/armv7/armv7var.h> > -#include <armv7/omap/prcmvar.h> > #include <armv7/omap/omgpiovar.h> > > #include <dev/ofw/fdt.h> > #include <dev/ofw/openfirm.h> > +#include <dev/ofw/ofw_clock.h> > #include <dev/ofw/ofw_gpio.h> > > #include "gpio.h" > @@ -259,22 +254,12 @@ omgpio_attach(struct device *parent, str > struct omgpio_softc *sc = (struct omgpio_softc *) self; > struct gpiobus_attach_args gba; > u_int32_t rev; > - int i, len, unit; > - char hwmods[64]; > + int i; > > if (faa->fa_nreg < 1) > return; > > - unit = -1; > - if ((len = OF_getprop(faa->fa_node, "ti,hwmods", hwmods, > - sizeof(hwmods))) == 6) { > - if ((strncmp(hwmods, "gpio", 4) == 0) && > - (hwmods[4] > '0') && (hwmods[4] <= '9')) > - unit = hwmods[4] - '1'; > - } > - > - if (unit != -1) > - prcm_enablemodule(PRCM_GPIO0 + unit); > + clock_enable_all(faa->fa_node); > > sc->sc_node = faa->fa_node; > sc->sc_iot = faa->fa_iot; > Index: ommmc.c > =================================================================== > RCS file: /cvs/src/sys/arch/armv7/omap/ommmc.c,v > retrieving revision 1.38 > diff -u -p -r1.38 ommmc.c > --- ommmc.c 19 Jan 2021 18:04:43 -0000 1.38 > +++ ommmc.c 24 Mar 2021 13:46:44 -0000 > @@ -19,11 +19,8 @@ > > /* Omap SD/MMC support derived from /sys/dev/sdmmc/sdhc.c */ > > - > #include <sys/param.h> > #include <sys/device.h> > -#include <sys/kernel.h> > -#include <sys/malloc.h> > #include <sys/systm.h> > #include <machine/bus.h> > #include <machine/fdt.h> > @@ -31,10 +28,8 @@ > #include <dev/sdmmc/sdmmcchip.h> > #include <dev/sdmmc/sdmmcvar.h> > > -#include <armv7/armv7/armv7var.h> > -#include <armv7/omap/prcmvar.h> > - > #include <dev/ofw/openfirm.h> > +#include <dev/ofw/ofw_clock.h> > #include <dev/ofw/ofw_gpio.h> > #include <dev/ofw/ofw_pinctrl.h> > #include <dev/ofw/fdt.h> > @@ -304,8 +299,6 @@ ommmc_attach(struct device *parent, stru > struct sdmmcbus_attach_args saa; > uint32_t caps, width; > uint32_t addr, size; > - int len, unit; > - char hwmods[128]; > > if (faa->fa_nreg < 1) > return; > @@ -322,14 +315,6 @@ ommmc_attach(struct device *parent, stru > size = faa->fa_reg[0].size; > } > > - unit = -1; > - if ((len = OF_getprop(faa->fa_node, "ti,hwmods", hwmods, > - sizeof(hwmods))) == 5) { > - if (!strncmp(hwmods, "mmc", 3) && > - (hwmods[3] > '0') && (hwmods[3] <= '9')) > - unit = hwmods[3] - '1'; > - } > - > sc->sc_iot = faa->fa_iot; > if (bus_space_map(sc->sc_iot, addr, size, 0, &sc->sc_ioh)) > panic("%s: bus_space_map failed!", __func__); > @@ -339,9 +324,8 @@ ommmc_attach(struct device *parent, stru > > pinctrl_byname(faa->fa_node, "default"); > > - /* Enable ICLKEN, FCLKEN? */ > - if (unit != -1) > - prcm_enablemodule(PRCM_MMC0 + unit); > + clock_enable_all(faa->fa_node); > + reset_deassert_all(faa->fa_node); > > sc->sc_ih = arm_intr_establish_fdt(faa->fa_node, IPL_SDMMC, > ommmc_intr, sc, DEVNAME(sc)); > @@ -450,9 +434,6 @@ ommmc_attach(struct device *parent, stru > saa.caps |= SMC_CAPS_MMC_HIGHSPEED | SMC_CAPS_SD_HIGHSPEED; > } > width = OF_getpropint(faa->fa_node, "bus-width", 1); > - /* with bbb emmc width > 1 ommmc_wait_intr MMCHS_STAT_CC times out */ > - if (unit > 0) > - width = 1; > if (width >= 8) > saa.caps |= SMC_CAPS_8BIT_MODE; > if (width >= 4) > Index: omrng.c > =================================================================== > RCS file: /cvs/src/sys/arch/armv7/omap/omrng.c,v > retrieving revision 1.2 > diff -u -p -r1.2 omrng.c > --- omrng.c 29 May 2020 04:42:23 -0000 1.2 > +++ omrng.c 24 Mar 2021 13:46:44 -0000 > @@ -24,10 +24,9 @@ > #include <machine/fdt.h> > > #include <dev/ofw/openfirm.h> > +#include <dev/ofw/ofw_clock.h> > #include <dev/ofw/fdt.h> > > -#include <armv7/omap/prcmvar.h> > - > /* Registers */ > #define RNG_OUTPUT0 0x0000 > #define RNG_OUTPUT1 0x0004 > @@ -110,8 +109,7 @@ omrng_attach(struct device *parent, stru > > printf("\n"); > > - if (OF_getproplen(faa->fa_node, "ti,hwmods") > 0) > - prcm_enablemodule(PRCM_RNG); > + clock_enable_all(faa->fa_node); > > /* Configure and enable the RNG. */ > HWRITE4(sc, RNG_CONFIG, 0x21 << RNG_CONFIG_MIN_CYCLES_SHIFT | > Index: ti_iic.c > =================================================================== > RCS file: /cvs/src/sys/arch/armv7/omap/ti_iic.c,v > retrieving revision 1.13 > diff -u -p -r1.13 ti_iic.c > --- ti_iic.c 10 Apr 2020 22:02:45 -0000 1.13 > +++ ti_iic.c 24 Mar 2021 13:46:44 -0000 > @@ -50,11 +50,9 @@ > * SUCH DAMAGE. > */ > > -#include <sys/cdefs.h> > #include <sys/param.h> > #include <sys/systm.h> > #include <sys/device.h> > -#include <sys/kernel.h> > #include <sys/rwlock.h> > > #include <machine/bus.h> > @@ -63,12 +61,11 @@ > > #include <dev/i2c/i2cvar.h> > > -#include <armv7/armv7/armv7var.h> > -#include <armv7/omap/prcmvar.h> > #include <armv7/omap/ti_iicreg.h> > > #include <dev/ofw/openfirm.h> > #include <dev/ofw/ofw_pinctrl.h> > +#include <dev/ofw/ofw_clock.h> > #include <dev/ofw/fdt.h> > > #ifndef AM335X_I2C_SLAVE_ADDR > @@ -165,8 +162,6 @@ ti_iic_attach(struct device *parent, str > struct fdt_attach_args *faa = aux; > struct i2cbus_attach_args iba; > uint16_t rev; > - int unit, len; > - char hwmods[128]; > > if (faa->fa_nreg < 1) > return; > @@ -174,14 +169,6 @@ ti_iic_attach(struct device *parent, str > sc->sc_iot = faa->fa_iot; > sc->sc_node = faa->fa_node; > > - unit = -1; > - if ((len = OF_getprop(faa->fa_node, "ti,hwmods", hwmods, > - sizeof(hwmods))) == 5) { > - if (!strncmp(hwmods, "i2c", 3) && > - (hwmods[3] > '0') && (hwmods[3] <= '9')) > - unit = hwmods[3] - '1'; > - } > - > rw_init(&sc->sc_buslock, "tiiilk"); > > sc->sc_rxthres = sc->sc_txthres = 4; > @@ -195,8 +182,7 @@ ti_iic_attach(struct device *parent, str > sc->sc_ih = arm_intr_establish_fdt(faa->fa_node, IPL_NET, > ti_iic_intr, sc, DEVNAME(sc)); > > - if (unit != -1) > - prcm_enablemodule(PRCM_I2C0 + unit); > + clock_enable_all(faa->fa_node); > > rev = I2C_READ_REG(sc, AM335X_I2C_REVNB_LO); > printf(" rev %d.%d\n", > > |
«
Return to openbsd port - arm
|
1 view|%1 views
| Free forum by Nabble | Edit this page |